Observability and production readiness are the same project
If you cannot tell that a customer is stuck, you are not ready — regardless of how many metrics you store.
Production readiness checklists often become a tour of tools. The useful test is simpler: can an on-call engineer, at 2 a.m., tell that a user journey is failing, find the change that likely caused it, and reverse that change?
Symptoms, not servers
Page on checkout failure, login errors, or a freshness miss that blocks a decision. CPU is a clue. It is a poor reason to wake someone if the user journey is fine. Golden signals should be written in the language of the product.
A trace is a story
Distributed systems without correlation identifiers produce folklore. Put a request or tenant id on the logs, the traces, and the support tool. The first hour of an incident should not be a hunt for the right index.
- Deploy events belong on the same timeline as errors.
- Runbooks should be written from real incidents and kept short.
- A readiness review that cannot name the rollback is not finished.
Common questions
What is production readiness?
The point at which a service can be operated safely: user-facing symptoms are monitored, alerts reach someone who can act, deploy events are visible next to errors, runbooks exist for known failure modes, and there is a rehearsed rollback.
What is the difference between observability and monitoring?
Monitoring tracks known signals against thresholds and tells you that something is wrong. Observability is the ability to ask new questions of a system’s logs, metrics, and traces to work out why — essential in distributed systems where failures are rarely predictable.
This article supports our DevOps engineering services. If the situation it describes is familiar, tell us about the systems involved.
