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
Think of a car. The dashboard shows speed and fuel, plus warning lights set up in advance; that's monitoring. A mechanic plugging in a diagnostic tool to read detailed sensor data and work out why the engine makes a strange noise is closer to observability. It means a system records enough detail that you can investigate problems nobody predicted, instead of only checking for known ones.
At work
Observability is how well a team can understand what's happening inside its software from the data the software produces, mainly metrics, logs, and traces. Monitoring checks for problems you predicted; observability lets you investigate ones you didn't. Businesses care because modern systems fail in new and unexpected ways, and faster diagnosis means shorter outages and fewer customers affected.
At home
Software produces three main kinds of data. Metrics are numbers over time, such as requests per second or memory used. Logs are timestamped records of individual events, like an error message. Traces follow one request as it passes through several services, timing each step. On their own, each gives a partial view; linked together through shared IDs, they let you zoom from 'something is slow' to the exact cause.
At work
At work, applications are instrumented, usually with OpenTelemetry, so they emit metrics, logs, and traces in a standard format. A collector receives that data, adds context such as service name and region, and forwards it to a backend: open-source tools like Prometheus, Grafana, and Jaeger, or platforms such as Datadog, New Relic, and Honeycomb. Shared trace IDs connect the signals, so an engineer can jump from a chart spike to the exact traces and logs behind it.
At home
The key idea is cardinality, the number of unique values a field can have. A metric tagged with region has a dozen values; tagged with user ID, it has millions. Traditional metrics databases store one time series per combination, so high cardinality explodes their cost. Observability tools store raw events instead and aggregate at query time. In my view, being able to slice by any field is what separates real observability from a nicer monitoring screen.
At work
Observability architecture is a pipeline: instrumentation, collection, sampling and filtering, storage, and query. Costs scale with volume and cardinality, so mature teams sample traces, tier retention by value, and drop noisy logs at the collector. Alerts should be driven by service level objectives that reflect customer impact, rather than raw thresholds. Standardizing on OpenTelemetry keeps instrumentation portable between vendors, which matters because telemetry bills often grow faster than the systems being watched.
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.