Signs it is time to revisit observability

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. A few signals that observability is due some attention.

Cloud work rewards teams who automate early and punishes teams who click through consoles. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

The signals

• Nobody can say when it was last reviewed
• The answer depends on who you ask
• Monitoring tells you something broke, observability tells you why
• Traces, metrics, and logs answer different questions

The practical version

Instrument the paths that lose money first. That sounds obvious written down. It is still the thing most often skipped. If it only works because one person remembers to do something, it does not work yet.

The short version

The bill is a design document: it tells you exactly what your architecture actually does. Three things worth confirming about observability before you move on:

• Someone can say what the current setup is without going to look
• Monitoring tells you something broke, observability tells you why — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.