Operations

Production Readiness Review Prompt

SHIP or DO NOT SHIP: twelve checks on failure modes, observability, rollback, and load — the review that happens before the incident.

Overview

The strongest combination on the tool: Production Readiness focus under Production Gate style. Every finding answers one standing question — would this survive production traffic, failures, and attackers? — across twelve checks: timeouts and bounded retries, 3-a.m. debuggability, metrics for new behavior, environment-safe config, graceful degradation, feature-flag rollback, migration compatibility, resource limits, idempotency under retry, alarms for new failure modes, secret storage, and behavior at 10× traffic. The verdict is a deployment decision: SHIP or DO NOT SHIP, with the minimal change list that flips it.

Workflow

Run it as the last gate
After correctness review, after tests — this pass asks the questions that only matter in production.
Respect the DO NOT SHIP list
The verdict comes with the minimal set of changes that would flip it — that list IS the pre-deploy task list.
Re-run at 10× growth
The traffic question ages: what survived launch traffic may not survive this quarter's.

Why This Works

A deployment decision forces the review to commit — no "mostly fine" verdicts
Failure-mode checks review the code's worst day, not its demo
The minimal-fix list turns a blocked deploy into a finite plan

Best for

Changes shipping to systems with real users and real SLAs
Teams without a formal production-readiness review process
The PR that "works locally" and is about to find out

Not for

Library or tooling code that never serves traffic — use Correctness or Maintainability focus
Incident diagnosis after the deploy — that's the Debugging Prompt Generator

Use cases

Gating the weekly deploy with a structured readiness pass
Reviewing failure handling before code meets real dependencies
Making "is this observable enough?" a checklist item instead of a hope

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

REVIEW OBJECTIVE
Decide whether this change is safe to deploy to production this week.
Primary focus: production readiness — review for the night this code meets real traffic and real failures.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a full pull request — judge the change as it will land: across files, at deploy time, in production.

REVIEW CRITERIA
- Failure modes: timeouts, retries, dependency outages
- Observability: logs, metrics, health signals
- Configuration, secrets, and environment separation
- Rollback safety and migration compatibility
- Behavior under load and at limits
- Breaking changes to public APIs or contracts
- Backward compatibility of serialized data, schemas, and protocols
- Regression risk in the touched code paths
- Cross-file impact: hidden coupling between the changed files
- Deployment risk: ordering, partial deploys, rollback path
- Migration risk: schema or data changes and their compatibility window
- Whether the PR is small enough to review honestly
- Whether the description matches what the change actually does

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Are failure modes handled: timeouts set, retries bounded, fallbacks defined?
2. Is logging sufficient to debug an incident at 3 a.m. without a debugger?
3. Are metrics or health signals exposed for the new behavior?
4. Is configuration externalized per environment — nothing environment-specific hardcoded?
5. Does the code degrade gracefully when its dependencies fail?
6. Can this change be rolled back safely (feature flag, reversible migration)?
7. Are schema or data migrations backward compatible during deploy?
8. Are resource limits respected: pool sizes, payload caps, queue bounds?
9. Are operations idempotent where retries can re-deliver them?
10. Will alarms fire for the new failure modes this change introduces?
11. Are secrets loaded from the proper store, never from code or plain config?
12. What breaks first at 10× the expected traffic — and is that acceptable?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Review as the final gate before production deployment.
- The standing question for every finding: would this survive production traffic, failures, and attackers?
- Treat missing failure handling and missing observability as findings, not nice-to-haves.

FINAL VERDICT
- End with a deployment decision: SHIP or DO NOT SHIP. If DO NOT SHIP, list the minimal set of changes that would flip the decision.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the pull request here]

Related Resources

Explore more resources that work well with this one.