Observability
Also known as: o11y, software observability, system observability
Observability is how well you can understand what's happening inside a software system from the data it produces, usually logs, metrics, and traces.
It's often contrasted with monitoring: monitoring checks for problems you predicted, while observability helps you investigate problems you didn't. While vendors use the word to sell dashboards, real observability is about being able to ask new questions of production without shipping new code.
Observability, explained at three levels
At home
A car's dashboard shows speed and fuel, which is monitoring. A mechanic plugging in a diagnostic tool to find out why the engine makes a strange noise is closer to observability: digging into detailed data to understand something unexpected.
At work
Observability helps teams find out why a system is slow or failing, even for new problems no one planned for. It reduces the time customers spend affected by outages.
At home
Systems produce three main kinds of data: metrics (numbers over time, like requests per second), logs (records of events), and traces (the path of one request through many services). Together, they let you zoom from 'something's wrong' to 'here's the exact cause.'
At work
Teams instrument code with OpenTelemetry and send data to tools such as Grafana, Datadog, New Relic, or Honeycomb. Good practice links all three signals through shared identifiers, so an engineer can jump from a spike in a chart to the traces and logs behind it.
At home
The key concept is 'high cardinality,' meaning data with many unique values, like user IDs or order numbers. Traditional metrics tools struggle with it. In my view, being able to slice data by any field is what separates observability from a nicer-looking monitoring screen.
At work
Costs grow quickly with data volume, so mature teams sample traces, set retention by value, and reduce noisy logs. Tie observability to service level objectives so alerts reflect customer impact. Standardizing on OpenTelemetry keeps instrumentation portable, which strengthens your hand in vendor negotiations.
Real-world examples
At home
Fatima runs a small Discord bot that sometimes stopped responding. After adding basic tracing, she saw that one slow external API call was blocking everything, something her simple uptime check never revealed.
At work
Sophie is an engineering director at a Toronto food delivery company. Customers in one city reported slow orders, but every dashboard looked green. Using high-cardinality traces, her team found one restaurant partner's integration timing out, and fixed it in an afternoon.
How it compares
| feature | Observability | Monitoring |
|---|---|---|
| Question it answers | Why is this happening? | Is something wrong? |
| Problems covered | Including unexpected ones | Mostly predicted ones |
| Typical data | Detailed events, traces, logs | Pre-defined metrics and checks |
| Main output | Investigation and insight | Alerts and dashboards |
Monitoring tells you something broke. Observability helps you find out why.
For analysts
Observability bills can grow faster than the systems they watch. I'd set a budget per service and review what data is actually used during incidents, because most stored telemetry is never looked at.
History & origin
The term comes from control theory, where Rudolf Kálmán defined it in 1960 as how well a system's internal state can be inferred from its outputs. Twitter's engineering team used it for its monitoring group around 2013, and Charity Majors, co-founder of Honeycomb in 2016, did much to popularize it as distinct from traditional monitoring. The 'three pillars' framing of logs, metrics, and traces spread around 2017. OpenTelemetry, formed in 2019 by merging OpenTracing and OpenCensus, became the standard way to collect this data across vendors. In my opinion, the 'three pillars' became a crutch: having all three data types doesn't help if they can't be connected to answer a question.