Production Readiness Checklist
An evidence-based release review for security, data, resilience, delivery, observability, operations, rollback, and ownership.
Learning objectives
- Review a backend release using verifiable evidence rather than confidence statements
- Define owners, monitors, recovery steps, and rollback before production traffic
A checklist is a release decision aid, not proof by itself. Mark an item complete only when a link, test result, dashboard, runbook, restore record, or named owner demonstrates it. Tailor thresholds to the service rather than copying universal numbers.
Product and API contract
Production starts with a bounded behavior contract and accountable ownership.
Requirements and non-goals are reviewed
Evidence: Approved scope and acceptance criteria
API success and RFC 9457 failure contracts are documented
Evidence: Versioned OpenAPI plus examples
Compatibility and deprecation policy is explicit
Evidence: Consumer review or contract test
Service, data, and on-call owners are named
Evidence: Repository ownership and runbook contacts
Security and privacy
Authentication is one control; production security includes authorization, abuse, secrets, data, and audit behavior.
Threats and trust boundaries are reviewed
Evidence: Threat model with mitigations and accepted risks
Least privilege and resource ownership are tested
Evidence: Automated negative authorization cases
Secrets are external, rotated, and excluded from logs/images
Evidence: Secret inventory and scan result
Sensitive fields are classified and redacted
Evidence: Logging/privacy test and retention policy
Rate limits and abuse responses protect high-risk flows
Evidence: Load/abuse test and operational override
Data and migrations
Durability requires constraints, compatible schema change, and proven recovery—not only successful writes.
Constraints and indexes match invariants and query plans
Evidence: Schema review and representative EXPLAIN evidence
Migration is backward-compatible and rehearsed
Evidence: Upgrade test from the previous production schema
Backup completed and restore was verified
Evidence: Recent restore record with measured recovery time
Retention, deletion, and audit history are defined
Evidence: Data lifecycle policy and implementation test
Connection-pool limits fit database capacity
Evidence: Capacity calculation plus pool dashboard
Reliability and performance
The service needs bounded resource and failure behavior under realistic concurrency.
Service objectives and workload assumptions are stated
Evidence: Latency/error/throughput targets with traffic model
Every network and database call has a timeout budget
Evidence: Configuration review and failure test
Retries are bounded, jittered, and idempotency-safe
Evidence: Policy and duplicate-delivery test
Pools, queues, and payload sizes are bounded
Evidence: Resource configuration and saturation test
Graceful shutdown drains accepted work
Evidence: SIGTERM deployment test
Delivery and infrastructure
A verified source change must become one identifiable, least-privileged, recoverable artifact.
The same immutable image is promoted
Evidence: Registry digest recorded in deployment
Image is minimal, non-root, scanned, and patched
Evidence: Dockerfile review and current scan
CI permissions and deployment approvals are least privilege
Evidence: Workflow and environment policy review
HTTPS, proxy limits, security headers, and resource limits are set
Evidence: Runtime configuration test
Application and schema rollback paths are rehearsed
Evidence: Recorded rollback exercise
Observability and operations
Operators need enough signal to detect user impact, locate a boundary, mitigate safely, and learn.
Structured logs correlate requests without sensitive data
Evidence: Sanitized log sample and redaction test
Request, error, latency, saturation, JVM, and pool metrics exist
Evidence: Dashboard populated from a test deployment
Trace context reaches trusted downstream boundaries
Evidence: Example trace and propagation policy
Readiness and liveness express different meanings
Evidence: Probe failure simulation
Alerts are actionable and linked to a runbook
Evidence: Alert test with owner and response steps
Incident and postmortem process is prepared
Evidence: Database pool exhaustion exercise
Release decision
- GO only when critical correctness, security, restore, observability, and rollback evidence exists and residual risks have named owners.
- CONDITIONAL GO records the exact temporary control, owner, expiry date, and verification plan; it is not a permanent waiver.
- NO-GO when an unknown can cause data corruption, unauthorized access, unrecoverable loss, or an unobservable high-impact failure.
Retrieval check
Before you continue
- Explain the main idea in your own words without rereading the page.
- Name one production problem this knowledge helps prevent.
- Describe where you would apply it in a Spring Boot project.
Source metadata
Primary references checked on 2026-07-16. Version scope is stated at the top of this page.
Spring Boot Actuator Endpoints (opens in a new tab)
Spring · official-docs
Spring Boot Graceful Shutdown (opens in a new tab)
Spring · official-docs
OpenTelemetry Concepts (opens in a new tab)
OpenTelemetry · official-docs
Application Security Verification Standard 5.0 (opens in a new tab)
OWASP · standard
Docker Build Best Practices (opens in a new tab)
Docker · official-docs