Logs Are Evidence, Not Decoration

The starting point

A log line is valuable when it helps answer a question. 'Something went wrong' is technically a log, but it gives an engineer almost nothing to work with. Good logs establish context: what operation was happening, what resource was involved, what decision was made, and what error occurred. The goal is not maximum log volume. The goal is useful evidence.

Context makes logs actionable

Consider a failed article query. A useful diagnostic might identify the operation, article identifier or route, and database error class without exposing secrets. That information lets an engineer connect an application symptom to a lower-level event.

Structured logs can make this even easier because fields can be searched and aggregated. But structured logging does not automatically make logs useful. The event still needs the right context and a sensible severity level.

Avoid logging everything

Dumping complete requests, tokens, cookies, database rows, or arbitrary objects can create security and privacy problems while making important events harder to find. Logging should be deliberate. Secrets should never become a debugging convenience.

A mature logging strategy therefore asks what someone will need when the system behaves unexpectedly. That answer should shape the fields, not the desire to have more lines in a terminal.

• Include useful context