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.

Navigating Disagreement & Seeking Clarity

Let’s be honest – disagreements and moments of uncertainty are absolutely woven into the fabric of nearly every software development team. It’s not about avoiding conflict, but rather, approaching it with strategic language to ensure clear communication and a path forward. Often, the initial reaction – a terse Slack message or an abrupt disagreement during code review – can escalate quickly if not carefully managed. The key isn’t necessarily winning the argument, but ensuring everyone understands the why behind the decision-making process.

Consider this scenario: Sarah, a senior engineer, flags a change request in John’s pull request with the comment “Needs clarification on scope.” While technically accurate – the PR description lacked detail – it’s also potentially frustrating for John to receive that feedback without context. A more constructive approach would be something like: “Hi John, thanks for submitting this PR! To help me understand the scope of your changes and ensure alignment with our team’s goals, could you elaborate on [specific aspect needing clarification]?” Notice how it’s framed as a request for understanding, not an accusation of inadequacy.

Similarly, during a code review discussion, instead of saying “This is bad style,” a more effective approach might be: “I’m concerned about readability here; can we discuss refactoring this to align with our team’s coding standards? I believe it will improve maintainability in the long run.” Notice the inclusion of reasoning – highlighting the benefits of the suggested change. This shifts the focus from subjective judgment to objective improvement.

Finally, when writing PR descriptions, strive for clarity and detail. Instead of a vague “Fixes bug,” try: “Addresses issue #123 - User reported intermittent login failures due to outdated authentication protocols. Implemented [specific changes] to resolve this.” This provides immediate context and allows reviewers to quickly assess the impact of the change. Remember, clear communication reduces ambiguity and fosters collaboration – it’s a cornerstone of productive teamwork, especially when navigating differing opinions or unexpected roadblocks. Focusing on understanding rather than simply stating disagreement is key to smooth workflow and strong professional relationships.