We shipped ZevAI, and it starts with the logs nobody wants to read

A deploy fails at eleven at night. You open the logs and get two thousand lines, most of them a dependency install that went fine, and somewhere in the middle one line that actually matters. If you knew which line, you would not be reading the logs.

That moment is where we decided to start.

ZevAI is live on ZevCloud, on every plan including free. Its first job is explaining failed deployments. Open a deployment that failed, press Explain, and you get three short sections: what happened, why it happened, and what to do next.

What you actually get

Not a chat window, and not a wall of text. Three headings and links.

1. What happened. The failure in one or two sentences, in plain language. Not the stack trace, the meaning of it.

2. Why. The cause, tied to the specific line in your log that shows it.

3. What to do next. Concrete steps for your project. Change this setting, add this file, pin this version.

Underneath, the documentation pages the answer drew on, linked. If the explanation is wrong you can check it against the source in one click, which matters more than the explanation being confident.

What it will not do

This part shaped the feature more than anything else.

It will not blame you for our mistakes. Some failures are ours. A build host that refused a connection, an internal timeout, something on our side having a bad minute. Those logs look alarming and have nothing to do with your code. When the failure is ours, ZevAI says so first, in our own words, and does not speculate about your repository. It never even asks the model in that case, because a model asked to explain a failure will find something in your code to blame. It is answering the question it was given. It cannot know that the answer is "this one is on us".

It will not invent ZevCloud features. Every answer is grounded in our documentation, and cites it. An ungrounded model writing about a product it half-remembers will suggest settings that do not exist and file paths you do not have.

It will not stand between you and a human. When the failure is ours, the card leads with Report to ZevCloud. One press attaches the deployment, the relevant log excerpt and what ZevAI concluded, and hands you a reference number. Our team sees it immediately. The same option is there for project-side failures, just quieter. If the explanation is wrong, or right but useless, reaching us takes one click and no retyping.

What happens to your logs

A fair question to ask of any AI feature, so here is the exact answer.

Before a log leaves our network it is sanitised, redacted and clipped. Sanitised means infrastructure detail is stripped, the same pass we already run before showing you logs. Redacted means anything shaped like a credential is removed. Clipped means the head and the tail only, because the middle two thousand lines of a package install help nobody.

The standard we hold ourselves to is one sentence: the log that leaves our network is the log you can already see, minus anything that looks like a secret.

Explanations are cached for a day against the deployment, so reopening the page does not send anything anywhere. A failed build's log never changes, and neither does its explanation.

Tell us when it is wrong

Every explanation has a thumbs up and a thumbs down, and both go into the same record we use to judge whether the feature is worth running. We can see how often it helps, how often it does not, and what each answer cost.

If you press thumbs down, that lands in front of us with the deployment attached. It is the most useful thing you can do with ten seconds, and it is how the next version gets better at the failures that actually happen to you rather than the ones we imagined.

Why start here

We could have started with a chat box. Chat boxes demo well.

But nobody opens a hosting dashboard wanting to chat. They open it because something broke, and the gap between "it failed" and "here is the line that matters" is where people give up on deploying at all. That gap is worst for exactly the people we built ZevCloud for: someone shipping their first real project, who did not choose this error message and has no idea it means their Node version is wrong.

Closing that gap is worth more than a chat box, and it is measurable, which a chat box is not.

What is next

More of ZevCloud, and eventually more of Zev. The same core runs behind anything we add, so the rules above hold everywhere: deterministic answers where we have them, grounded generation where we do not, nothing invented, and always a way to reach a person.

ZevAI is on now. There is nothing to enable. The next time a deploy fails, the button is there.

If you want the engineering side of this, the decisions about when not to call a model, what leaves your network and how we measure whether any of it helps, that is the follow-up post.