Observability vs monitoring: what a small team needs first

Observability vs monitoring comes down to one difference: monitoring tells you that something is wrong, and observability lets you find out why. Monitoring watches signals you chose in advance. Observability lets you ask new questions of your data during a problem nobody planned for.

You need both, in that order. This guide compares them, shows where telemetry and the three pillars fit, follows one outage from alert to cause and sets out what a small team should build first. If customers find your outages before you do, our DevOps consulting services set up alerts tied to what customers feel, plus the on-call routine behind them.

Observability vs monitoring at a glance

Monitoring is for failures you can predict, and observability is for the ones you cannot. Both draw on the same raw data, called telemetry, so the real difference is what each one does with it.

The DORA research program draws the line this way: monitoring is based on gathering "predefined sets of metrics or logs", while observability is based on "exploring properties and patterns not defined in advance". The table compares the two with telemetry, because the three terms are often used as if they meant the same thing.

Treat these as two jobs, not two products. The line in monitoring vs observability is softer than most comparison pages suggest. Google's SRE book says a monitoring system should answer "what's broken, and why?", and DORA says monitoring should help you understand why. A team with good logs and instrumented code already does some of both.

What monitoring does well, and where it stops

Monitoring tells you quickly that a known signal has crossed a line. It stops at the symptom: it reports what is broken, and it can only report what someone thought to measure.

Start with the four golden signals from the SRE book: latency, traffic, errors and saturation. The book's advice is that if you can measure only four metrics of a user-facing system, these are the four. Saturation means how full the service is, measured on whichever resource runs out first.

Good monitoring is also quiet. The Prometheus alerting guidance says to keep alerts few and to alert on symptoms tied to end-user pain, not on every possible cause. Paging a person is expensive, and the SRE book warns that teams who get paged too often start to ignore real alerts.

The limit shows up when the failure looks healthy from the outside. The SRE book notes that an error can be implicit, such as an HTTP 200 success response with the wrong content. No threshold on your error rate catches that. The same gap is why LLM observability scores answers as well as counting failed requests.

What observability adds

Observability adds the ability to investigate a failure nobody predicted, without shipping new code first. It is a property your system earns through instrumentation, not a tool you install.

The word comes from control theory. The CNCF observability whitepaper quotes the original meaning: how well a system's internal states can be inferred from its external outputs. Software has the same test. OpenTelemetry's primer calls an application properly instrumented when developers do not need to add more instrumentation to troubleshoot an issue, because they already have the information they need.

In practice that means three habits. Give every request an ID that follows it across services. Record useful context on each step, such as the release version, the region and the customer's plan. Keep that data queryable, so you can slice it by a dimension you did not plan to use. A dashboard answers the questions you built it for, while a queryable store answers the one you have during an outage.

Observability vs monitoring vs telemetry

Telemetry is the data, monitoring is the watching and observability is the ability to explain. OpenTelemetry defines telemetry as data emitted from a system and its behaviour, in the form of traces, metrics and logs.

So telemetry vs observability is raw material vs what you can do with it. You can collect a great deal of telemetry and still be unable to explain an outage, usually because the signals sit in separate tools with nothing linking them.

OpenTelemetry is the open standard for producing and moving that data. It is vendor- and tool-agnostic, and it is not a place to store or view your data: you send it to a backend of your choice. As of October 2026, its status page lists the tracing and logging specifications as stable, the metrics API and protocol as stable with a mixed SDK, and the profiles protocol as still in development. Instrumenting with it keeps your options open if you change backends later.

The three pillars of observability

The three pillars of observability are metrics, logs and traces. Metrics show that something changed, traces show where a request spent its time and logs record what happened at one moment.

• Metrics. Numbers aggregated over a period, such as error rate or request rate. They are cheap to keep and fast to alert on, but they rarely name the cause.
• Traces. The path of one request through your application, split into spans for each step. A trace shows which step was slow or failed.
• Logs. Timestamped records of single events. They hold the detail, such as the exact error message, and they are hard to search without a way to narrow them down.

Having all three does not make a system observable. The CNCF whitepaper prefers the name "primary signals" for two reasons. They are not always needed at the same time, and metrics and logs with occasional tracing can be a valid way to control cost. Other signals, such as continuous profiles, are also growing in use.

What matters is whether you can move between signals. OpenTelemetry's SDKs can correlate logs with traces by adding trace and span IDs to each log record. Exemplars do a similar job for metrics, attaching an example trace ID to an aggregated number. That shared ID turns three piles of data into one story.

One outage, from alert to root cause

Monitoring raises the alarm and observability finds the cause. This invented example shows where one hands over to the other, for a SaaS product whose checkout slows down after a release.

1. Symptom alert. The latency alert on checkout fires. Errors have barely moved, so nothing is obviously down.
2. Dashboard. The golden signals show normal traffic and flat saturation, with latency up on a single endpoint. Load is ruled out. Monitoring has done its job, and this is where it stops.
3. Slow trace. You open a slow trace for that endpoint. Most of the time sits in one span, a call to an outside tax service, and the call repeats three times.
4. Log line. The trace ID leads to the log line for that span: a timeout, followed by a retry. The release version on the span matches the release that went out before the alert.
5. Root cause. The release changed the client's timeout and retry settings, so one slow dependency now holds each checkout open. You roll back, then fix the setting.

The last step matters most. Once you understand a failure, it is no longer unknown, so add a check for it, such as an alert on latency to that dependency. Each investigation turns into a new piece of monitoring, and the alerts get closer to the failures your system really has.

Which one does a small team need first?

Start with monitoring: a few alerts on what customers feel, and someone who answers them. Add tracing when your logs can no longer explain a failure, which usually happens as the number of services grows.

For a small team, observability vs monitoring is a question of order, not a choice. Keep it simple on purpose. The SRE book says a Google SRE team of 10 to 12 people typically has one or sometimes two members whose main job is monitoring. A startup does not have that person, so every dashboard and alert you add is one more thing to maintain. The table sets out a sensible order.

An SLO, or service level objective, is a target for a measured behaviour of your service, such as the share of checkouts that finish successfully. It gives alerts a better basis than a fixed threshold. The SRE workbook uses the example of a 99.9% SLO over 30 days, which leaves an error budget of 0.1% of events. A burn-rate alert fires on how fast you are using up that budget, so a brief blip stays quiet and a serious problem pages someone.

What observability costs, and how to control it

Observability costs grow with the detail you keep, so decide what you need before you send everything. The three levers are metric cardinality, trace sampling and retention.

Cardinality is the number of unique metric series you collect. The CNCF whitepaper gives the scale: 100 data centres with 10,000 hosts each produce about 1 million series for a single metric, and the true cost of metric storage grows with cardinality. For a small team the usual mistake is simpler. A label such as user ID creates a new series for every user, so put details like that on spans and logs instead.

Sampling means keeping a representative share of traces. OpenTelemetry calls it one of the most effective ways to reduce observability costs without losing visibility, and it also warns that sampling carries costs of its own, including missing information you later need. At low traffic you may not need it at all.

Retention is the simplest lever. Decide how long you really look back at raw logs and traces, and keep only that much. Check logs for personal data and secrets at the same time, because anything you store there becomes something you have to protect.

How we set up monitoring and observability

We start with what customers feel: alerts on failed checkouts or slow pages, an on-call rota and runbooks your team can follow. Tracing comes next, where your system needs it, with instrumentation you own. Our DevOps consulting covers that work, and our cloud consulting services help when the bill for all this data needs an owner.

If something is already failing, our production incident response work starts with the outage and ends with the checks that catch it next time. The work is led by Thanos Gkanas, our Head of Engineering. Every engagement is under an NDA, and the IP is always yours.

Frequently asked questions