Production readiness checklist: 12 questions experienced teams carry in their heads

There is a type of article you find everywhere: the production readiness checklist you walk through before go-live and tick off. In practice I have almost never seen that happen. Deployments run on experience, on habit, and on whatever hurt during the last outage. There are formal processes — approvals, maintenance windows, four-eyes rules — but not a list somebody works through top to bottom every time.

That is not a lack of professionalism either. Every release is a different situation, and a list that tries to cover all of them gets ignored by the third time. These questions are useful in two other places: early, while the architecture is being shaped and the answers are still cheap, and afterwards, when something has gone wrong and you want to know which question you should have asked.

That is how the following twelve are meant. Not as an acceptance gate, but as what experienced people carry in their heads anyway — written down so that the people who have not been there yet have it too.

1. Observability: what do we see when something goes wrong?

Without logs, metrics and traces, an incident is a guessing game. The question is not whether errors occur, but whether the team finds them quickly.

• Are there central logs with correlation IDs? Requests across multiple services must be traceable.
• What metrics are monitored? Not just CPU and RAM, but business metrics such as error rates, latency, queue lengths.
• Are there meaningful alerts? An alarm that fires constantly is ignored. An alarm that reaches nobody is worthless.

If you can only answer one of these, make it the middle one. A team that knows the business metric of its system notices an outage before the customer calls. A team with only infrastructure metrics notices afterwards.

2. Operations: who deals with ongoing problems?

A system that belongs to nobody ages and silently deteriorates. Before go-live it must be clear who takes over operations.

• Who is the first point of contact for an incident? Not a role, a name.
• Is there a runbook for the most likely failures? The most important document is not the architecture, but the guide for the next outage.
• Is the rollback path tested? A rollback that only works in theory is not a rollback.
• After an incident, can you reconstruct what happened — or only what is true now? Systems that store only current state cannot answer the question of how it came to be. This worked example from order fulfilment shows what that costs.

The decisive one is the third. A tested rollback turns every deployment into a reversible decision — and reversible decisions may be made faster.

3. Security: can the system withstand attacks?

Security is not a one-off check but a property that grows with operations.

• Are secrets separate from code and rotatable? No passwords in repositories, no long-lived keys without a plan.
• Is there a patch process for critical dependencies? When a CVE is published, it must be clear who responds and how fast.
• Does this release change who may see or do what — and would anyone notice? Beyond that, the access model does not belong in a deployment review. How roles, tenants and tokens become structurally sound is an architecture question; more on that in multi-tenancy with Keycloak.

The third question is the one most often missed, because permission changes rarely show up in a changelog. Yet it is the only security change a single release can genuinely introduce.

4. Organisation: who carries the responsibility?

Technical readiness is not enough if the organisation is not ready.

• Who decides on changes after go-live? Clear authority prevents every detail from passing through multiple committees.
• Who represents the system in the business unit? Adoption needs a name, not a role.
• Is there a clear handover plan from project to operations? A date on paper is not enough; it needs shared time, documentation and tested processes.

If only one question here is answered, make it the first. Everything else can be caught up on; unclear decision authority blocks every correction that becomes necessary after go-live. Why that is, in ownership instead of roles.

How these questions actually become useful

Not as a form. Two uses work:

During architecture. While the shape of the system is still being decided, these answers are almost free. Six weeks before go-live the same answers cost rework. That is why we go through them at the start, not at the end.

After an incident. An outage is the one moment an organisation is willing to talk honestly about operations. Then the list is not bureaucracy but a map: which of these twelve questions would have warned us?

Our platform and production readiness package starts exactly there — not as a final gate, but as company from architecture to the handover into operations.

When this does not fit

For prototypes, feasibility studies and internal tools that are deliberately short-lived, this is overhead. And when a team has deployed the same system for years and knows the answers by heart, a written list adds nothing — the only value there is writing it down once before the person who knows everything leaves.

It also does not fit as a pure capacity question. Anyone looking for someone to work through the list on their behalf is buying a document, not a system that holds.

Short version

Nobody ticks off a checklist before deploying, and they do not have to. The twelve questions on observability, operations, security and organisation are a thinking tool for two moments: when the architecture is taking shape, and when something has gone wrong. Asking them then avoids the classic trap — a system that is technically live but organisationally nowhere.

If you want to check what your system can actually evidence today, the provability check asks ten questions about exactly that. The wider frame — from NIS2 to the EU AI Act — is collected under provability.