Observability: the questions we get asked most

There is no clever trick in this one, just a handful of decisions worth making deliberately. The questions about observability that come up most often on our calls.

The bill is a design document: it tells you exactly what your architecture actually does. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Do we need to care about this?

Monitoring tells you something broke, observability tells you why. There is a version of this that is over-engineered, and it is worth avoiding. Doing this properly once is usually cheaper than doing it approximately three times.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. This is the sort of thing that compounds, quietly, in both directions.

How do we know it is working?

Instrument the paths that lose money first. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The short version

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

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