Logs, Metrics, and Alerts

The last topic said Pageturn has to be watched once it's live. But Sam can't sit and stare at the site all day, and staring wouldn't tell him much anyway. Watching software in practice comes down to three plain things that do the looking for him — and once you have names for them, every monitoring tool you'll ever see starts to make sense.

Those three things are logs, metrics, and alerts. Logs are the recorded diary of what happened. Metrics are numbers measured over time. Alerts are the automatic taps on the shoulder when one of those numbers crosses a line you care about. Think of a car's dashboard: the trip history is the log, the live gauges are the metrics, and the warning light that flicks on is an alert. (We'll drop the dashboard shortly and use the real terms.)

Logs: the diary of what happened

A log is a recorded event — a single line written down the moment something happens, stamped with the time it occurred. "3:42:07 — Maya's reader logged in." "3:42:09 — error saving a favorite." Strung together, these lines form a log: a timestamped diary of everything the app did, in order.

Logs are where you go to find out exactly what happened, after you already know something is wrong. When a reader reports that saving a favorite failed, Sam opens the logs around that time and reads the actual events leading up to it. Logs are detailed and specific — which is their strength for digging in, and, as we'll see, their weakness if you drown in them.

Metrics: numbers over time

A metric is a number measured repeatedly over time. Not a one-off reading — a value sampled again and again so you can watch it move: how many requests Pageturn handles per second, what fraction of them fail (the error rate), how many milliseconds a page takes to load. Each is a number, tracked as a line on a chart.

Where a log tells you about one event, a metric tells you about the trend. A single failed request is one line in a log; the error rate climbing from one in a thousand to one in ten is a metric, and that's the shape of a problem forming. Metrics are how you see the health of the whole app at a glance, without reading every individual event.

Alerts: automatic warnings

Nobody can watch the charts every minute, so the third piece does it for you. An alert is an automatic warning that fires when a metric crosses a line you set in advance — "tell me if the error rate goes above two percent," "tell me if a page takes longer than three seconds." When the number crosses, the alert reaches out: a message, a page, a notification.

The key word is automatic. An alert means the machine is watching the metrics so a human doesn't have to, and it speaks up only when something actually needs attention. Crucially, a good alert is an early warning — it fires while a problem is forming, not after Pageturn is already down. The point is to look before users feel it.

Putting It Together: Monitoring and Observability

Used together, these three answer different questions: a metric tells you something is wrong, an alert makes sure you notice, and the logs let you dig in and find out why. That after-the-fact insight — understanding what's going on inside a running system from the outside, just from what it reports — is roughly what people mean by observability. One honest caveat: tools usually name the core observability signals as logs, metrics, and a third called traces, which follows a single request across the system. Traces are beyond this beginner course, and an alert is really a notification built on top of a metric rather than a separate signal — but logs, metrics, and alerts are the three you'll meet first.

This is the simplified picture — observability runs deeper than three words, and there are whole tools and a whole craft built on top of it. That's a future course: the Observability Deep Dive picks up exactly here and teaches how real teams collect, store, and read these signals. For now, the three terms — logs, metrics, alerts — are the vocabulary that makes every monitoring screen you'll ever meet readable.