[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-production-readiness-review::en":3,"gloss-cluster-production-readiness-review::en":23,"gloss-next-production-readiness-review::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"production-readiness-review","cloud","Production Readiness Review","A production readiness review is the check a service passes before it is allowed to carry real traffic, and it asks a different question from a code review. Code review asks whether this change is correct. Readiness asks whether anybody can run the thing once it is live: is it visible when it misbehaves, does someone own it, is there a procedure for its known failures, does it degrade rather than collapse when a dependency is slow, and can it be restored if its data is lost. The reason to make it explicit is that these questions are all easy to answer during a launch and nearly impossible to answer afterwards, when the service is already carrying customers and the people who wrote it have moved on. A readiness review has to stay short to survive. The version that works is a handful of questions with a named owner for each answer, not a document nobody finishes. Who is paged when it breaks. What does the dashboard show, and would a stranger reading it know whether the service is healthy. What are the two or three ways this is expected to fail, and what does someone do about each. What does it depend on, and what happens to a user request when each dependency is unavailable. What is the recovery story for its data, and when was that last tested. The failure mode is the review that becomes a gate rather than a conversation — a queue with a wait, held by a team that did not build the service and cannot judge it, which teaches everyone to schedule around it or to argue that this particular service is not really production. If that is happening, the review is measuring compliance rather than readiness, and shortening it is a better response than enforcing it harder. The same questions are worth re-asking when a service changes materially, because readiness is a property of the system as it is now, not a certificate it earned at launch. A service that acquired a new dependency, a new data store or ten times its original traffic has quietly stopped being the thing that was reviewed.","A production readiness review asks whether a service can be operated, not whether the code is correct. The questions worth asking before launch.",null,[11,14,17,20],{"slug":12,"name":13},"disaster-recovery","Disaster Recovery",{"slug":15,"name":16},"observability","Observability",{"slug":18,"name":19},"runbook","Runbook",{"slug":21,"name":22},"service-level-objective","Service Level Objective (SLO)",[24,28,32,35,38,41,45,48,51,54,57,60],{"slug":25,"category":5,"name":26,"updated_at":27},"air-gapped-deployment","Air-Gapped Deployment","2026-09-09T03:30:02+00:00",{"slug":29,"category":5,"name":30,"updated_at":31},"autoscaling","Autoscaling","2026-09-08T21:32:36+00:00",{"slug":33,"category":5,"name":34,"updated_at":31},"availability-zone","Availability Zone (AZ)",{"slug":36,"category":5,"name":37,"updated_at":31},"block-storage","Block Storage",{"slug":39,"category":5,"name":40,"updated_at":27},"bring-your-own-cloud","Bring Your Own Cloud (BYOC)",{"slug":42,"category":5,"name":43,"updated_at":44},"budget-alert","Budget Alert","2026-09-08T21:32:37+00:00",{"slug":46,"category":5,"name":47,"updated_at":27},"change-freeze","Change Freeze",{"slug":49,"category":5,"name":50,"updated_at":27},"control-plane","Control Plane and Data Plane",{"slug":52,"category":5,"name":53,"updated_at":44},"cost-allocation-tag","Cost Allocation Tag",{"slug":55,"category":5,"name":56,"updated_at":44},"cost-chargeback","Cost Chargeback",{"slug":58,"category":5,"name":59,"updated_at":44},"cost-observability","Cost Observability",{"slug":12,"category":5,"name":13,"updated_at":31}]