Track Errors First

Summary

Track Errors First Klaas van Schelven; June 4 - 5 min read Observability usually means collecting dashboards, traces, metrics, and logs — or at least, that’s how it’s sold. What’s often missing from that conversation is the most valuable signal of all: errors. When an exception is raised, your code is telling you: this was not supposed to happen. Not just that something is slow, or that usage is spiking — but that your assumptions, as a programmer, just failed. That makes an exception — a real, raised error — the single most useful event you can track. If you’re building out observability, whether for the first time or revisiting an existing setup, start with that. The three pillars of observability The standard model splits observability into three pillars: logs, metrics, and traces. They’re helpful, but something is missing — and if you only follow this model, you’ll miss it too. Logs tell you what the system thought was worth noting. Metrics show trends over time: request duration, error rates, cache hit ratios. Traces give a sense of flow: what did this request call, and how long did it take? All of those are useful. But none of them tell you where the code broke. For that, you need proper error tracking. Signal Over Noise There’s nothing more direct than a thrown exception. You don’t have to guess whether it’s important. It’s the system saying: this should not have happened, and here’s the line where it went wrong. Right to the heart of the problem: a stacktrace with local variables And because exceptions are so rare – so high-signal – it’s worth going deep when they happen. You want to capture: The full stacktrace — readable, with line numbers and source references Local variables — so you know what was actually passed in Request data — like URL paths, headers, or session info User context — who was affected, what were they doing? You can’t get this from a metric. And you usually don’t get it from a log line unless you’ve done a lot of extra work. So instead o...