Skip to main content

> sre_operational_standards:_production_readiness_reviews_(prr)_&_launch_gate_audits

SRE Operational Standards: Production Readiness Reviews (PRR) & Launch Gate Audits

Why do newly deployed microservices cause 80% of preventable production outages within their first 30 days of launch, and how does Google SRE's Production Readiness Review (PRR) gate un-operable services?

Staff/Principal (L6+)

⚡THE SHORT ANSWER

When development squads rush a new microservice to production, they focus 100% on business logic features and 0% on operational operability. The new service launches without health check endpoints, has no Prometheus metrics, uses hardcoded database connection pools, lacks automated canary rollbacks, and has zero runbooks. Within 2 weeks, the service crashes production and the on-call engineer has no idea how to debug or restart it. Google SRE invented the Production Readiness Review (PRR) to eliminate this failure mode: an objective, programmatic gate that every new service must pass before accepting real customer traffic. The PRR validates 8 Core Operational Pillars:

1

Observability: SLI/SLO metrics, distributed tracing, and Datadog dashboards.

2

Emergency Recovery: Automated runbooks, graceful shutdown (SIGTERM), and circuit breakers.

3

Capacity & Scaling: Load test benchmarks and auto-scaling policies.

4

Security & Compliance: JIT access, secret rotation, and CVE scan gates.

Engineering Handbook & Failure Dynamics

6-Dimensional Architecture Breakdown

⚙️1. Underlying Mechanism

Execution

PRR governance executes via automated scorecard linting and SRE partnership:

1

Automated Service Catalog Scoring: Cortex or Backstage evaluates the repository against automated rules (e.g. 'Has Dockerfile health check?', 'Prometheus metrics endpoint responds 200', 'Runbook link configured').

2

The PRR Design Sprint: During early architectural design (not the day before launch), an SRE pairs with the squad to review failure modes.

3

The Pre-Launch Checklist Audit: The squad demonstrates graceful degradation under simulated dependency failure.

4

Operational Handoff: SRE formally co-signs operational ownership once the service achieves a Gold-tier PRR rating.

🎯2. Appropriate Use Context

Scope

New microservice deployments, major architectural rewrites, Tier-1 core system migrations, and third-party SaaS integration launches.

⚠️3. Production Failure Modes

P0 Risk
  • ✓

    Treating PRR as a bureaucratic rubber-stamp checklist completed 10 minutes before a marketing launch

  • ✓

    launching a service with zero rate limiting or timeout configurations against upstream databases

📡4. Diagnostic Signals & Telemetry

Telemetry
  • ✓

    New services crashing immediately on Day 1 due to missing environment variables

  • ✓

    on-call engineers getting paged for services where no runbook or dashboard exists

  • ✓

    squads claiming 'We will add metrics in Phase 2'

🛡️5. Prevention & Safeguards

Safeguards
  • ✓

    Automate PRR verification in Spotify Backstage / Cortex

  • ✓

    block DNS routing to new services until PRR Bronze status is verified

  • ✓

    enforce the 'No Runbook = No Production' rule

⚖️6. Architectural Trade-offs

Trade-off

Production Readiness Reviews eliminate 80% of Day-1 operational outages and standardize telemetry, but require development squads to allocate 10-15% of initial build time to operability engineering.

📋

Case Study (TinyCTO In-Field Example)

REAL-WORLD TELEMETRY

A banking squad built a new AI Fraud Detection microservice. During the automated PRR review, the SRE team discovered that:

1

The service had no timeouts on its calls to the core ledger,

2

Database connection pool size was set to default 100 on each of 40 pods (4,000 DB connections, which would crash PostgreSQL), and

3

It had no /healthz readiness probe. The PRR gate automatically blocked the production rollout. The squad fixed the connection pool size, added circuit breakers, and instrumented p99 latency metrics in 3 days. When launched under 50,000 req/sec real traffic, the service scaled smoothly with zero database incidents.

Interactive Concept Drills

2 Cards
Q1

What is a Production Readiness Review (PRR) in Google Site Reliability Engineering?

A structured, objective assessment that evaluates whether a software service meets core operational standards for observability, emergency recovery, capacity, and security before it is permitted to accept production traffic.
Q2

When should a Production Readiness Review (PRR) begin during a project lifecycle?

Early during the initial architectural design phase, NOT the day before the production marketing launch, ensuring operability requirements are built into the foundational architecture.

SRE Operational Standards: Production Readiness Reviews (PRR) & Launch Gate Audits — Technical FAQ

What are the essential elements of an acceptable operational runbook in a PRR?

Clear service overview, architecture diagram, common alert failure modes with step-by-step diagnostic CLI commands, rollback procedures, and escalation contacts.

How can engineering organizations automate PRR scorecards at scale?

Using internal developer portals like Spotify Backstage or Cortex to programmatically poll Git repositories and CI/CD pipelines for mandatory health checks, metrics, and documentation.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸

    PRRs ensure services meet strict operational standards before accepting real traffic.

  • ▸

    Enforce the 8 Pillars: Observability, Emergency Recovery, Scaling, and Security.

  • ▸

    Initiate PRR collaboration during early system design, not the night before release.

  • ▸

    Automate PRR readiness scorecards using Spotify Backstage or Cortex service catalogs.

Common Misconceptions

  • ✗

    Yanılgı: PRR is a bureaucratic blocker that slows down product feature launches (Gerçek: PRR prevents catastrophic Day-1 outages that stall product roadmaps for weeks).

  • ✗

    Yanılgı: We can deploy to production now and add metrics and runbooks later in Phase 2 (Gerçek: Phase 2 never happens; un-monitored services inevitably cause SEV1 outages).

Decision & Governance Guidance

Implement programmatic Production Readiness Reviews (PRRs) integrated into developer portals like Backstage to eliminate un-operable microservices and guarantee Day-1 operational excellence.

Authoritative Sources & Standards

Technical terms on this page

Productionhealth checkCode Review