Logging in Production: What to Log, What to Skip

The first time I took my logs seriously was the first time I had to debug something I could not reproduce. After that incident I rewrote my logging strategy from scratch. Six months later, here is what stuck and what I stopped logging on purpose.

What I Always Log

Every request gets at minimum:

• Request ID (generated at the edge, propagated through all services)
• User ID (if authenticated)
• Method and path
• Status code
• Duration in milliseconds
• Any business-relevant identifiers (post ID, category ID, whatever the request acted on)

That is the baseline. I cannot debug anything without those six fields.

What I Log Selectively

Inside business logic I log decisions, not steps:

log.info('cache_miss', key=k)  # good: a decision
log.info('loaded variable x')   # bad: too granular

A "cache_miss" log tells me something interesting happened. A "loaded variable x" log is noise. If I want the variable, I reconstruct it from the request ID and the cache state.

What I Never Log

Some things never hit the logs:

• Passwords, tokens, API keys: obvious
• Full request bodies: too much data, often contains secrets
• Full response bodies: same reason, plus churn
• Personal identifiable information: names, emails, addresses

If I need to log something sensitive, I log a hash or a truncated identifier. Never the raw value.

The Structured Format

Everything is JSON, one log entry per line:

{
  "ts": "2025-10-17T14:00:00Z",
  "level": "info",
  "request_id": "r_abc123",
  "event": "cache_miss",
  "key": "posts_list_page_1"
}

Structured logs are queryable. Unstructured logs are an archaeological site. The extra five minutes to set up a JSON formatter saves hours every incident.

Sampling the Noisy Stuff

Not every event needs 100% capture. High-volume debug events get sampled at 10% or 1%. A request ID is still logged at 100%, but a "fast path hit" debug line gets dropped most of the time. That keeps the log volume manageable and the signal-to-noise ratio readable.

Logging is cheap to set up and expensive to retrofit. Spend the afternoon now. You will thank yourself during the next production incident.

Read the AWS structured logging guidance for the pattern.