Every production-bound system at Calvrix ships with observability in place before it sees its first byte of real traffic. Not as a polish step. As an entry condition.
The four signals.
- A latency SLI on the user-facing path, with an SLO and an alerting rule that fires before the error budget is exhausted, not after.
- A success-rate SLI on every external dependency, with the failure mode (5xx vs timeout vs schema mismatch) preserved in the metric.
- A correctness signal: a synthetic transaction that runs continuously through the production path and verifies the output, not the response code.
- A capacity signal: the resource that will run out first, instrumented and graphed, with a threshold that fires at 70%, not 90%.
What "in place before launch" means.
It means the dashboard exists. The alert exists and has been tested by deliberately tripping it in staging. The runbook for the alert exists, names the on-call rotation, and lists the first three diagnostic steps. If any of those is missing, the system does not launch. This is not a stretch goal; it is the entry condition.
The cost of getting this wrong.
A system launched without observability is a system whose first incident is also its first instrumentation work. The engineers find the bug at 02:30 by reading code and guessing, not by reading dashboards. Mean time to recovery is measured in hours instead of minutes. Confidence drops; rollbacks become the default; the platform team learns to fear deploys.
What we will not launch.
A service whose only failure signal is a 500 status code in an access log. A service whose latency is "feels fine." A service whose capacity ceiling is "we will know when we hit it." None of these are launch-able. Refusing to launch them is part of the discipline.
Observability is not a feature you add. It is the entry condition for production.