Automated Deploy Gates Prevent Broken Production Sites

The Gap Between "Build Passed" and "Site Works"

A deploy pipeline that stops at "the build succeeded" is answering the wrong question. A build can compile cleanly, pass every unit test, and still ship a broken production site — a missing environment variable that only matters at runtime, a database migration that hasn't run yet against the schema the new code expects, a CDN cache that's still serving the previous version's assets alongside the new HTML. None of these show up in a build log. All of them show up the moment a real visitor loads a real page.

An automated deploy gate closes that gap by treating "the deploy is live" and "the site is actually working" as two separate claims, and refusing to consider a deploy finished until both are verified against the running system — not against the code that was supposed to produce it.

What a Deploy Gate Verifies

A deploy gate for a content-heavy site typically checks, in roughly this order:

1. Build and type-check success. The baseline everyone already does, and necessary but nowhere near sufficient.
2. Smoke-test key routes. After deploy, actually request a representative sample of pages — the homepage, a category page, a handful of individual articles, any page type your site has — and check the HTTP status code and a minimum expected content signature (a known string, a minimum byte size, a required element in the markup). A 200 status with an empty body is a "pass" by naive health checks and a total failure by any standard that matters.
3. Database and migration state. If the new code expects a schema change, confirm the migration has actually run against the target database before the new code starts serving traffic, not as a manual step someone remembers to do "around the same time" as the deploy.
4. Critical third-party dependencies. If the site depends on an API, a CDN, or a search index being reachable and correctly configured, check that reachability as part of the gate rather than discovering it's down when the first user hits an error.
5. Performance regression check. A lightweight synthetic check of load time or key metrics against the pre-deploy baseline catches the case where the new code works correctly but is meaningfully slower — a real, if quieter, form of "broken."

Each of these is cheap to run and expensive to skip. The cost of skipping doesn't show up as a failed deploy — it shows up later, as an incident, at a moment with much less context about what changed and why.

Rollback Has to Be a Mechanism, Not a Plan

"We'll roll back if something goes wrong" is not a rollback strategy unless rolling back is something the system can do automatically and quickly, without a human first noticing something's wrong, then finding the previous known-good state, then executing a set of manual steps under pressure. Every one of those steps adds time, and for a public content site, time spent broken is time spent showing readers, and search crawlers, a site that doesn't work.

A deploy gate that's actually useful is tied to automatic rollback: if the post-deploy checks fail, the system reverts to the last known-good deployment without waiting for a person to make that call. This requires a few things to be true architecturally:

• Deploys need to be atomic and reversible at the infrastructure level — a previous version needs to still exist and be quickly promotable, which is the normal behavior of platforms built around immutable deployments and instant traffic-switching, but is not automatic if you're deploying by overwriting files in place on a single server.
• The rollback target has to be verified good, not just "previous." Rolling back to a deployment that was itself broken doesn't help. This is one more reason the deploy gate needs to run and pass on every deploy, including the ones you're rolling back to — you want to always know your rollback target already cleared the gate once.
• Database and content-side changes need to be considered separately from code changes. Code can usually roll back cleanly; a completed data migration often can't be undone as cleanly, which means gates on migrations need to be stricter and more conservative than gates on a code-only deploy, because the fallback plan for code (revert) doesn't apply symmetrically to data.

Staged Rollout as a Complement, Not a Replacement

Where traffic volume allows it, routing a small percentage of live traffic to a new deploy before promoting it to everyone gives the deploy gate a second, real-world data source beyond synthetic smoke tests — actual error rates, actual response times, from actual requests, before the blast radius is the whole site. This doesn't replace pre-promotion checks; a canary that immediately starts throwing errors for 5% of traffic is still 5% of your readers having a bad experience, just a smaller bad experience than 100%. Staged rollout is a way to shrink the cost of a gate that missed something, not a substitute for making the gate as thorough as you can before traffic hits it at all.

The Post-Deploy Probe Nobody Wants to Write

The single highest-leverage piece of this whole system, and the one most often skipped, is the simplest one: after every deploy, actually fetch a handful of live URLs from the outside — the same way a real visitor or a search crawler would — and check what comes back. Not a health-check endpoint you built specifically to always return 200. Not an internal status page. The actual article pages, requested over the actual public internet, checked for the actual content that's supposed to be there.

This catches the failure class that everything upstream of it structurally cannot: the build succeeded, the code is correct, the database migrated fine, and something in the layer between your application and the public internet — a CDN configuration, a DNS change, an edge cache serving stale content, a WAF rule blocking legitimate requests — is still broken. That layer is invisible to anything running inside your deploy pipeline, because your deploy pipeline isn't the public internet. Only a probe that goes out and comes back in through the same path a real visitor uses will see what a real visitor sees.

Building This Incrementally

None of this needs to exist on day one, and building all of it before you have real traffic is its own kind of waste. A reasonable sequence: start with a single post-deploy smoke test hitting three or four key pages and checking for 200-plus-expected-content. Add automatic rollback tied to that check's failure. Add a broader page sample and a performance baseline once traffic and page count justify the cost of running them on every deploy. Add staged rollout once you have enough traffic that a canary sample is statistically meaningful.

What matters is the direction: every step moves the system from "we assume the deploy worked because the pipeline said so" toward "we verified the deploy worked because we checked the thing that was actually supposed to change." That's the difference between a site that occasionally goes down and one where going down requires two independent things to fail at once.