Observability is not three dashboards
2026-05-30 · DevOps · 1 min read · @TechScribeWire
Somewhere along the way “observability” got flattened into “buy the three-pillars product and put up some dashboards.” That misses the point entirely.
The real definition
Observability is the ability to ask arbitrary questions about your running system — including questions you did not anticipate — without deploying new code to answer them. Dashboards answer the questions you already thought of. Real observability is for the 3am question you have never asked before.
High-cardinality is the whole game
The reason a request slows down is rarely “the service is slow.” It is “the service is slow for users on plan X, in region Y, hitting endpoint Z, since the last deploy.” If you cannot slice by all of those at once, you cannot answer it.
latency_ms{plan="enterprise", region="eu-west", endpoint="/export"}
Instrument intent, not just plumbing
- Emit events at decision points, with the context that explains the decision.
- Include identifiers you can correlate: request id, user id, trace id.
- Favor wide, structured events over scattered log lines.
Dashboards are the start of an investigation, not the end
A dashboard tells you that something is wrong. The ability to break down, filter, and pivot on live data tells you why. Optimize for the second one, and the late-night incidents get a lot shorter.