Skip to content

Cloud & DevOps

Observability

The ability to understand what a running system is doing from the outside, using the signals it already emits: logs of what happened, metrics, and traces.

Observability is how well you can answer questions about a running system without shipping new code to investigate. It rests on three kinds of signal: logs (what happened), metrics (how much and how fast), and traces (the path a request took through the system). Together they let you move from "something is wrong" to "here is exactly what and where" quickly.

It is distinct from monitoring, which watches for known problems. Observability is about being able to diagnose the problems you did not anticipate, which, in a real system, are most of them. Building it in as features ship, rather than bolting it on after an outage, is the difference between a five-minute diagnosis and a five-hour one.

Related terms

Working out whether you need Observability?

Definitions are the easy part. If you are trying to decide whether Observability belongs in your system, describe what you are building and a senior engineer will give you a straight answer, including when the answer is that you do not need it.

  1. 01A senior engineer reads it. Not a form queue, and not an account manager.
  2. 02We reply either with questions or with a straight answer that we are not the right fit.
  3. 03If it looks like a fit, a technical call with the person who would actually run the delivery.
  4. 04Then scope, effort and risk in writing, before anyone signs anything.

Two fields required. We reply to real enquiries. No list, no sequence.