What is a production readiness review?
A production readiness review, or PRR, is a structured decision process used to determine whether a specific software release is ready to operate in production under defined conditions. It examines more than functional correctness. A useful review asks whether the system can be deployed, observed, supported, secured, recovered and changed without relying on undocumented assumptions.
The review should produce a decision supported by traceable evidence: approve, approve with explicit conditions, or block pending remediation. It is not a ceremonial meeting, a generic checklist or a promise that incidents will not occur. Even a thorough review samples evidence at a point in time; production behavior, third-party services, traffic and threats can change afterward.
The unit of review must be clear. Record the application, release or commit, environment, configuration, test journey, review time and accountable owners. Without that provenance, an approval can be mistakenly applied to code or infrastructure that was never inspected.
When to run the review
Run the production readiness review late enough that representative evidence exists, but early enough to fix material findings. For a conventional release, that is usually after integration and acceptance testing but before broad production exposure. New services, major architectural changes, sensitive data flows, new vendors, migrations and high-impact automated actions deserve deeper scrutiny than a small, reversible change.
The review model should be proportional to risk. A low-impact content adjustment may need only focused checks and deployment controls. A new payment path, authentication flow or AI agent capable of taking external actions needs stricter authority, data, failure and human-oversight gates. Re-review when the inspected version, environment, dependencies or risk assumptions change materially.
- Define the reviewed version and environment before collecting evidence.
- Set a remediation deadline that leaves room for reinspection.
- Require a fresh decision after material scope or configuration changes.
- Use tighter controls for irreversible, regulated, financially consequential or safety-relevant actions.
Start with scope, ownership and acceptance criteria
A PRR becomes unreliable when participants interpret “ready” differently. Begin with the intended user journey, release boundaries, expected load, data handled, external dependencies and failure consequences. Identify what is deliberately out of scope and who accepted that limitation.
Convert broad questions into testable acceptance criteria. “Monitoring is ready” is vague. “An alert fires when the checkout error ratio exceeds the agreed threshold, reaches the current on-call route and links to a tested runbook” can be inspected. Thresholds must come from the service’s objectives and risk tolerance rather than copied from another system.
Every criterion needs an owner and an acceptable form of evidence. Evidence might include a versioned configuration, browser capture, test result, source reference, alert route, recovery exercise or approved decision record. A verbal assurance can add context, but it should not replace observable proof for a material launch condition.
Review the dimensions that can make a release fail
The exact subject-matter coverage depends on the product, but a production readiness assessment should account for the full operating system around the feature—not only the happy path. Public frameworks such as NIST’s Secure Software Development Framework, OWASP ASVS, WCAG and established site reliability engineering practices can inform criteria. They do not replace product-specific threat modeling, accessibility evaluation or legal advice.
- Functionality: critical journeys, input validation, state transitions, duplicate submissions and failure handling.
- Security and privacy: authentication, authorization, secrets, dependency exposure, logging hygiene, data minimization and retention controls.
- Accessibility and usability: keyboard operation, focus behavior, labels, contrast, errors, responsive layouts and assistive-technology checks appropriate to the product.
- Reliability: timeouts, retries, rate limits, concurrency, graceful degradation and dependency failure behavior.
- Observability: meaningful logs, metrics, traces, alert thresholds, ownership and correlation identifiers without inappropriate sensitive data.
- Operations: deployment procedure, capacity assumptions, on-call coverage, runbooks, escalation paths and support readiness.
- Recovery: rollback or roll-forward procedure, database compatibility, backup restoration evidence and recovery objectives.
- Change governance: reviewed code and configuration, artifact provenance, approvals, feature flags and separation of duties where required.
Use an evidence-gated review workflow
A practical workflow separates evidence collection from judgment. First freeze the candidate scope. Then gather evidence against each criterion, record gaps, assess consequence and likelihood, assign remediation, and reinspect the changed release. The final decision should reference the evidence set and unresolved risks.
For each artifact, capture what produced it, when it was produced, which version and environment it covers, and who is accountable for interpreting it. Screenshots alone are weak when they omit the URL, state or version. A passing test is also incomplete if the test scope, data and result cannot be reproduced.
Automated inspection can broaden coverage, but it introduces its own uncertainty. Browser automation may miss assistive-technology behavior; source inspection may not reflect deployed configuration; synthetic journeys may not expose concurrency or real traffic effects. Record these limitations rather than converting incomplete evidence into a pass.
- Collect raw evidence before writing conclusions.
- Keep observed facts separate from inferred risk and proposed remediation.
- Deduplicate repeated symptoms without discarding their underlying evidence.
- Mark untested, inaccessible or unknown areas explicitly.
- Reinspect remediation against the new version instead of carrying forward the old approval.
Test operational safety, not just the happy path
The strongest readiness reviews deliberately examine what happens when assumptions fail. Interrupt a dependency, deny authorization, submit stale or malformed data, repeat an action, and test a safe timeout where the environment permits. Confirm that the result is understandable to users and diagnosable by operators.
Consequential actions need special treatment. Charges, messages, deletions, permission changes and external system updates may not be safely repeatable. Use disposable data and controlled accounts where possible. Establish explicit authority before execution, stop when the effect or entitlement is unknown, and involve a human when judgment or approval is required.
Do not infer exactly-once behavior merely because a button becomes disabled or a single test succeeds. Retry and idempotency claims require architecture and failure-path evidence. Likewise, a rollback document is not proof of recoverability until the applicable procedure has been exercised under representative conditions.
Turn findings into a defensible launch decision
A production readiness report should make the decision legible to someone who did not attend the review. Each finding needs a concise title, observed evidence, affected component and version, plausible consequence, severity rationale, owner and required action. Where uncertainty changes the risk, state it directly.
Avoid averaging unlike risks into one readiness score. A collection of minor presentation defects cannot cancel an authorization flaw or an untested destructive migration. Define non-negotiable blockers before the review and evaluate every required dimension, including those with no available evidence.
Conditional approval can be appropriate when residual risk is bounded, owned and time-limited. Record the condition, compensating control, expiry or follow-up date, and person authorized to accept it. “Known issue” is not a decision unless its impact and ownership are explicit.
- Approve: required evidence is present and no defined blocker remains.
- Approve with conditions: bounded residual risks have named owners, controls and deadlines.
- Block: a critical criterion fails, evidence is missing for a material risk, or safe operation cannot be established.
- Escalate: the reviewer lacks authority or expertise to accept the consequence.
Common production readiness review mistakes
The most common failure is treating the PRR as a meeting held just before deployment. That creates pressure to rationalize gaps rather than resolve them. Another is allowing each team to present only its preferred evidence, leaving cross-cutting concerns such as recovery, accessibility or authorization unowned.
AI-built and no-code applications add further provenance challenges. Generated code can contain unfamiliar dependencies, while platform-managed behavior may be difficult to inspect. Visual success does not establish server-side authorization, data isolation or reliable side effects. Record what can be observed, what can be inspected in source, what is controlled by a provider and what remains unknown.
- Reviewing an ambiguous build rather than a pinned release candidate.
- Accepting screenshots or verbal statements without context and provenance.
- Testing with live or sensitive data when disposable data would suffice.
- Executing consequential actions without explicit authority.
- Assuming source code, browser behavior and deployed configuration are identical.
- Closing a finding after a code change without reinspection.
- Using a checklist that omits an entire specialist dimension.
- Confusing readiness with a guarantee of security, compliance, accessibility or business success.