CLOUD & DEVOPS / PRODUCTION LESSONS
What I Check Before Every Production Go-Live
A calm, repeatable checklist for the last mile before a release.
Key Insight: Almost every go-live incident I've seen traces back to a question nobody asked out loud, not a technology nobody understood.
After 19+ years shipping software into production, the pattern is consistent: the releases that go badly aren't the ones with hard technical problems. They're the ones where a reasonable-sounding assumption never got checked. This is the checklist I actually run — not a formality, a set of questions that have each personally saved me from an incident at some point.
Can we see it the moment it breaks?
Before anything else: if this release causes a problem, will we know within minutes, or will a customer tell us first? That means confirming dashboards exist for the new code paths, alerts are wired to a real on-call rotation (not a channel nobody watches), and the metrics that matter — error rate, latency, saturation — are visible for the specific feature shipping, not just the service as a whole.
A new feature with no dedicated metrics is flying blind wrapped in an existing dashboard's confidence.
Can we undo it in minutes, not hours?
Rollback should be a rehearsed action, not a plan. I check: is the previous version still deployable with one command? Are database migrations backward-compatible with the old code, so a rollback doesn't also require reversing a schema change under pressure? Is there a feature flag on the risky part, so we can disable behavior without a full redeploy?
The releases I regret aren't the ones that broke. They're the ones that broke *and* took 40 minutes to undo because rollback was theoretical.
Have we tested the failure paths, not just the happy path?
Staging environments are excellent at proving the happy path works. They're much worse at surfacing what happens when a downstream dependency times out, when a queue backs up, or when a retry storm starts. Before go-live, I want an answer to: what happens if this new dependency is slow? What happens if it's completely unavailable? Does the system degrade, or does it cascade?
If the honest answer is "we don't know," that's a gap worth closing before release, not after.
What's the actual blast radius?
Not every release needs a canary and a phased rollout, but every release deserves the question: who is affected if this is wrong, and how many of them? A change behind a feature flag, ramped from 1% to 100% over a day, fails safely. A change deployed to 100% of production traffic at once fails loudly, at scale, immediately.
Match the rollout strategy to the actual risk — that's a judgment call, not a checkbox, but it has to be made deliberately rather than defaulted into.
Does someone specific own this if it breaks tonight?
Vague ownership is how minor incidents become major ones. Before go-live: who is on call, do they know this feature shipped, and do they have enough context to make a call at 2am without waking up the person who wrote the code? A short runbook — what this feature does, what "broken" looks like, and the fastest safe mitigation — is cheap insurance.
Have we told anyone who needs to know?
Support teams fielding confused customer tickets about a feature they didn't know shipped is a completely avoidable failure mode. A two-line heads-up to support and any dependent teams costs nothing and prevents a scramble.
Key takeaways
Confirm observability exists for the new code specifically, not just the service generally. Rehearse rollback rather than assuming it. Test what happens when dependencies fail, not just when they work. Size the rollout to the actual blast radius. Name an owner who can act at 2am. Tell the humans downstream of this change before it ships, not after they ask what happened.