observability versus monitoring
Imagine the dashboard of a car. Monitoring is the set of dials the manufacturer chose to install: speed, fuel, engine temperature. They answer questions someone decided in advance were worth asking. But when the car makes a strange new noise that no dial covers, the dials cannot help — you need a way to ask a question nobody planned for, without taking the engine apart. That second ability is what people mean by observability.
More precisely: monitoring means watching a fixed set of known signals (chosen in advance) and alerting when one crosses a threshold — it answers questions you already knew to ask. Observability means the system emits enough rich data that you can ask NEW questions of it after the fact, including questions you did not anticipate, without changing or stopping the running system. A monitored system tells you THAT something is wrong (the error rate is up); an observable system lets you explore WHY, by slicing the data along dimensions you choose at query time (which customer, which version, which host, which code path). The practical test often quoted is: can you debug a novel problem you have never seen before using only the data already coming out of the system? If yes, it is observable.
It matters because modern production systems fail in ways nobody predicted — a rare combination of a specific user, a specific request, and a specific node. Pre-defined dashboards cannot cover combinations you did not foresee. Observability is the discipline of emitting high-cardinality, structured signals (metrics, logs, traces) so that the answer is already in the data and you only need to query it. The honest caveat: observability is not a product you buy or a dashboard you install — it is a property of how much your system reveals about itself, and you can spend a lot of money on tools while still being unable to answer the question that actually matters.
Monitoring: alert when http_5xx_rate > 1% Observability: query latency, group by (customer_id, build_version, host) -> 'all the slow requests are customer 4821 on build 9f3a, only on host db-7'
Monitoring fires a known alert; observability lets you slice by dimensions you choose at query time to find an unforeseen cause.
These are not opposites and one does not replace the other: you still want monitoring (cheap, fast alerts on known failure modes) AND observability (deep ad-hoc questions). 'Observability' as a marketing label is often just monitoring renamed — judge it by whether you can ask a question nobody pre-built.