The operational readiness review decision record: why the production launch checklist you chose determines your new-service incident probability and your service ownership accountability surface

A 37-person B2B SaaS company built a resource and project planning platform for professional services teams. The engineering organization of 16 engineers had been running for two years with a deployment culture that the VP of Engineering described as "high trust, low ceremony." The founding senior engineers — three staff engineers and a VP — had spent the first year establishing a set of informal pre-launch practices that they applied before merging any significant service: they would spend 30-60 minutes reviewing the deployment runbook, confirm that alerts had been wired to the on-call rotation, walk through the service's failure modes with the author, and do a quick load test if the service was on the critical path for any customer-facing flow. This informal checklist was never written down. It existed in the institutional knowledge of the four founding senior engineers, transmitted to the engineers they hired through code review feedback, pairing sessions, and the occasional post-incident retrospective where a gap in the pre-launch practices had contributed to an incident. The informal standard was effective. In the company's first 18 months of production operation, the mean time to detect a production incident was 4 minutes and the mean time to resolve it was 23 minutes — well within the P1 response targets the company had set for enterprise customers.

Over the next 14 months, the team grew from 16 to 37 engineers. The VP of Engineering moved into a pure leadership role and stopped reviewing code. Two of the three staff engineers moved into engineering manager roles and significantly reduced their code review throughput. One left the company. The institutional knowledge of the informal pre-launch standard was held by people who were now less present in the day-to-day of service development. Engineers hired in the second year of the company's operation had been onboarded into a culture where the informal standard existed in theory but was not reliably transmitted. Some of the new engineers had strong operational backgrounds and applied rigorous pre-launch practices on their own initiative. Others were product-focused engineers who had come from companies where deployment was a push-the-button activity and pre-launch operational review was not part of their professional practice.

A Refund Processing service was built over a 6-week period by two mid-level engineers, both hired in the company's second year. The service was responsible for calculating customer refund amounts, submitting refund requests to the payment processor, and updating the billing database with the refund status. It was a critical-path financial service — a failure in Refund Processing affected customer billing accuracy directly. The service was deployed to production in the 18th month of the company's operation. The two engineers who built it went through their team's deployment checklist, which covered code review, CI passing, and a quick smoke test of the primary happy path. Neither engineer had a senior engineer walk them through a pre-launch operational review. The VP of Engineering was not involved in the deployment because the team lead had approved it. The service had no load testing — it had been designed to handle the current refund volume, which was modest, and neither engineer had considered what would happen at end-of-month billing cycle peaks when refund requests clustered. It had no runbook. It had basic application logging but no structured logs with trace IDs, no per-operation latency metrics, and no error rate dashboard beyond what the default Kubernetes container metrics provided.

The service ran without incident for six weeks. The refund volume during that period was low and steady — 30-50 refund requests per day, well within the service's comfortable operating range. In week 7, the end-of-quarter billing cycle generated 7× the normal refund volume over a 4-hour window as enterprise customers processed quarterly billing adjustments. The Refund Processing service began queuing requests. The database connection pool — configured with a maximum of 10 connections for what had been expected to be a low-traffic service — reached saturation within 22 minutes. New refund requests began timing out. The customer billing API began returning 503 errors for refund submissions. An alert fired on the customer billing API's error rate, but the alert routed to the billing API's on-call engineer, not to the Refund Processing service's owning team, because Refund Processing had no alert routing configured. The on-call engineer opened the billing API dashboard and found the API was healthy. She checked the downstream service call logs and found timeouts to Refund Processing. She opened the Refund Processing metrics dashboard and found nothing — no service-specific metrics were emitted. She read the application logs and found unstructured Java stack traces with connection pool exhaustion errors that were repeated across thousands of log lines with no request IDs to correlate them to specific customer refund submissions. She searched the engineering wiki for a Refund Processing runbook and found none. Connect this pattern to the service observability ownership decision record: the observability ownership decision specifies who is responsible for ensuring each production service meets the minimum instrumentation standard before launch; the operational readiness review is the enforcement point at which that responsibility is verified; when the readiness review is informal and held in the institutional knowledge of senior engineers who are no longer reviewing each deployment, the observability requirement — like every other requirement — is transmitted only to engineers who happen to work alongside those senior engineers, and the gap between services that meet the standard and services that don't grows invisibly until an incident reveals it.

The on-call engineer escalated to the Refund Processing team at 22:15. The two engineers who built the service spent 47 minutes diagnosing the connection pool exhaustion before identifying the fix. The database connection pool was increased and the service was redeployed. Refund request processing resumed at 23:02 — 3.2 hours after the first timeout. The post-incident review identified the informal pre-launch standard as the root cause: the service had been deployed without the operational verification that the founding engineers would have performed, and no formal process had been in place to require it. The VP of Engineering commissioned a production readiness checklist. The checklist was written by the two remaining original staff engineers and specified 47 items covering observability, load testing, runbook, rollback verification, dependency failure analysis, and service ownership. The first version of the checklist was 6 pages long.

A 52-person developer tools company built a static analysis platform — automated code quality scanning, dependency vulnerability detection, and test coverage enforcement distributed as a CLI and CI/CD integration. After a production incident in month 22 of operation — a database migration gone wrong that took the primary analysis API offline for 4.7 hours — the VP of Engineering mandated a formal production readiness review process for all new services. The process was designed by the senior engineering team over two weeks and produced a 47-item checklist organized across eight categories: observability (8 items), load testing (6 items), security (5 items), data management (6 items), runbook and documentation (7 items), rollback and recovery (5 items), dependency analysis (4 items), and service ownership (6 items). The checklist was intended to be comprehensive. The VP of Engineering's stated goal was "no more surprises in production that a 30-minute review would have caught."

The process was applied to the next four new services without modification. The results were mixed. The first two services — both low-traffic internal tooling services built by the founding engineers — completed their PRRs in 4 and 5 days respectively. The third service — a new Webhooks Delivery service that would handle customer-configured outbound webhook notifications for build events — required 19 days. The 19 days included 4 days of actual verification work and 15 days of coordination overhead: scheduling the security review with the security engineer (who had a 3-week calendar backlog), getting a second engineer to review the load test artifact (the only engineer with available capacity was on a team that had no context on the webhooks domain and took 2 days to review a document that took 20 minutes to write), and getting the VP of Engineering's sign-off for the final checklist submission (a calendar constraint). The Webhooks Delivery service engineer sent a Slack message to the VP of Engineering in week 3: "I want to flag that 14 of the 47 checklist items don't apply to a webhooks service at all — there's no database, no schema migration, no read replica, no data retention policy, nothing related to financial data. Can we skip those? Also items 23 and 24 are duplicates with different phrasing." The VP of Engineering approved skipping 10 items and merging the duplicates. The effective checklist for the Webhooks Delivery service was 35 items.

At month 7 of operation after the Webhooks Delivery service launched, a customer reported that webhook notifications for build events had stopped arriving at their configured endpoints. Investigation revealed that the delivery queue had backed up — 14,000 undelivered webhook events were queued, with the queue depth growing by approximately 2,400 events per hour. The service's worker processes were timing out on delivery attempts to customer endpoints that were returning 429 Too Many Requests — the webhook delivery service had no rate limiting on outbound delivery attempts, and a single customer's endpoint returning 429s was consuming worker capacity that should have been distributed across all customers' endpoints. The on-call engineer opened the Webhooks Delivery service's observability dashboard and found the queue depth metric and the delivery success rate metric, both correctly configured. The queue depth had been growing steadily for 6 hours before the customer report — 6 hours in which the queue depth alert should have fired but had not. The alert had been configured in staging but not promoted to the production alert routing. The production alert routing configuration was checklist item 3c: "Alerts configured and routing verified in production environment." The checklist had a checkmark next to item 3c. The artifact field contained a link to the staging alert configuration. The engineer who signed off on item 3c had checked the staging configuration, not the production configuration, and had not specified in the artifact whether the verification was production or staging. Connect this pattern to the alerting threshold decision record: the alerting threshold decision specifies which signals trigger alerts and at what sensitivity; the readiness review is the enforcement point at which alert configuration is verified before the service enters the on-call rotation; when the readiness checklist item for alert verification does not specify what counts as adequate verification — which environment, what test, what artifact — the verification gap is invisible until the alert fails to fire in a production incident and the post-incident review reveals that the checklist item was signed off against the wrong environment.

The second load testing finding was more damaging. Checklist item 17a specified: "Service load tested to 2× expected peak traffic volume with results documented." The artifact for item 17a was a PDF report titled "Webhooks Delivery Load Test — Pre-Launch." The report documented a test that had run for 60 seconds at 1× the expected average traffic volume. The engineer who signed off on item 17a was a senior engineer from a different team who had been assigned the load test review because he was the only engineer available during the review window. He had 20 minutes between two meetings, reviewed the PDF, noted that a test had been run and results had been documented, and signed off. He had not checked whether the test had run at 2× expected peak (it had run at 1×), whether the 60-second duration was sufficient (it was not — the rate limiting failure mode that caused the incident was a slow accumulation pattern that would not appear in a 60-second test), or whether the artifact demonstrated what the checklist item required (it did not). The readiness checklist had provided a false signal that the Webhooks Delivery service had been adequately load tested. The post-incident review found 8 of the 35 applicable checklist items where the sign-off artifact did not demonstrate what the item specified. The VP of Engineering's response was to add more specificity to each checklist item. The checklist grew to 51 items and the average review time increased to 25 days.

A 45-person fintech company built a payments and billing orchestration platform for marketplace operators. The engineering team of 21 engineers operated two categories of services: customer-facing payment processing services (the Payments API, the Settlement Engine, the Reconciliation Service, and the Fraud Detection service) and internal operational services (the Analytics Dashboard, the Fee Calculator, the Merchant Reporting tool, and several data pipeline services that fed the analytics infrastructure). The company had adopted a production readiness checklist 8 months into its operation after a founding engineer read a Google SRE chapter on PRRs. The checklist had 22 items and applied uniformly to all services regardless of their risk profile. Items included: load tested to 2× expected peak, runbook written and reviewed, alerts configured and firing in a test environment, rollback procedure executed in staging, error budget policy documented, dependency failure modes specified, and service owner named in the on-call rotation.

For the Payments API and the Settlement Engine — services where a production incident meant immediate financial impact for customers — the 22-item checklist was in retrospect too light. The checklist had no item for payment-specific failure modes: what happens if the downstream payment processor returns a timeout, what happens if a settlement batch is partially processed and the service is restarted mid-batch, what the reconciliation procedure is if a discrepancy is discovered between the internal transaction ledger and the payment processor's settlement report. These payment-specific failure modes were not in the generic checklist because the checklist was designed to be applicable to all services, and most services had no transaction ledger. The engineers who built the Payments API knew these failure modes mattered but there was no checklist item to prompt them to specify and test the behavior, and the peer reviewer signing off on the checklist had no way to know whether the payment-specific behaviors had been analyzed and tested because no item asked about them.

For the Analytics Dashboard and the internal operational services — services where a production incident meant an internal reporting delay with no customer-facing impact — the 22-item checklist was over-specified. The Analytics Dashboard had no SLA, no financial data, no customer-facing surface, and traffic from a maximum of 40 internal users. Requiring a load test to 2× expected peak traffic for a service whose peak traffic was 8 concurrent users viewing a dashboard was a ceremony without substance. Requiring an error budget policy for a service with no SLA was a document that the author would write and no one would use. The engineers building internal services learned, through experience, that the hard items on the checklist — load testing, dependency failure mode specification, rollback execution in staging — consumed the most time and were the items that checklist reviewers were most likely to approve without scrutiny. The rational response to a uniform checklist whose hard items applied to some services but not others was to do the minimum required to produce an approvable artifact for each hard item, defer the hard items to post-launch milestones when calendar pressure permitted, or frame the artifact ambiguously enough that it satisfied the item's wording without satisfying its intent. These behaviors were not malicious — they were the rational adaptation to a process that imposed uniform overhead regardless of service risk.

The deferral behavior that had developed for internal services transferred to the customer-facing services. An engineer who had internalized that "load tested to 2× expected peak" could be satisfied with a 60-second test at 1× load because that was how she had always passed the item brought the same interpretation to a Payments API extension she built. An engineer who had deferred the "dependency failure modes specified" item to a post-launch milestone for three consecutive internal service launches deferred it for a Settlement Engine feature that introduced a new dependency on the Fraud Detection service. The checklist behavior learned on low-risk services was being applied to high-risk services because the checklist made no distinction between them. Connect this pattern to the deployment rollback decision record: the rollback decision specifies the mechanism and procedure for reverting a deployment when production problems occur; the operational readiness review's rollback verification item specifies that the rollback procedure has been executed at least once in a non-production environment; when the rollback verification item is rubber-stamped rather than verified — because the engineer building a low-risk service rubber-stamped it and the behavior carried over to a high-risk service — the rollback procedure is a hypothesis rather than a tested procedure, and the first time the procedure is executed is in a production incident under time pressure with a customer watching.

The deferral pattern became visible 7 weeks after a Payments API extension was launched with two critical alert conditions marked as "planned post-launch" in the runbook. The extension added a new payment method (ACH bank transfers) with a 2-5 business day settlement window. Alert condition 1 was an alert on ACH transactions that had been submitted to the payment processor but had not received a settlement confirmation within the expected window — a signal that would indicate either a payment processor issue or a data processing bug. Alert condition 2 was an alert on the settlement reconciliation job that ran nightly to verify that the internal ledger matched the payment processor's settlement report. Both conditions required understanding the ACH settlement flow well enough to specify the alert threshold, which was deferred because the flow was still being finalized when the readiness review happened. The alerts were in a backlog item. The backlog item had no due date because the launch happened and the engineer moved to the next project.

Seven weeks after launch, a payment processor issue caused 34 ACH transactions to be submitted successfully but not settled — the processor acknowledged receipt but the settlement confirmation was never sent. Alert condition 1 would have fired within 4 hours of the settlement window expiring. It was not configured. The nightly reconciliation job detected the discrepancy at 02:00 — alert condition 2 would have triggered a P2 escalation to the payments team at that point. It was also not configured. The discrepancy was discovered by a customer support ticket at 09:30, 7.5 hours after the reconciliation job detected it and 31 hours after the settlement confirmation should have arrived. The post-incident review found the "planned post-launch" notes in the runbook, traced the deferral back to the readiness checklist sign-off, and identified 4 other services with unresolved "planned post-launch" items in their runbooks that had been signed off on checklist items that required completed alert configuration. Connect this pattern to the incident postmortem culture decision record: postmortem findings about items that were rubber-stamped in the production readiness review are not individual attribution findings — they are systems findings that point to a flaw in the readiness process itself; the readiness process allowed the deferral behavior to develop because it imposed uniform overhead on all services, made the hard items indistinguishable from the easy ones, and specified checklist items in terms that permitted approvable artifacts that did not demonstrate compliance; fixing individual engineers' behavior without fixing the process produces temporary improvement until the next engineer learns the same rational adaptation.

Structural properties set by the operational readiness review decision

Three structural properties are determined by the decisions — often made informally, incrementally, or by default — about what the operational readiness standard requires, who verifies it, and whether it distinguishes between service risk levels. None of these properties are visible in the deployment frequency metric, the sprint completion rate, or the service count. They are established by whether the readiness standard creates real pre-launch verification or review theater, whether the accountability model ensures that sign-offs reflect actual compliance, and whether the risk stratification model aligns checklist rigor with the services where it has the most protective value.

Property 1: The new-service incident probability multiplier. Every engineering organization that deploys services has a baseline production incident rate for established services — services that have been in production long enough to have absorbed operational learning, stabilized their configuration, and built up a runbook that reflects real failure modes rather than hypothetical ones. New services have a higher incident rate in their first 30-60 days because they lack that operational learning: the connection pool sizing that seemed correct in development turns out to be wrong at production traffic, the load test that ran at average traffic did not reveal the behavior at peak traffic, the dependency that returns 429s infrequently in staging returns them frequently enough at production scale to require a retry strategy that was never implemented. The operational readiness review's purpose is to reduce this new-service incident probability multiplier by requiring pre-launch verification of the failure modes that are predictable — load behavior, dependency failure handling, alert coverage, rollback procedure — before the first production traffic runs through the service. The multiplier is not reduced by requiring verification; it is reduced by requiring verification that is actually performed. A readiness checklist that permits rubber-stamped sign-offs does not reduce the multiplier because the failure modes that were predictable were not actually verified. Connect this property to the service observability ownership decision record: the observability ownership decision specifies who ensures each service meets the minimum instrumentation standard; the operational readiness review is the enforcement gate at which that standard is verified before launch; the monitoring coverage gap — uninstrumented services in production — is a function of how rigorously the observability item in the readiness checklist is verified, not merely whether the checklist item exists; a checklist that requires 'alerts configured and routing verified' but allows artifacts that document staging configuration as evidence of production verification produces the same monitoring coverage gap as having no checklist item at all, because the gap is in the verification standard, not in the item existence.

Property 2: The accountability surface ambiguity. Every production readiness checklist specifies what must be done, but the specification gap that determines the checklist's effectiveness is not in what is listed but in who verifies each item and what adequate verification consists of. A checklist item that says "load tested to 2× expected peak" can be satisfied by a 60-second test at 1× load if the item does not specify test duration, load level, failure threshold, and required artifact. A checklist item that says "alerts configured" can be satisfied by staging configuration if the item does not specify that production routing must be verified. The accountability surface ambiguity is the fraction of checklist items where the verification requirement is ambiguous enough that a reviewer can sign off without performing actual verification — and where, if that item's gap causes a production incident, the post-incident review cannot determine whether the sign-off was negligent or whether the signer followed the item specification as written. The ambiguity is not the fault of the reviewer; it is the fault of the item specification. An ambiguous item transfers accountability from the process to the individual reviewer's judgment, and individual reviewer judgment is variable across reviewers, service contexts, and launch pressure conditions. Connect this property to the runbook quality decision record: the runbook quality decision specifies how runbooks are written and maintained; the operational readiness review's runbook item specifies that a runbook exists before launch; both decisions share the same accountability surface ambiguity failure mode — if the runbook item says 'runbook written and reviewed' without specifying what a complete runbook contains, how review is conducted, and what artifact proves completion, engineers will write the minimum-viable runbook that passes review rather than the runbook that provides operational utility during an incident; the runbook quality standard and the readiness checklist's runbook item must be written together, with the checklist item referencing the quality standard, to ensure that the checklist item verifies the quality standard rather than verifying only that a document with the word 'runbook' in the title exists.

Property 3: The risk stratification ceiling. A production readiness standard that applies identically to all services regardless of their traffic volume, data sensitivity, blast radius, and operational complexity creates a ceiling on the standard's effectiveness in two directions simultaneously. For low-risk services — internal tooling, administrative dashboards, low-traffic supporting services — the uniform checklist imposes overhead without proportionate risk reduction. The overhead is real: load testing a service whose peak traffic is 8 concurrent users, writing an error budget policy for a service with no SLA, executing a rollback procedure in staging for a service where a rollback consists of reverting a single environment variable — these take engineering time that has near-zero protective value relative to the service's actual production risk. Engineers who regularly build low-risk services learn that many checklist items are overhead without value for their service type, and they adapt by minimizing the time spent on those items. The adaptation habit transfers to high-risk services because the checklist provides no signal that the same items have different significance for high-risk services. For high-risk services — payment processing, authentication, financial data management — the uniform checklist is under-specified on the items most critical to the service's specific risk profile. A payment processing service needs a payment-specific failure mode analysis, a partial-processing recovery procedure, and a financial reconciliation verification step that do not appear in a generic checklist because they are not applicable to most services. The risk stratification ceiling is the ceiling on the checklist's effectiveness produced by treating high-risk services as generically as low-risk ones while simultaneously taxing low-risk services with high-risk overhead. Connect this property to the deployment strategy decision record: the deployment strategy decision specifies how services are deployed — canary, blue-green, rolling, or direct cutover; the operational readiness review's rollback and deployment strategy items should specify that the deployment strategy is appropriate for the service's risk tier; a payment processing service launching with a direct cutover strategy requires a different rollback plan than a low-traffic internal service launching with the same strategy; a uniform checklist that does not distinguish between service risk tiers cannot require that the deployment strategy be calibrated to the risk level of the specific service being launched.

The operational readiness review ADR: five sections

Section 1: The service risk tier classification. Begin the operational readiness review decision record by specifying the criteria by which each service is classified into a risk tier before its readiness review begins. The tier classification criteria should be specified in terms that can be evaluated without expert judgment: traffic volume (services above a specified RPM threshold at projected peak), SLA status (services with a committed uptime SLA), data sensitivity (services that process, store, or transmit financial data, authentication credentials, or personal data), blast radius (services whose failure causes customer-facing impact or cascading failures in other tier-1 services), and deployment frequency (services that are deployed more than once per week and where deployment-related incidents are a significant fraction of total incidents). The classification should be binary — tier 1 or tier 2 — or at most ternary (tier 1, tier 2, tier 3), because more tiers create classification disputes without proportionate improvement in calibration. Three tiers is the maximum complexity that can be maintained without dedicated process overhead to manage classification edge cases. The classification is made before the readiness review begins — not during the review — and is made by the service owner in consultation with a platform team engineer for any service where the owner is uncertain. The classification decision should be logged in the service registry alongside the readiness checklist artifacts, so that the post-launch incident attribution process can evaluate whether the tier assignment was correct and whether the assigned tier's checklist requirements were sufficient to prevent the incident that occurred. Connect this section to the incident response playbook decision record: the incident response playbook specifies how incidents are triaged and escalated; the tier classification in the operational readiness review should use the same severity taxonomy as the incident response playbook — a service classified as tier 1 (critical) in the PRR should map to the service types that generate P1/P2 incidents in the incident response playbook, so that the readiness standard's rigor is calibrated to the same risk level that the incident response process is designed to handle.

Section 2: The minimum production readiness standard per tier. Specify, for each tier, the complete list of readiness requirements with their verification specifications stated in terms that are mechanically verifiable rather than qualitatively interpretable. For each item, the specification must include: what must be done (the requirement), what counts as adequate evidence (the artifact specification), who is responsible for producing the artifact (the author), and who is responsible for verifying the artifact meets the specification (the reviewer). The artifact specification is the most critical component: it is the difference between "load tested to 2× expected peak" (verifiable only if the reviewer examines the test parameters and duration) and "load test report committed to the service repository showing: (a) test load of at least 2× projected peak RPM sustained for at least 15 minutes, (b) error rate below the service's SLA threshold throughout the test, (c) p99 latency below the service's SLA threshold throughout the test, and (d) the engineer's written interpretation of any anomalies observed during the test." The more specific the artifact specification, the harder the item is to rubber-stamp and the less reliant verification is on reviewer judgment under time pressure. For tier 1 services, include service-type-specific items that are not applicable to all services: payment-processing failure mode analysis for financial services, authentication fallback behavior for identity services, data recovery procedure for services that own a primary database. These items should be specified in the tier 1 checklist even though they are not universally applicable, with a clear notation that they are required for services of the specified type — the specificity signals to the reviewer that these items require active evaluation, not a checkbox. Connect this section to the service observability ownership decision record: the minimum observability standard from the observability ownership decision record should appear in the operational readiness checklist as a reference, not a re-statement — "service meets the minimum observability standard defined in [link to observability ownership decision record] as verified by [specific artifact: link to dashboard showing required metric names emitting data in production, screenshot of alert routing in production environment]"; this cross-reference ensures the readiness checklist's observability item stays current as the minimum observability standard evolves, rather than drifting independently.

Section 3: The review ownership and accountability model. Specify who performs the readiness review for each tier, what the reviewer's accountability consists of, and how the accountability is documented. For tier 3 services (critical), require a cross-functional review: the service owner verifies the artifacts they produced, a platform engineer reviews the observability and deployment items, and a senior engineer from a different team reviews the failure mode analysis and the load test report. The cross-functional reviewer's accountability is explicit: by signing off, they attest that the artifact meets the item specification as written, not merely that an artifact exists. The sign-off should include the reviewer's name, the date, a link to the specific artifact version reviewed, and a one-sentence statement of what they verified — not just a checkbox. For tier 2 services (standard), require a peer review: a second engineer from the same team reviews the artifacts and signs off. The peer reviewer's accountability is lighter but still artifact-linked: they sign off on the specific version of each artifact. For tier 1 services (low risk), self-review by the service owner is acceptable for most items, with a platform engineer reviewing the on-call routing configuration as the one item that requires an external second set of eyes. The accountability documentation — who reviewed what artifact at what version — should be committed to the service repository alongside the readiness artifacts, not stored in a separate tracking system. When the post-incident review needs to determine who signed off on item 3c and what they verified, the answer should be in the service repository, not in a calendar invitation or a chat message. Connect this section to the on-call rotation design decision record: the on-call rotation design specifies who is responsible for responding to production incidents; the operational readiness review's service ownership item specifies that a named owner is registered in the on-call rotation before the service enters production; these two decisions must be co-authored — the readiness checklist should require that the service's on-call routing has been tested (a test alert has been fired and confirmed to route to the correct on-call engineer) rather than merely configured, and the on-call rotation design should specify the readiness checklist as the mandatory onboarding path for any new service added to the rotation.

Section 4: The launch gate enforcement mechanism. Specify how the completion of the readiness checklist is enforced before the service enters the on-call rotation and before production traffic is routed to it. Two enforcement mechanisms can be combined. The first is a technical gate in the deployment pipeline: a deployment pipeline check that verifies the readiness checklist has been completed and all artifacts have been committed to the service repository before the deployment to the production environment proceeds. This gate is binary — the deployment cannot proceed without the checklist completion artifact. The gate does not verify the quality of the artifacts, only their existence; quality verification is the reviewer's responsibility. The gate prevents the most common enforcement failure: a service where the review is "in progress" being deployed anyway under launch pressure with the intention of completing the review retroactively. The second mechanism is a service registry gate: the on-call routing for the service is not activated until the readiness checklist artifacts have been reviewed and signed off. This gate is the quality gate — it is the point at which a reviewer (or the platform team) confirms that the artifacts meet the item specifications. A service can exist in production without on-call routing for a defined window (24-48 hours is typical for staged deployments that begin with internal traffic before opening to customers), but the on-call routing activation is conditional on the review completion. Specify both gates in the decision record: the deployment pipeline gate prevents launch without artifacts, and the on-call routing gate prevents launch without review. Connect this section to the deployment strategy decision record: the deployment strategy specifies the mechanism by which code transitions from staging to production (canary release, blue-green, rolling, direct cutover); the readiness review's launch gate should specify whether it applies at the point of initial deployment to production or at the point of routing live customer traffic, which differ for canary and blue-green deployments; for a canary deployment, the readiness checklist may be completed before the canary is deployed (with canary traffic as the test environment) or at the point of full traffic promotion, and the decision record should specify which model applies to avoid the deployment gate being circumvented by deploying a canary with full traffic routing before the review is complete.

Section 5: The post-launch monitoring window and incident attribution process. Specify the period after a new service's launch during which its incident rate is tracked separately from the organization's baseline incident rate, and the process by which production incidents occurring within that window are attributed back to specific readiness checklist items. The monitoring window is the mechanism that makes the readiness process self-correcting: it provides the feedback loop that reveals which checklist items are consistently associated with first-30-day incidents (underspecified, rubber-stampable, or missing entirely) and which items are consistently adequate. The window length should be long enough to cover the full range of new-service failure modes: 30 days covers most load-related failures and many integration failures, but some failure modes — seasonal load patterns, end-of-quarter billing cycles, dependency behavior under specific conditions — may not appear within 30 days for low-traffic services. A 60-day window is more thorough; the operational cost of tracking a service's incident rate for 60 days is low enough to be worth the additional coverage. The attribution process should be specified in the post-incident review template as a standard section for services within their monitoring window: "Was this incident in a service within its 60-day monitoring window? If yes, which readiness checklist items, if fully verified rather than rubber-stamped, would have prevented or significantly shortened this incident?" The attribution findings should be reviewed quarterly by the platform team and the VP of Engineering — not to assign blame to reviewers but to identify patterns in which items are consistently associated with first-30-day incidents and update the checklist specifications to make those items harder to rubber-stamp. Connect this section to the incident postmortem culture decision record: the postmortem culture decision specifies the blamelessness model and the systems attribution approach for root cause analysis; the operational readiness attribution process is a direct application of that model — when a service in its monitoring window causes a production incident, the systems finding is that the readiness process permitted a service to launch without adequate verification of the failure mode that caused the incident, and the action item is a change to the readiness process rather than a reprimand to the engineer who rubber-stamped the item; the postmortem culture and the readiness attribution process must be designed together, because a blameless postmortem culture that does not feed findings back into the readiness process improvement cycle is a culture that learns from individual incidents but does not improve the system that permitted those incidents to occur.

FAQ

Further reading

• Service observability ownership decision record — the observability ownership decision specifies who ensures each production service meets the minimum instrumentation standard; the operational readiness review is the enforcement gate at which observability compliance is verified before launch; the monitoring coverage gap — uninstrumented services in production — is a direct function of how rigorously the observability item in the readiness checklist is verified; when the two decisions are not written together, the readiness checklist's observability item drifts from the observability standard as each evolves independently, and the checklist begins verifying an older or lighter version of the standard than the one the organization currently requires.
• Runbook quality decision record — the runbook quality decision specifies how runbooks are written, reviewed, and maintained; the operational readiness review's runbook item specifies that a runbook exists before launch; these two decisions must reference each other to be effective — the readiness checklist's runbook item should require that the runbook meets the runbook quality standard, not merely that a document exists, and the quality standard should specify the minimum content requirements that the checklist reviewer uses to evaluate the runbook; without this cross-reference, the readiness review produces the minimum-viable runbook that passes the existence check while the quality standard specifies a thorough runbook that would actually be useful during an incident, and the gap between the two is the gap that costs on-call engineers diagnostic time in the next first-30-day incident.
• Deployment rollback decision record — the rollback decision specifies the mechanism and procedure for reverting a deployment; the operational readiness review's rollback verification item specifies that the procedure has been executed at least once in a non-production environment before the service enters production; the two decisions must be calibrated to the same risk tier — a critical service requires a rollback procedure that has been executed under realistic conditions (realistic data volume, realistic failure scenario) rather than a trivially short staging environment test; when the rollback verification item does not specify what 'verified in staging' means in terms of conditions and duration, the gap in the item specification produces the same false confidence in the rollback procedure that the load test artifact gap produces for load behavior.
• Incident postmortem culture decision record — the postmortem culture decision specifies the blamelessness model and the systems attribution approach; the operational readiness attribution process — when a service in its monitoring window causes an incident, which checklist items would have prevented it — is a direct application of that model to the readiness process itself; a blameless postmortem culture that attributes first-30-day incidents to individual reviewer negligence rather than to readiness process gaps will not improve the process, because the finding produces a behavior change in individuals rather than a specification change in the items that were rubber-stampable; postmortem culture and readiness attribution must be designed together so that the feedback loop from incident to process improvement is explicit and owned by the process owners, not the incident participants.
• Open-source extractor — the operational readiness review decision is consistently buried in AI chat history; the conversations where a VP of Engineering and the platform lead debated what the checklist should require, which items were blocking versus advisory, whether tier stratification was necessary or over-engineering, what counted as adequate evidence for the load testing item — those conversations happened in ChatGPT or Claude because they are exactly the kind of open-ended trade-off discussions that benefit from a thinking partner; the written output of those conversations is a checklist document or a policy PDF that records the decisions but not the reasoning behind the verification specifications, the accountability model, or the tier boundaries; when the checklist needs to be updated because a first-30-day incident revealed that an item was rubber-stampable, the engineer updating the item cannot recover the original rationale for the item's specification from the policy document alone; the reasoning is in the chat history, and the extractor surfaces it.