GuideApr 26, 2026~8 min · intermediate

Monitoring: logs, alerts, uptime

The worst way to learn prod is broken is from an angry customer. Monitoring is knowing before they do. Here are the three layers I set up: structured logs, metrics, and alerts that don't cry wolf.

Stacklogsmétriquesalertesuptimepino

The three layers

Monitoring isn’t a tool, it’s three questions: what happened (logs), how is the system doing (metrics), and am I warned when it goes wrong (alerts)?

logsthe detail of a specific event, to investigate

métriquesnumbers aggregated over time (latency, errors, CPU)

alertesa notification when a threshold is crossed

uptimean external check: is the site up, seen from outside?

Structured logs

A free-text console.log is unreadable as soon as volume grows. A structured (JSON) log is filterable, searchable and aggregatable — you find all of a user’s errors in one query.

logger.tsTSCopy

import pino from "pino";
const log = pino();
// un log STRUCTURE (JSON) : filtrable, cherchable, agregeable
log.info({ userId, orgId, route: "/api/invoices", ms: 42 }, "invoice fetched");
log.error({ err, userId }, "invoice fetch failed");
// >> pas de console.log("truc " + x) : illisible a grande echelle

Worth noting

For an AI agent, the same logic gives tracing: every step visible and searchable, as in trace and score an agent.

Useful alerts

An alert that fires too often ends up ignored — that’s alert fatigue, and it’s worse than no alert at all. Alert on symptoms that matter to the user, not on every technical twitch.

Error rate

The % of 5xx requests crosses a threshold: something is broken, now.

Latency

The p95 spikes: the app is slow for a real share of users.

External uptime

A ping from outside every minute: is the site actually responding?

Saturation

Disk full, DB connections maxed: the foreseeable outages, to catch before the crash.

Where to start

·first a simple external uptime check + alert: the bare minimum, in 5 minutes;

·then centralized structured logs (CloudWatch, Grafana, Sentry for errors);

·finally metrics and a dashboard: latency, error rate, traffic;

·one clear alert channel (Slack, PagerDuty) — not ten places to watch.

Careful

Don't monitor everything at once. An uptime check and an error-rate alert already cover most real outages.

Sources & further reading

01Google SRE Book — Monitoring Distributed SystemsThe four golden signals (latency, traffic, errors, saturation) and the rule “alert on symptoms, not causes”.↗02Google SRE Workbook — Alerting on SLOsTurning an SLO into an alert: burn rate, multiple windows, error budget — the anti-alert-fatigue recipe.↗03OpenTelemetry — Observability primerThe settled definition of logs, metrics, traces and spans, and why correlating them changes everything when investigating.↗04Pino — Super fast, all natural JSON logger for Node.jsThe docs for the logger used in the example: JSON output, levels, child loggers, serializers, transports.↗05AWS — Using Amazon CloudWatch alarmsMetric alarms, log alarms and composite alarms — the latter exist precisely to cut alert noise.↗06AWS — Synthetic monitoring (canaries) with CloudWatch SyntheticsThe outside-in check: a script replaying the customer journey, as often as once a minute.↗07Sentry — Alerts best practicesFilters, triggers, channel routing: how to keep alerts valuable and not too noisy.↗

In short

Monitoring turns outages from surprises into non-events: you're warned, you have the logs to understand, and you fix before it shows. Start minimal — uptime + error rate — and grow. The goal isn't to see everything, it's to know before the customer.

Grafana — Getting started ↗