Observability Is Not Logging
Adding more logs does not make a system observable. Observability is the ability to ask questions about a running system that nobody anticipated when the system was built.
The system has thousands of logs, and nobody can tell what’s wrong.
This pattern shows up in almost every growing engineering team. They added logging early because it felt responsible, like the right thing to do. Then the first serious production incident arrived, and nobody could find the answer in the logs.
Adding more logs isn’t the same as making a system observable.
Logs are a record of events that happened
A log line says something occurred. It captures a fact at a point in time. That’s useful, but it isn’t enough on its own.
Logs are designed to answer questions you already had when you wrote them. If you logged “order created,” you can confirm an order was created. If you logged the response time, you can look it up. If you didn’t log the right thing at the right moment, the question goes unanswered.
Logs can’t answer questions you forgot to ask.
Observability is about questions you haven’t thought of yet
Observability, in the engineering sense, is the ability to understand the internal state of a system from its external outputs. In practice: can you diagnose an issue you’ve never seen before? Can you answer a question that nobody anticipated when the system was built?
A system with good observability lets you ask arbitrary questions of a running system and get meaningful answers. A system with only logs lets you look up things that someone already thought to capture. Those are different things.
The three signals aren’t the same thing
Most teams think of observability as three things: logs, metrics, and traces. They’re all useful, and they do different jobs.
Logs capture discrete events: something happened, here’s the data at that moment.
Metrics capture shape over time, what the system was doing during a window: rate, volume, error percentage, latency distribution.
Traces capture the path of a request across a distributed system: this request went through these services, in this order, with these durations, and failed here.
The mistake is treating them as redundant. They aren’t. A spike in error metrics tells you something went wrong, a trace tells you where, and a log at that point in the trace tells you what the state was. All three together give you something close to a complete picture.
Most systems have logs and not much else.
Most teams instrument for confidence, not for insight
There’s a pattern that shows up across codebases: log on entry, log on exit, log errors, log the response.
That feels like good coverage, but it only confirms expected behaviour. It’s designed to prove the code ran, not to help you understand why something went wrong under conditions you didn’t anticipate. So when something unusual happens, the logs confirm the code ran and the metrics show something is wrong, but nobody can say why.
Instrumenting for insight is different. It means asking: if something breaks in a way we’ve never seen before, what information do we need to diagnose it? That changes what you log, what you measure, and what you trace.
Product observability is different from infrastructure observability
Infrastructure observability asks: is the service running? Is the database healthy? Are requests being processed?
Product observability asks: are users actually succeeding? Where are they failing? Which paths lead to value and which don’t?
Both matter, but most teams invest heavily in the first and almost nothing in the second.
This is also why observability isn’t just an engineering concern. In systems that need to grow, the ability to detect problems before they compound is foundational. Without product-level visibility, the first signal of something wrong is often a user report, not a dashboard.
Product-level instrumentation means tracking business events: a user completed a checkout, an import failed at this step, a search returned zero results, a workflow timed out. Not just that an error occurred, but what the user was trying to do and where the system stopped delivering.
This is where observability becomes useful to people outside engineering. Support, product, and operations can all make better decisions when they can see what’s actually happening in the product, not just whether the servers are green.
The instrumentation should answer business questions
The practical starting point isn’t to add more logs. It’s to write down the questions that matter.
What does a successful user session look like? What does a failed one look like? Where are the drop-off points in a high-value workflow? Which errors have the most business impact?
Once the questions are clear, the instrumentation follows. Logs go in places where the answer would be useful. Metrics track the things that matter to the product. Traces cover the paths where latency has a real consequence.
Without that framing, observability work becomes a series of guesses about what future-you might want to know.
The question is not “are we logging enough”
The useful shift isn’t from fewer logs to more logs. It’s from reactive instrumentation to intentional instrumentation. A system with thoughtful metrics, meaningful traces, and well-placed logs is easier to understand and faster to debug than one with thousands of undifferentiated log lines and no other signals.
So the real question isn’t whether the system is logging enough. It’s this: if something breaks in a way we’ve never seen before, can we figure out what happened?
If the answer is no, the system isn’t observable. Adding more logs won’t fix that.