Observability vs monitoring

At a glance

	Monitoring	Observability
Question it answers	Is the thing I expected to break, broken?	Why is this happening, when nobody expected it?
Defined in advance	Yes. Dashboards and thresholds are authored	No. The questions arrive during the incident
Fails when	The failure mode was not anticipated	The needed dimension was never recorded
Typical artefact	An alert rule, a dashboard	High-cardinality events that can be sliced arbitrarily
Cost driver	Number of checks	Cardinality and retention
Good enough test	Did it page when users were affected?	Could you answer a new question without deploying code?
Common failure	Alerting on causes rather than symptoms	Three pillars that cannot be joined to one request

How it works

Monitoring is the practice of deciding in advance what failure looks like and watching for it. You choose a signal, choose a threshold, and something pages when the threshold is crossed. It is a closed-world activity: it covers what somebody thought of.

Observability is a property of a system rather than a practice, and it describes how much you can learn about the internal state from what the system already emits. The operational test is concrete: during an incident, can you ask a question nobody anticipated and answer it from data already being collected, without shipping new code? If the answer requires adding a log line and waiting for a deploy, the system is not observable in the way that matters, however many dashboards exist.

The two fail differently, which is why both are needed. Monitoring fails when the failure mode was not on the list, which is most of the interesting failures. Observability fails when the specific dimension needed was never recorded, and unlike monitoring, that failure cannot be repaired retroactively. Data not collected is gone.

The three-pillars framing, metrics, logs and traces, is widely repeated and slightly misleading. Having all three does not produce observability if they cannot be correlated. Metrics telling you error rate rose, logs from an unknown subset of instances, and traces sampled at one percent are three separate investigations rather than one, and joining them by hand under time pressure is where most incident time actually goes.

Cardinality decides this. Unanticipated questions are almost always about a subset: this customer, this build, this availability zone. Where those dimensions were stripped to control cost, the question is unanswerable at any price later.

How it is measured

There is no clean metric for observability, but there is a good proxy: how often does an investigation require adding instrumentation and redeploying? Track it across incidents. A team doing that regularly has found the boundary of what its telemetry supports, and each instance names a dimension worth adding permanently.

Measure how long it takes to attribute an incident to a change. That number is a direct readout of whether deploy events, telemetry and service topology can be joined. Where it is consistently long, the missing capability is correlation rather than collection. How root cause analysis works and how it is measured covers what that attribution involves.

For monitoring specifically, measure coverage the other way round. Take incidents from the last quarter and count how many were first noticed by an alert rather than by a customer, a support ticket or an engineer glancing at a graph. That fraction measures whether monitoring works, and it is usually lower than teams expect.

Audit sampling and retention against the questions you actually needed to ask. A one percent trace sample is fine for aggregate latency and useless for finding the one request that failed strangely. What the four golden signals are and what to alert on covers the monitoring half of this in more detail.

Common misconceptions

That observability is a product you buy. Vendors sell tools that help, but the property depends on what your services emit and whether it can be correlated. A tool cannot query a dimension that was never recorded.

That more data means more observability. Undifferentiated volume raises cost and lowers signal. Ten well-chosen dimensions on every event beat a hundred metrics nobody can join.

That the three pillars are a checklist. They are three data types. Observability comes from being able to move between them for a single request or a single change, which is a correlation property rather than a collection one.

That observability makes alerting unnecessary. Something still has to notice. Excellent observability with poor alerting means you investigate skilfully, starting late.

That monitoring is the outdated one. Alerting on symptoms remains the mechanism that gets a human involved. The two are complementary, and a team that neglects monitoring in favour of observability has simply moved its weakness. The short definition covers the terms themselves.