Make production readiness a review of evidence

Reviewed: 2026-09-06

A production-readiness review should approve demonstrated operating capability, not completed checkboxes. Before a service joins an on-call rotation, its team should show who owns it, how failure is detected, how impact is limited, and how recovery was exercised.

Ask for artifacts that operators can use

Ownership evidence is a current service catalog entry with primary team, escalation route, repository, deployment target, data owner, and dependency contacts. Page the listed route during the review. An untested alias is not ownership.

Reliability evidence begins with user-facing service-level indicators and objectives. Show the query behind each indicator, current data, alert thresholds, and an example of the alert reaching the correct responder. The Google SRE guidance on the evolving engagement model describes production readiness review as a prerequisite for an SRE team to accept responsibility for managing a service’s production aspects, within a broader service-lifecycle engagement model.

Capacity evidence is a load test or production analogue tied to expected demand. Include the bottleneck, safe operating limit, scaling trigger, quota headroom, and what degrades first. “Autoscaling enabled” says little if a database connection pool or vendor quota fails earlier.

Dependency evidence is a map of synchronous and asynchronous dependencies with timeouts, retry limits, circuit behavior, and owners. Demonstrate what users see when the most critical dependency is slow or unavailable.

Prove deploy and recovery paths

Show one normal deployment from an auditable artifact and one rollback or forward-fix exercise. Record how long each took and what state could not be reversed. For schema changes, explain compatibility across the versions that can coexist during rollout.

Backups count only after a restore. Demonstrate recovery into an isolated environment, verify representative records, measure recovery time, and identify the acceptable data-loss window. For queues and object stores, document recovery too; a database backup does not cover every durable component.

Classify stored and transmitted data, identify retention and deletion paths, and show that logs and traces avoid credentials and unnecessary personal data. Confirm which operational roles can access production and how emergency access expires.

A witnessed failure exercise ties the artifacts together. Terminate an instance, block a dependency, exhaust a safe quota in staging, or inject latency. The reviewer should see dashboards change, an actionable page fire, the runbook lead to a decision, and recovery restore the indicator. The related articles on runbook verification and decay and dependency-failure game days are useful follow-on reading, but the review itself should require direct observation.

Make on-call sustainable

The Google SRE workbook’s on-call chapter emphasizes balanced pager load, adequate staffing, and support through procedures and escalation paths for on-call engineers. Evidence should therefore include a staffed rotation, paging-volume estimate, and clear escalation and operating procedures. We also recommend a shadowing or training plan and tested production access before a new service lands on the pager.

Review two runbooks by scenario. Each should start with user impact and immediate safety checks, then offer diagnostic branches, mitigation, escalation, and verification. A command dump with no decision points will fail during stress.

Dashboards should align with symptoms an operator can act on: request success, latency, saturation, backlog age, dependency health, and recent changes. Every page needs a linked dashboard and runbook. Every dashboard does not need a page.

Record gaps as explicit risk

Not every service needs the same bar. An internal cache and a payment ledger have different recovery and data requirements. The review should document applicable risks, evidence, exceptions, owner, and expiry date. An exception without an owner and deadline silently becomes architecture.

Use a short decision record containing service version, reviewers, artifacts, exercises observed, open risks, and the date of the next review. Repeat readiness checks after major changes in traffic, ownership, dependencies, data classification, or recovery design.

Schedule a short dependency-failure game day before adding the service to the pager. Require the team to detect one injected failure, mitigate it from the runbook, and attach the timeline and measured recovery to the readiness record.