Observability: Logs, Metrics, Traces

Once software is running, you can't just open it up and look inside — it's off on a server somewhere, serving thousands of users. So it has to tell you how it's doing. Observability is the ability to understand what a running system is doing from the outside, built from three kinds of signal: logs, metrics, and traces.

Each signal answers a different question, and together they let you understand and debug a system you can't pause or poke at directly. This is core vocabulary for anyone who runs software.

A car dashboard is the perfect picture: warning lights flag specific events (logs), gauges show numbers changing over time (metrics), and a trip computer follows the whole journey (traces). You drive by what the dashboard tells you, not by opening the engine.

Logs

Logs are timestamped records of individual events — "user 123 logged in", "failed to send email at 9:04". They're the first thing you read when something breaks, because they tell you what happened and when, in detail. A log is the system writing down notable moments as they occur, so you can reconstruct the story afterward.

Metrics

Metrics are numbers measured continuously over time — requests per second, error rate, response time, memory used. Where a log is one event, a metric is a trend you can graph and watch. Metrics answer "how much" and "how often", and they're what tell you, at a glance, whether the system is healthy right now or drifting toward trouble.

Traces

Traces follow a single request as it travels through the system — touching this service, then that database, then this other piece — and show how long each step took. In a system made of many parts, a trace answers "where did this one request slow down or fail?" It stitches the pieces together into the story of one user's journey through the system.

Why All Three

You need all three because each answers a question the others can't. Metrics tell you something is wrong ("error rate spiked"); logs tell you what happened ("database connection failed"); traces tell you where ("the slowdown was in the payment service"). Together they make a system observable — understandable from the outside. Relying on just one leaves blind spots that hurt most exactly when something is breaking.

When Cadence's reminders start firing late, the team uses all three. The logs show an error at send time. The metrics reveal a latency spike every morning at 9 AM. And a trace follows one slow reminder and pinpoints the culprit: a slow database query under the morning load. No single signal would have solved it; together, they turn a vague "reminders are late" into an exact, fixable cause.