Being Able to Find Out What Happened

Logs are for answering questions later

The question is rarely “what error occurred?” It is “why did this customer's order end up in this state?” Answering that needs business events logged, not just exceptions.

A log full of stack traces and empty of business events tells you what broke and nothing about what happened.

What to log

1. Business events — order created, payment taken, status changed, who did it
2. Integration calls — what was sent, what came back, how long it took
3. Scheduled job runs — start, finish, what was processed
4. Authorisation failures, which indicate either a bug or an attack
5. Errors, with enough context to reproduce them

Correlate with a request identifier

Generate an identifier at the start of each request and include it in every log line for that request, including any queued jobs it triggers.

That single practice turns log investigation from guesswork into filtering, and it costs almost nothing to implement.

Keep personal data out

• Log identifiers, not names and addresses
• Never log passwords, tokens or card details, even in error handlers
• Redact before logging rather than after
• Apply a retention period, automatically
• Remember logs are in scope for data requests

Make them searchable

A log file that can only be read by tailing it on a server is a log nobody consults.

Frequently asked questions