Observability vs monitoring: what the difference actually means

Observability vs monitoring comes down to what a system can tell you, and when. Monitoring watches for the failures a team already predicted and alerts the moment one crosses a threshold. Observability is the ability to ask new questions of a system's recorded behavior after something breaks in a way nobody anticipated, and get an answer without shipping new code to go looking for it. One depends on foresight. The other depends on how much detail was captured in the first place.

Known failures versus unknown ones

A multi-tenant SaaS platform runs order-count, checkout-latency, and error-rate dashboards averaged across every tenant, and every panel is green. The failure hits one tenant out of thousands and barely moves an aggregate number. A customer on an older Android build hits a payment method their app version handles incorrectly, so checkout throws a client-side error the server never sees. Support gets the complaint before engineering gets a signal.

That gap is the whole argument for observability. Monitoring is built ahead of time: someone decides which metrics matter, sets a threshold, and waits for it to trip. It works for failure modes someone thought to name, and has nothing to say about the ones nobody named, because no panel was built to represent them. Observability trades the pre-built dashboard for raw telemetry an engineer can query after the fact, asking a question the system was never wired to answer: show every checkout on this app version in the last hour, broken down by payment method.

The three pillars

Three kinds of telemetry cover most of what observability tooling collects.

• Metrics are numbers over time: request rate, error rate, latency, queue depth. Cheap to store because they're pre-aggregated, and usually what a dashboard is built from. They can't tell you which request failed.
• Logs are timestamped records of discrete events, one line per thing that happened: which request, which user, which error. That detail is what metrics throw away, and it's also what makes logs expensive at scale, since verbose logging on a busy service can outgrow every other telemetry cost combined.
• Traces follow a single request across every service it touches, timing each hop as a span. They're the only one of the three built to show where in a distributed call chain the time went, which is exactly the gap in the checkout example above. Storing every span for every request gets expensive fast, so traces are usually sampled rather than kept in full.

None of the three replaces the others. A metric flags that something is wrong, a trace shows roughly where, and a log fills in the detail once the search is narrow enough to read one.

What OpenTelemetry changed

Before OpenTelemetry, a team instrumenting a service for tracing chose between two competing open-source projects, OpenTracing and OpenCensus, whose tooling rarely worked together. The two merged in 2019 to form OpenTelemetry, which the Cloud Native Computing Foundation accepted that year and later moved to Graduated status, its highest maturity tier, in May 2026.

In practice, that means instrumentation stops being tied to one observability vendor. Code gets instrumented once, against a vendor-neutral API, and the resulting logs, metrics, and traces ship to any backend that speaks the OpenTelemetry protocol. Switching backends used to mean re-instrumenting the codebase; now it mostly means changing an export destination.

What it costs to run

Observability tooling is usually priced on volume, and volume grows faster than most teams expect once instrumentation gets thorough. Three levers decide the bill.

Cardinality is how many unique combinations a metric can produce. Tag a request-count metric by service name alone and it might have a dozen values; add user ID too and it can hit millions, and most backends charge more as cardinality climbs.

Retention is how long data sits before deletion: logs and traces for weeks, metrics for years at lower resolution, since storage cost scales with volume and duration.

Sampling decides what fraction of traces get recorded. Full capture is the most complete option and, at scale, often the most expensive by a wide margin. Most teams sample a fixed share of ordinary traffic and force full capture for anything that errors or runs slow.

Instrumentation mistakes that get expensive

Four habits turn instrumentation into a bill nobody planned for.

• Instrumenting every service and field before anyone asks what will get queried. The cardinality cost stays invisible until the bill arrives, usually driven by a tag nobody remembers adding, a raw user ID or an unbounded request path.
• Writing a log line as a prose sentence, "payment failed, retrying," instead of a structured event. It reads fine in the moment, but there's no field to filter or group later, so months of logs become text nobody can search.
• Routing alerts to a channel with no owner. A page nobody answers for gets muted within weeks, and the one alert that mattered rides through the same silence as everything else.
• Adding sampling only once the bill forces the conversation, instead of deciding it alongside the instrumentation itself. Doing it after the fact means guessing which discarded traces might have mattered.

When teams outgrow basic monitoring

A service with three or four known failure modes doesn't need much of this. A handful of threshold alerts covers it; building out tracing is effort spent on a problem the team doesn't have yet.

The trigger is usually one of three changes. A monolith splits into a dozen microservices, and each split is a new integration point, so a slow checkout can no longer be traced to one dashboard once the request crosses eight services. A contract adds a regulated uptime commitment, so a complaint now comes with a clock attached. Or an incident takes two engineers three days to root-cause because nobody can reconstruct what a specific request did, only that something failed somewhere in the chain.

Company size doesn't predict which of these hits first. A ten-person team running microservices under a regulated uptime commitment needs this sooner than a two-hundred-person team running one monolith. Getting there is mostly an instrumentation problem: deciding what to trace, how long to keep it, and where the sampling line sits, usually faster with input from a team that has done it before. Custom software development and product development engagements run into this at that scale, and software development consulting is a reasonable place to start if the question is just whether you're there yet.