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
- Business events — order created, payment taken, status changed, who did it
- Integration calls — what was sent, what came back, how long it took
- Scheduled job runs — start, finish, what was processed
- Authorisation failures, which indicate either a bug or an attack
- 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
| Need | Requires |
|---|---|
| Find one customer's journey | Structured logs with identifiers |
| Spot a pattern | Aggregation across servers |
| Alert on something | Machine-readable format |
| Investigate last month | Retention long enough |
| Prove what happened | Immutable storage |
A log file that can only be read by tailing it on a server is a log nobody consults.