What Happens When a Deploy Fails

On a lot of platforms, a failed deploy is the scariest moment you have — the build breaks and the site breaks with it, in public. On SrvBot it’s designed to be a non-event. Here’s exactly what happens when a build fails.

The build runs in isolation

When you push, your new version is fetched, its dependencies installed, and the project compiled and checked — all in a separate build step that no visitor traffic touches. Nothing about your live site changes while this runs.

Traffic only switches on success

This is the core of it: SrvBot only moves traffic to a new build after that build succeeds. If the build fails, traffic keeps flowing to the last working version. Your live site is unaffected — visitors never see the broken build, because it never went live.

You get the log, not a mystery

A failed deploy shows a clear failed status with the build log attached. Scroll to the first line marked ERROR, or to where the process exited, and that’s almost always the cause — a missing environment variable, a build-command mismatch, a failing test. The full guide to reading it is at /help/failed-deploy.

Rolling back is one action

If a deploy succeeds but causes a problem you only notice later, you don’t need to reconstruct anything. Open the deploy history, find the last known-good version, and redeploy it. SrvBot rebuilds from that exact commit and switches traffic back once it’s ready.

Why we built it this way

Most real-world downtime is self-inflicted — a bad deploy, not a data-center failure. The platform should make that failure mode safe by default, so shipping often doesn’t mean risking the site each time.

The bottom line

A build that fails should cost you a log to read, not an outage to explain. The recovery walkthrough lives at /help/failed-deploy, and you can try the deploy flow yourself from /get-started.