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.