My first job was a social service placement at the national telegraph office, and it contained the entire lesson without me noticing.
Everything was documented by hand, in folders. My manager’s office was full of them — years and years of samples, carefully taken, carefully filed. Nobody ever opened those folders again.
The data existed. It was accurate. It was useless, because there was no way to ask it anything.
Twenty years later I watch organizations do exactly the same thing with terabytes instead of paper, and pay a great deal for the privilege. Collecting and being able to interrogate are two different things, and almost all the value is in the second.
🔑 The short version
- Monitoring answers questions you thought of in advance. Observability answers ones you did not.
- The practical test: can you investigate a failure nobody predicted, without deploying new code?
- It is built on metrics, logs and traces — but having the three is not the same as having observability.
- The classic trap is the average: a national number in the green while a whole region is down.
- Seeing is necessary and not sufficient. Ask what you are permitted to fix.
Monitoring versus observability, without the sales pitch
The difference is not the volume of data and it is not the price of the tool. It is what kind of question you can ask.
| Monitoring | Observability | |
|---|---|---|
| The question | Is what I expected to break, broken? | Why is this behaving strangely? |
| Prepared | In advance. You defined the checks | Not required. You explore |
| Good at | Known failures | Failures nobody anticipated |
| Fails when | Something breaks in a new way | Nobody knows what to ask |
Notice the last row, because vendors skip it. Observability does not remove the need for a person who knows what to ask. It removes the need for that person to have predicted the question six months earlier.
The practical test
Forget definitions. Here is how I judge it in a real environment:
Can you investigate a failure nobody anticipated, right now, without deploying anything?
If answering “why are checkouts slow only for customers in the north, only on mobile, only since Tuesday” requires adding new instrumentation and waiting for a release, you have monitoring. Good monitoring, possibly. But the question you actually have is one your system cannot answer.
That is the whole distinction, and it is checkable in one meeting.
The three signals, and why having them is not enough
Observability is usually built on metrics, logs and traces. Briefly:
- Metrics — numbers over time. Cheap, aggregated. Tell you that something changed.
- Logs — recorded events with detail. Tell you what happened. Expensive at volume.
- Traces — one request across every service. Tell you where the time went.
But owning all three is not the same as being able to interrogate them. That is the telegraph office again: the folders were complete and nobody could ask them a question.
What turns three signals into observability is whether they are connected — whether you can move from a metric spike to the logs of that moment to the trace of one affected request without re-entering the problem by hand in three different tools.
The trap that catches everyone: the average
Years ago I worked on a national voice network with hundreds of sites. The availability dashboard was consistently, honestly green.
And small sites were down. Regularly. Twelve people with no service disappear completely inside a national average calculated over hundreds of locations. The metric was not wrong. It was answering a question nobody had asked.
That failure mode has never gone away — it just changed hardware. It is the same reason one overheating accelerator can slow an entire training cluster while utilization graphs look excellent.
Seeing is not fixing
This is the part I would most want a newcomer to hear, because it took me years and a lot of frustration.
For a long stretch I was accountable, every month, for a voice quality number I had no authority to change. The policies governing it belonged to the connectivity provider. We were permitted to look. When the fault came from their side, that side showed us nothing.
Responsible for the number. No authority to move it. No visibility into the half that was failing. Reporting on it regardless.
A metric you answer for but cannot influence is not a metric. It is theater.
So when a platform promises total visibility, my question is no longer what we will be able to see. It is and of what we see, what are we permitted to fix? Visibility is necessary and it is not sufficient, and this industry has spent two decades quietly conflating the two.
Where to start, honestly
- Write down the last three incidents and the question you could not answer. That list is your requirements document, and it is more useful than any feature comparison.
- Measure the user journey, not the components. “Could the customer pay” beats twelve green components every single time.
- Connect the signals before you buy more of them. Most teams have more data than they can interrogate already.
- Standardize the format early so today’s tool choice is not permanent.
- Ask who is allowed to act on what you are about to be able to see.
On the open standard for producing this telemetry and the foundation behind it: OpenTelemetry and the Cloud Native Computing Foundation.
Frequently asked questions
What is observability, in simple terms?
It is the ability to understand what is happening inside a system by examining the data it emits, including for failures nobody anticipated. The practical test is whether you can investigate an unexpected problem right now, without deploying new instrumentation and waiting for a release. If answering a new question requires a code change, you have monitoring rather than observability.
What is the difference between monitoring and observability?
Monitoring answers questions you defined in advance — it checks whether the things you expected to break are broken. Observability lets you ask questions you did not anticipate. Monitoring fails when something breaks in a new way; observability fails when nobody knows what to ask. It does not remove the need for someone who understands the system, only the need for them to have predicted the question months earlier.
Is having metrics, logs and traces the same as having observability?
No. Those three signals are the raw material, but owning them is not the same as being able to interrogate them. What makes the difference is whether they are connected — whether you can move from a metric spike to the logs of that moment to the trace of one affected request without re-entering the problem by hand in three separate tools. Data that cannot be questioned is an archive, not observability.
Why do averages hide outages?
Because an aggregate is designed to smooth away outliers, and a small group of affected users is an outlier. A national availability figure can sit comfortably in the green while an entire region has no service. The fix is not a better average — it is looking at the distribution, or breaking the metric down by the dimension where failure actually clusters, such as site, region or customer segment.
Where should a team start with observability?
Write down the last three incidents and, for each, the question you could not answer. That list is a better requirements document than any feature comparison. Then measure the user journey rather than individual components, connect the signals you already have before buying more, standardize the telemetry format so today’s tool choice is not permanent, and ask who is authorized to act on what you are about to be able to see.
What I take from this
I keep returning to that office full of folders.
Nobody there was careless. The samples were taken properly, recorded properly, filed properly. The organization had done the hard, disciplined work of collecting — and got nothing back, because collecting was the part they knew how to do, and asking was the part nobody had built.
The industry sells the opposite emphasis. Every conversation starts with how much more you could be capturing. Almost nobody’s real problem is capture. The problem is that the data you already have cannot be interrogated fast enough by a tired person at two in the morning.
So if you take one thing from this: before buying anything, write down the last question you could not answer during an incident. If the tool in front of you cannot answer that one, more data will not help — you will just have a larger room full of folders. 🗂️
May the systems be with you. ✦
Featured image generated with artificial intelligence.
Ethel Méndez
Senior Product Manager in B2B observability and networking, with 20 years of field work, NOC and managed services across Latin America. I write what I learned running real systems, not what I read in a course.