Production Readiness Review English: Vocabulary for Launch Communication

Launching a service to production is a high-stakes moment that involves careful communication between engineers, SREs, and stakeholders. The Production Readiness Review (PRR) is a structured process for ensuring a service is ready, and it has its own vocabulary. Whether you are presenting a PRR, attending one as a reviewer, or writing the documentation for one, this guide covers the English you need.

Core Vocabulary

Production Readiness Review (PRR) A structured assessment process conducted before a new service or major feature is launched to production. A PRR typically covers reliability, scalability, observability, security, and operational runbooks.

“The PRR for the payments service is scheduled for Thursday — the team needs to have the runbooks, SLO definitions, and load test results ready before then.”

Launch criteria The specific, agreed requirements that a service must meet before it is permitted to go to production. Launch criteria turn abstract quality goals into concrete, measurable checkboxes.

“We have four outstanding launch criteria: the load test must pass, the runbook must be reviewed by the SRE team, SLOs must be defined, and the rollback plan must be documented.”

SLO (Service Level Objective) A target for service reliability or performance, expressed as a percentage or latency threshold over a time window. SLOs are typically defined as part of the PRR and monitored in production.

“Our SLO for the checkout service is 99.9% availability over a rolling 30-day window — that gives us about 43 minutes of allowed downtime per month.”

Runbook A documented set of step-by-step operational procedures for handling specific situations — such as a high error rate alert, a database failover, or a traffic surge. Runbooks are essential for on-call engineers responding to incidents.

“The runbook for the cache eviction alert walks through five steps: check the eviction rate, check memory usage, check for key expiry misconfiguration, scale the cache cluster, and notify the team.”

Rollback plan A documented procedure for reverting a deployment to the previous stable version if the new release causes problems. A clearly defined rollback plan is a standard PRR requirement.

“The rollback plan for this release takes about 8 minutes end-to-end — we need to retag the previous Docker image, update the deployment, and verify the health check passes.”

Load test A test that simulates expected production traffic volumes against a service to verify that it handles the load within acceptable latency and error rate limits. Load tests are usually required before a PRR can be approved.

“The load test showed the service handles 2,000 requests per second with p99 latency under 200ms — that’s well within our launch criteria.”

Chaos exercise A structured test that intentionally introduces failures — such as killing a replica, injecting network latency, or exhausting a connection pool — to verify that the system degrades gracefully and recovers automatically.

“We ran a chaos exercise that killed two of three database replicas — the service continued serving reads from the remaining replica and latency only increased by 40ms.”

Go/no-go decision The formal conclusion of a Production Readiness Review: either the service is approved to launch (go) or it is not approved and must address outstanding issues (no-go). This decision is typically made by the SRE team or a designated reviewer.

“The PRR review meeting ended with a go decision, contingent on the runbook being updated to include the cache eviction procedure before the actual deployment window.”

Key Collocations

• schedule the PRR — “Schedule the PRR at least one week before the target launch date so reviewers have time to read the documentation.”
• meet launch criteria — “We meet all launch criteria except one — the load test at 3x expected traffic is still failing at the database layer.”
• define rollback steps — “Define rollback steps in the runbook before the PRR, not after — reviewers need to see that the team has thought through failure scenarios.”
• run a load test — “We run a load test at 1x, 2x, and 3x expected peak traffic to understand the service’s limits, not just whether it works at normal load.”
• approve the go decision — “The SRE tech lead approves the go decision — without their sign-off, the deployment is blocked.”
• document in the runbook — “Document every alert and its resolution procedure in the runbook — on-call engineers shouldn’t need to debug from first principles at 2am.”

Using This Vocabulary in PRR Discussions

PRR discussions often use the phrase “blocking issue” to distinguish problems that must be fixed before launch from “non-blocking recommendations” that should be addressed but don’t prevent launch. Knowing this distinction helps you interpret review feedback: “This is a blocking issue: the rollback plan isn’t documented” versus “This is a recommendation: consider adding a circuit breaker.”

When presenting a PRR, structure your key claims as: “We meet [criterion] as evidenced by [evidence].” For example: “We meet the load test criterion — the load test report shows p99 latency of 180ms at 2x expected traffic.” This evidence-based framing is the standard pattern in English technical communication.

The phrase “contingent on” is frequently used in go decisions: “The PRR is approved, contingent on the runbook update.” It means the approval holds only if the specified condition is met.

Practice Tip

Write a short mock PRR summary for a fictional service you know well — perhaps a simplified version of something you’ve worked on. Include: the service name, three launch criteria and whether each is met, a one-sentence SLO, a brief rollback plan summary, and a go or no-go recommendation with your reasoning. Writing a PRR summary in English trains you to structure technical risk communication clearly, which is one of the most valued skills in senior engineering roles.