Production Readiness Review Template

Overview

Shipping to production isn’t the finish line. It’s the starting line for operational responsibility. A production readiness review (PRR) is a structured checkpoint that verifies a service or feature is ready to run in production: it can be monitored, rolled back, secured, and operated by people other than the author. PRRs prevent the 3 AM surprises where nobody knows how to restart a service, what “normal” looks like, or how to roll back a bad deployment.

When to Use

Use this template when:

• A new service is being deployed to production for the first time
• A major feature or refactor changes how an existing service operates
• A service is changing tiers (e.g., from Tier 3 internal tool to Tier 1 customer-facing)
• You are acquiring or migrating a service from another team or company
• An audit requires documented evidence of production readiness

Prerequisites

Before conducting a PRR:

• The service or feature is code-complete and passes all automated tests
• A service ownership document exists (or will be created as part of this review)
• On-call rotation is defined and trained
• Runbooks exist for common failure scenarios
• A rollback procedure has been tested in a non-production environment

Running the Review

1. Circulate the template early. Send the checklist to the service owner and reviewers at least a week before the session — gaps found in the room are gaps found too late.
2. Walk the domains in order. Each box gets checked only with evidence: a dashboard link, a runbook URL, a test run. “We have that” doesn’t count.
3. Record findings as you go. Every gap lands in Review Notes with a risk level, an owner, and a due date. No owner means no fix.
4. Sign off per role. Engineering, product, security, and SRE sign (or block) their own domain — nobody signs for someone else.
5. Decide: pass, conditional, or fail. Conditional pass means launch is allowed once the high-risk items close; the medium ones ship tracked. Fail means fix and reschedule.
6. Track the actions. The review isn’t done until the findings are. Follow up on due dates before calling the service ready.

Scoping the Review

Not every service needs the same depth. Tier 1 (customer-facing, revenue-touching) gets the full ten domains plus a quarterly re-review of the riskiest ones — observability and rollback first. Tier 2 (important but not critical) runs the full review once, then annual re-reviews. Tier 3 (internal tools) can drop to a subset: service definition, deployment, security, and operational readiness are rarely optional; chaos testing and distributed tracing often are.

The scoping conversation happens before the review, in the kickoff — not during it, when half the room is already defensive. Write down which domains you cut and why; a scoped-out domain is a documented decision, not a skipped checkbox.

Solution

# Production Readiness Review: `<Service / Feature Name>`

> Reviewer: ______ | Date: ______ | Status: Pass / Conditional / Fail
> Service owner: ______ | Team: ______ | Release target: ______

---

## 1. Service Definition

- [ ] Service purpose is documented and understood by on-call engineers
- [ ] Service tier is defined (1 / 2 / 3) and matches operational requirements
- [ ] Service ownership document is complete and accessible
- [ ] Dependencies (upstream and downstream) are documented
- [ ] Data classification is defined (Public / Internal / Confidential / Restricted)

## 2. Architecture and Code Quality

- [ ] Architecture is reviewed and approved by a senior engineer or architect
- [ ] Code follows team standards (linting, formatting, test coverage)
- [ ] No known security vulnerabilities in dependencies (scanned within 30 days)
- [ ] Secrets are managed via secret manager, not hardcoded or in config files
- [ ] No single points of failure without documented mitigations

## 3. Testing

- [ ] Unit test coverage is above team minimum (usually 70-80%)
- [ ] Integration tests cover external dependencies and critical paths
- [ ] Load tests confirm the service handles expected peak traffic
- [ ] Chaos or failure injection tests verify graceful degradation
- [ ] End-to-end tests cover the full user journey where applicable

## 4. Observability

- [ ] Metrics are emitted for request rate, errors, and duration (RED)
- [ ] Logs are structured, correlated with trace IDs, and queryable
- [ ] Distributed tracing is configured for cross-service requests
- [ ] Dashboards exist for service health and key business metrics
- [ ] Alerting rules are configured with appropriate severity and thresholds
- [ ] On-call engineers can distinguish between symptoms and causes

## 5. Reliability and Resilience

- [ ] Health check endpoint exists and is used by load balancers
- [ ] Circuit breakers or bulkheads protect against cascading failures
- [ ] Timeouts and retries are configured for external calls
- [ ] Rate limiting is in place for public or partner-facing endpoints
- [ ] Database connections are pooled and bounded
- [ ] The service degrades gracefully when dependencies fail

## 6. Deployment and Release

- [ ] CI/CD pipeline exists and is green
- [ ] Deployments are automated; no manual production changes required
- [ ] Canary or staged rollout is configured for high-tier services
- [ ] Feature flags are available for risky or irreversible changes
- [ ] Database migrations are backward-compatible or have a tested rollback
- [ ] Rollback procedure is documented and tested within the last 30 days

## 7. Security

- [ ] Authentication and authorization are implemented correctly
- [ ] Input validation and sanitization protect against injection attacks
- [ ] Encryption in transit (TLS 1.2+) is enforced
- [ ] Sensitive data is encrypted at rest
- [ ] Security review is completed for auth, payment, or data-handling changes
- [ ] Penetration test or security scan results are reviewed and remediated

## 8. Data and State

- [ ] Database schema changes are reviewed for performance impact
- [ ] Backups are configured and tested (restore verified within 90 days)
- [ ] Data retention policies are documented and enforced
- [ ] GDPR / CCPA / compliance requirements are met for user data
- [ ] Migration scripts are idempotent and reversible where possible

## 9. Documentation

- [ ] README explains how to build, test, and run the service locally
- [ ] API documentation is current (OpenAPI / Swagger / equivalent)
- [ ] Runbooks exist for: deployment, rollback, common incidents, and escalation
- [ ] On-call handoff document is updated with recent changes and risks
- [ ] Architecture Decision Records (ADRs) cover major design choices

## 10. Operational Readiness

- [ ] On-call rotation is staffed and trained on this service
- [ ] Paging alerts reach the right people with useful context
- [ ] Escalation path is documented and contacts are verified
- [ ] Runbooks have been tested by someone who did not write the service
- [ ] Post-deployment verification steps are defined and automated where possible

---

## Review Notes

| Item | Finding | Risk | Mitigation / Action | Owner | Due Date |
|------|---------|------|---------------------|-------|----------|
| ______ | ______ | High / Medium / Low | ______ | ______ | ______ |

## Sign-Off

| Role | Name | Date | Signature (approve / block) |
|------|------|------|------------------------------|
| Engineering owner | ______ | ______ | ______ |
| Product owner | ______ | ______ | ______ |
| Security reviewer | ______ | ______ | ______ |
| SRE / Platform | ______ | ______ | ______ |

Explanation

The ten domains map to the ways services actually fail: undetected errors (observability), no way back (deployment), unsafe defaults (security), and the human side nobody thinks about until 3 AM (operational readiness). Each domain has concrete checkboxes verifiable with evidence, not intentions.

The sign-off model matters as much as the checklist: four distinct approvals prevent the “looks fine to me” from a reviewer who’s also the author. The conditional path is deliberate — a PRR that only produces “no” becomes a gate teams route around; one that produces tracked mitigations becomes a habit.

Completed PRR Example

# PRR: Real-time Notification Service

## Service
- Name: notification-service
- Type: Microservice (Go)
- Tier: 1 (Critical for user experience)
- Review date: 2026-07-11

## Review Findings

| Item | Finding | Risk | Mitigation | Owner | Due |
|------|---------|------|------------|-------|-----|
| Observability | No WebSocket dashboard | Medium | Create dashboard before launch | alice | 2026-07-15 |
| Alerting | No alert for rejected connections | High | Add alert before launch | bob | 2026-07-14 |
| Security | JWT validation missing expiry test | High | Add test before launch | carol | 2026-07-14 |
| Documentation | No rollback runbook | Medium | Write runbook before launch | alice | 2026-07-16 |
| Operational | On-call not trained on WebSocket | Medium | Training session | platform | 2026-07-18 |

## Sign-Off

| Role | Name | Date | Decision |
|------|------|------|----------|
| Engineering owner | alice | 2026-07-18 | Conditional approve |
| Product owner | dave | 2026-07-18 | Approve |
| Security reviewer | carol | 2026-07-18 | Approve (test added) |
| SRE / Platform | bob | 2026-07-18 | Conditional approve |

## Decision
Conditionally approved. Launch permitted after completing the
3 High-risk items (alerting, security, test). Medium-risk items
tracked with due dates but do not block launch.

Companion template: the production-readiness-review-template companion repo has the blank checklist and this filled example as downloadable Markdown files.

Variants

Context	Adjustments	Notes
Mobile app release	Add app store review, rollout percentage, and crashlytics monitoring	Mobile releases are harder to roll back
Data platform / pipeline	Add data quality checks, schema evolution plan, and consumer impact assessment	Data changes affect downstream teams silently
Third-party integration	Add vendor SLA review, contract terms, and fallback behavior	You don’t control the upstream
Security-critical launch	Require mandatory security review and sign-off from security team	Auth, payment, and health data
Internal tool promotion	Reduce observability and on-call requirements; focus on documentation and support	Internal tools have different operational standards

What Works

1. Run the PRR early. Don’t wait until the day before launch; identify gaps while there’s still time to fix them
2. Make it a conversation, not a gate. The goal is readiness, not paperwork; collaborate on mitigations
3. Track gaps explicitly. Items that aren’t checked should have owners and due dates, not be ignored
4. Review quarterly for existing services. Services drift from readiness over time; schedule periodic reviews
5. Automate what you can. Coverage reports, dependency scans, and deployment health checks should feed into the PRR automatically

Common Mistakes

1. Treating the PRR as a one-time event. Production readiness decays; schedule re-reviews for major changes
2. Skipping the rollback test. The only thing worse than a bad deploy is not knowing how to undo it
3. Not involving operations early. SREs and platform teams catch constraints that developers miss
4. Checking boxes without verifying. “We have monitoring” isn’t enough; confirm dashboards are useful and alerts are actionable
5. Forgetting the human side. On-call engineers need training, not just documentation; verify they’ve run through the runbooks

Troubleshooting the Review

• Reviewers approve without evidence: the checklist becomes theater. Require a link or artifact per box — dashboard URL, runbook, test output — and treat “we have that” as unchecked.
• The sign-off stalls for weeks: nobody wants to block, so nobody signs. Set a response deadline (5 business days is common) and escalate to engineering leadership when a signer goes quiet.
• Findings pile up with no owners: a gap list without names is a wish list. Every Review Notes row needs an owner and a due date before the meeting ends, or it isn’t tracked.
• The PRR becomes a rubber stamp: when every review ends in “pass” the process has decayed. Rotate reviewers periodically and compare findings across services to calibrate.
• Conditional passes never close: launch day arrives, mitigations don’t. Put findings into the issue tracker — not a doc nobody opens — and review them at sprint boundaries.

Further Reading

• On-call handoff template — the prerequisite the operational readiness section expects.
• Incident communication template — for the escalation path the review asks you to document.
• Blue-green deployment guide — one of the rollback strategies the deployment domain checks for.
• Capacity planning forecast — where the load-test targets come from.

Production Notes

• Re-review on a schedule. Tier 1 annually, Tier 2 every 18 months, Tier 3 every two years — readiness decays whether anyone notices or not.
• Trigger out-of-cycle reviews on owner changes, big refactors, migrations, or a SEV1 that exposed an operational gap.
• Feed automation into the checklist. Coverage reports, dependency scans, and deploy-health checks can pre-fill half the domains before the session starts.
• Keep a registry. One line per review — service, date, outcome, open findings — it’s the audit trail compliance asks for later.

Key Takeaways

• A PRR answers one question: can someone other than the author operate this safely? Every box serves that.
• Evidence beats intent — a checked box needs a link, a runbook, or a test behind it.
• The conditional pass is what makes the process sustainable: ship the launch, track the gaps.
• Reviews are per-service and per-change, not one-and-done — readiness rots between reviews.

Common Production Pitfalls

• Skipping the evidence requirement once “everyone knows the service” — the next reviewer won’t.
• Writing the PRR the night before launch, so every gap becomes an emergency or a shrug.
• Filing the review where the on-call never looks — a runbook you can’t find doesn’t exist.
• Copying the last PRR forward with stale findings; each review needs fresh verification.
• Leaving findings in the doc instead of the issue tracker — unassigned work is unfinished work.
• Treating “conditional pass” as a pass; the conditions have owners and dates for a reason.