Production Readiness Checklist

Most software does not fail because the code was wrong. It fails because something nobody owned was missing on the day it went live: an alert that pointed at a dead inbox, a database with no tested restore, a dependency that expired on a Sunday. A production readiness review is the meeting where you find those things while they are still cheap.

This is the checklist we work through before putting a system in front of real users. Use it as a gate, not a formality. Anything you cannot answer with evidence is an open risk, not a green tick.

1. Reliability and failure behaviour

• Every external dependency has an explicit timeout. No unbounded waits anywhere in the request path.
• Retries use exponential backoff with jitter, and are only applied to operations that are safe to repeat.
• The system degrades rather than collapses when a downstream service is unavailable. You have decided, in writing, what each failure looks like to the user.
• There is a documented single point of failure list. Each entry has either a mitigation or an accepted risk with a named owner.
• Health checks test real dependencies, not just that the process is alive.

2. Data and recovery

• Backups run on a schedule, and a restore has actually been performed into a clean environment. An untested backup is not a backup.
• Recovery point and recovery time objectives are written down and agreed with the business, not assumed by engineering.
• Database migrations are reversible, or the forward-only path has been rehearsed.
• Personal data is inventoried, and deletion requests can be honoured across every store that holds it, including logs, caches and analytics.

3. Observability

• Logs are structured and centrally searchable, and they do not contain credentials, tokens or personal data.
• Dashboards exist for the handful of metrics that actually indicate user pain: error rate, latency at the tail, queue depth, saturation.
• Every alert routes to a person who is awake and empowered to act. Alerts that nobody can action are deleted, not muted.
• You can answer “what changed?” within minutes, because deploys are correlated with the metrics.

4. Security

• No secrets in source control, in environment files committed to the repo, or in client-side code. Rotation has been tested at least once.
• Authentication and authorisation are enforced server-side on every route, including the ones nobody links to.
• Dependencies are scanned, and there is a named owner for acting on findings within an agreed window.
• Access to production follows least privilege, and there is a leavers process that revokes standing credentials, including API tokens and application passwords, not just logins.
• TLS certificates and domain registrations have expiry monitoring. A surprising number of outages are simply an expiry nobody was watching.

5. Performance and capacity

• The system has been load tested at a realistic multiple of expected peak, with realistic data volumes rather than an empty database.
• Slow queries have been profiled against production-sized data. An index that is unnecessary at a thousand rows is mandatory at ten million.
• Autoscaling limits and cost ceilings are set deliberately, so a traffic spike cannot become an unbounded invoice.

6. Release and rollback

• Deployment is automated and repeatable. If it only works when one particular person runs it, it is not ready.
• Rollback has been performed successfully in a rehearsal, not just documented.
• Feature flags allow risky changes to be disabled without a redeploy.
• There is a defined change window and a named release owner for the first period after launch.

7. Ownership and operations

• The service has a named owning team. “Everyone” means nobody.
• An on-call rotation exists, with an escalation path and a runbook for the three most likely failures.
• Third-party support contracts and their response times are known before you need them.
• A post-incident review process exists and is blameless, so people report problems early.

Using this as a gate

Score each section red, amber or green with evidence attached. Red items block the launch. Amber items need a named owner and a date. Green means someone has demonstrated it, not that someone believes it. The value of the review is entirely in refusing to accept assertions without evidence.

If you would like a second pair of eyes on a system before it goes live, talk to our engineers. We run this review against your architecture, your data and your team’s actual operational reality, and hand you a prioritised list of what to fix first.