Logging and Observability

Observability is how you understand a production system from the outside. Logs, metrics, and traces answer different questions. Together, they help you find failures, measure impact, and confirm fixes.

Structured Logs

Structured logs are machine-readable objects, not only strings.

type LogEvent = {
  level: "info" | "warn" | "error";
  message: string;
  requestId: string;
  userId?: string;
  route?: string;
};

function log(event: LogEvent) {
  console.log(JSON.stringify(event));
}

Include request ids so one user action can be followed across handlers, workers, and downstream services.

Metrics and Traces

Metrics answer aggregate questions:

How many requests are failing?
How slow is the checkout endpoint?
How many jobs are waiting in the queue?

Traces answer path questions:

Which service made the request slow?
Did the database call or third-party API call dominate latency?

NOTE

Alerts should fire on user-impacting symptoms, not every internal detail. A high error rate on login matters more than a single retryable job failure.

Safe Logging

Never log passwords, session tokens, API keys, full payment data, or sensitive personal information. Redact aggressively at logging boundaries.

TIP

Add request ids early in the stack. Every later log line becomes more useful when it carries the same correlation id.

Further Learning

Search these terms to go deeper:

“structured logging best practices” — searchable production logs
“RED metrics rate errors duration” — service health metrics
“distributed tracing explained” — following requests across services
“OpenTelemetry backend observability” — common observability standard

Logging and Observability

Once your app is live, you can’t just watch it run — you need it to tell you what’s happening. Observability is the umbrella term for logs, metrics, and alerts that let you understand a running system from the outside.

Log as structured data, not just text

Instead of a plain sentence, log an object with useful fields you can search and filter later:

function log(event) {
  console.log(JSON.stringify(event))
}

log({ level: 'error', message: 'Payment failed', requestId: 'abc123', userId: 'u_42' })

TIP

Give every request a unique request id, and include it in every log line for that request. Later, you can pull every log related to one specific user action, even across different services.

Track the big-picture numbers (metrics)

Metrics answer questions like “how many requests are failing right now?” or “how slow is checkout?” — aggregated numbers over time, not individual log lines.

Alert on what users actually feel

NOTE

Alerts should fire for things users would notice — like a spike in failed logins — not for every tiny internal hiccup. Too many noisy alerts and people start ignoring all of them.

Never log secrets

WARNING

Never write passwords, session tokens, API keys, or full payment details into logs. If in doubt, redact it before logging.

In one sentence

Observability means logging structured, searchable events (with a shared request id), tracking aggregate metrics for the big picture, alerting only on user-facing problems, and never logging secrets or sensitive data.

Want to go deeper?

Switch to Expert mode above for distributed tracing and the RED metrics framework (rate, errors, duration).