Production Readiness Review
What a service owes before it carries traffic. Set a status against each dimension and write down what you would point at to justify it — that second half is the whole exercise, because a dimension you cannot produce evidence for is UNKNOWN, not READY.
No total, no percentage, no traffic-light average. A score gets optimised, and the cheapest way to raise one is to lower the bar on the dimensions that are hardest to prove — which are reliably the ones that matter in an incident. A status per dimension, justified by evidence someone could go and check, gets fixed instead. UNKNOWN is a legitimate and useful answer; it is not a zero, and it is far more honest than a READY nobody can substantiate.
Is there a named team accountable for this service in production, with an escalation path that resolves to people who are actually reachable?
A service catalogue entry naming the owning team, an on-call rotation with names in it for the next four weeks, and a page that was routed and acknowledged by that rotation. A wiki page listing an individual who has changed teams is evidence of the opposite.
Can a small change reach production through an automated, repeatable path that anyone on the owning team can run?
The last ten deploys came from the pipeline rather than a laptop, the median time from merge to production is recorded, and someone other than the pipeline author has deployed successfully in the last month.
Do you know exactly what is running, where it came from, and can you get the previous one back?
The running version is identified by an immutable digest, that digest traces to a commit and a build with provenance, and the artifact it would roll back to still exists in the registry under the retention policy.
If the next release is bad, what is the way back, how long does it take, and when was it last exercised?
A rollback performed in the last quarter — in production, not staging — with the elapsed time recorded, plus a written statement of what currently makes rollback unavailable (an in-flight migration, data written in a new shape) if anything does.
Can an operator determine whether this service is healthy, and which version is responsible, without asking the team that wrote it?
A dashboard that answers request rate, error rate, latency and saturation, broken down by version, with deploy annotations on the same timeline. Someone outside the owning team has used it to answer a health question.
Does something page a human when users are affected, and does it stay quiet otherwise?
Alerts defined on user-visible symptoms, each linked to a runbook section; a count of pages over the last month and what fraction were actionable. A rotation that has received no alerts is UNKNOWN, not READY.
Is there a document that lets someone who did not build this service handle its known failure modes at 3am?
A runbook with concrete commands, decision points and escalation criteria, referenced from the alerts, and used during a real incident or a drill by someone who is not the author. Last-reviewed date within the last two quarters.
How much traffic can this take, what saturates first, and what happens when demand exceeds it?
A load test or a production measurement identifying the first bottleneck, the current headroom against peak, and a defined behaviour at the limit — shedding, queueing or degrading — that has been observed rather than assumed.
If the data is lost or corrupted, what is the recovery procedure and when did it last work?
A restore performed into a usable environment within the last six months, with the elapsed time and the data loss window recorded against the stated RTO and RPO. A backup job with green ticks and no restore is MISSING, not PARTIAL.
What does this service require to function, and what does it do when each of those is unavailable or slow?
A list of hard and soft dependencies, each with a configured timeout, retry policy and fallback behaviour, plus at least one exercise — a dependency failure injected in a test or observed in a real incident — showing the degradation is the intended one.
How does this service obtain credentials, who can reach production, and how is that access reviewed?
Credentials issued through workload identity or a secret manager with no long-lived secret in the repository or image; a list of humans with standing production privilege; the date of the last access review and what it removed.
How does a schema change reach production without downtime and without removing the way back?
Migrations run through the pipeline rather than by hand, a documented expand/migrate/contract practice, and a recent schema change that shipped without an incident and with the rollback path intact throughout.
Reading the result
The output of this exercise is a list of gaps, in the order you would fix them — not a rating. A service with one MISSING dimension it knows about is in better shape than one with twelve UNKNOWNs, and no arithmetic on those two lists produces a comparison worth having. Take the MISSING rows to the owning team as work; take the UNKNOWN rows to whoever should be able to answer them, because an unanswerable question about production is itself the finding.