Observability, explained without the jargon

This is cheap to get right at the start and expensive to retrofit. Here is observability without the vocabulary that usually surrounds it.

Cloud work rewards teams who automate early and punishes teams who click through consoles. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

The short version

Monitoring tells you something broke, observability tells you why. It is worth being explicit about, because assumptions differ quietly. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. There is a version of this that is over-engineered, and it is worth avoiding.

Traces, metrics, and logs answer different questions. The cost of getting this wrong is rarely visible on the day it happens. Check it against what you would want a competitor's site to get wrong.

Making it stick

Instrument the paths that lose money first. There is a version of this that is over-engineered, and it is worth avoiding. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

In practice

Operability is a feature, and it has to be built rather than bought. Three things worth confirming about observability before you move on:

• Someone can say what the current setup is without going to look
• Instrument the paths that lose money first — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.