What to Log

Four categories

Not everything deserves a log entry. Too few logs and you cannot debug. Too many and the noise drowns the signal. The right balance: log what you need to answer the question “what happened?“

1. Requests and responses

Every HTTP request should be logged: who asked, what they asked for, what the server returned, how long it took.

{
  "level": "info",
  "message": "request completed",
  "method": "GET",
  "path": "/v2/books",
  "status": 200,
  "duration": 12,
  "requestId": "req_a1b2c3"
}

This is the foundation. When something goes wrong, the request log tells you what happened, when, and for whom.

2. Errors

Every error should be logged with enough context to understand and reproduce it:

{
  "level": "error",
  "message": "Order creation failed",
  "error": "INSUFFICIENT_STOCK",
  "stack": "Error: INSUFFICIENT_STOCK\n    at createOrder...",
  "requestId": "req_a1b2c3",
  "userId": "user-42",
  "orderId": "order-99",
  "productId": "prod-5"
}

The error message alone (“something went wrong”) is useless. The context (which user, which product, which request) makes it actionable.

[!NOTE] The Error Handling course classified errors as operational (expected, like validation failures) and programmer (unexpected, like TypeError). Both should be logged, but at different levels: operational errors at warn, programmer errors at error.

3. Business events

Events that matter to the business, not just the code:

{"level":"info","message":"order.placed","orderId":"order-99","userId":"user-42","total":29.99,"items":3}
{"level":"info","message":"user.registered","userId":"user-100","method":"email"}
{"level":"info","message":"book.reviewed","bookId":"book-1","userId":"user-42","rating":5}

These logs answer questions like: “How many orders were placed today?” “Which books are being reviewed?” “How many users registered this week?” Business intelligence from logs.

4. Performance

Slow operations should be logged so you can find and fix bottlenecks:

{"level":"warn","message":"slow query","query":"SELECT ... JOIN ...","duration":250,"threshold":100}
{"level":"info","message":"cache hit","key":"top-books","duration":0.2}
{"level":"info","message":"external api call","service":"goodreads","duration":340,"status":200}

[!NOTE] The Caching course tracked cache hit rates. The Background Jobs course monitored queue depth. Performance logging captures these metrics in the log stream, alongside request and error logs.

What NOT to log

Passwords. Never. Not even hashed. Not even partially masked.

Authentication tokens. JWTs, session IDs, API keys. If leaked from logs, attackers gain access.

Credit card numbers. PCI compliance forbids it.

Personal information. Emails, addresses, phone numbers — unless required and protected. GDPR and similar regulations restrict logging PII.

Request/response bodies by default. Bodies can contain any of the above. Log them selectively (e.g., in development mode only).

The Sensitive Data lesson (Section 6) covers redaction in detail.

The logging spectrum

Too little                                              Too much
|-- silent --|-- errors only --|-- requests + errors --|-- everything --|
                                        ↑
                                   Sweet spot

Log requests, errors, business events, and performance. Skip debug traces in production. Never log sensitive data.

Exercises

Exercise 1: Categorize these as request, error, business event, or performance: “user login”, “database query took 500ms”, “404 not found”, “payment processed”, “cache miss”.

Exercise 2: List five things your API should log and five things it should never log.

Exercise 3: Write a JSON log entry for each category: one request log, one error log, one business event, one performance log.