Key takeaway
Tie each record to a diagnostic question: which operation failed, which service was affected and when? Keep passwords, tokens and unnecessary personal data out of logs.
What question should a log answer?
An application log records timestamped events produced while software runs. Startup and shutdown, request outcomes, unexpected errors, failed calls to external services and configuration changes answer different investigation questions. Operating-system and server logs describe the surrounding environment; application logs can explain what the application was trying to do.
Operation
The start and outcome of a request, job or integration.
Error
An exception, failed dependency or fault that affects a user.
Change
The time and actor for a release, configuration or privilege change.
Choose fields that explain the event
Consistent fields make records easier to search and compare. Commonly useful fields include time, level, service and environment, event type, outcome, a concise message, a request or trace identifier and, where safe, an error code. Synchronize clocks and make the time zone clear when comparing events across services. Each record does not need every possible detail.
Time and source
UTC or an explicit time zone; service, version and environment.
Event and outcome
A stable event name, outcome and selected log level.
Correlation
A request ID and, when available, trace/span IDs; the identifier itself should not be a secret or account detail.
Use levels consistently
A level signals how urgently a record needs attention, but names and exact meanings depend on the logging library. Agree on a short team vocabulary: DEBUG for extra development detail, INFO for normal milestones, WARN for an unexpected but recoverable condition, ERROR for a failed operation and CRITICAL/FATAL for a severe component failure. Inconsistent levels across services weaken alert rules.
DEBUG / TRACE
Detailed diagnostics; limit volume and sensitive fields in production.
INFO / WARN
Describe normal progress and conditions to watch that are not yet failures.
ERROR / CRITICAL
Support escalation when functionality fails or impact is broader.
Keep structured records readable
A structured format such as JSON gives each event consistent keys, enabling both text search and field-based filtering or correlation. Keep field names and types consistent across services. Use a concise message, put the error type and operation context in separate fields, and retain a full stack trace when it is useful. JSONL is a common format with one JSON object per line.
{"timestamp":"2026-10-09T08:30:00Z","level":"ERROR","service":"billing-api","event":"payment_authorization_failed","request_id":"req-7f21","error_code":"upstream_timeout"}
Keep secrets and unnecessary personal data out
Request content, URL parameters, cookies, tokens, passwords and full user details can enter logs unintentionally. Remove or mask sensitive values at the point of collection and keep only fields needed for the stated purpose. Control access in transit and at rest, limit privileges and preserve change history.
Should every event be logged?
No. Select important operations and investigation questions; excessive noise can hide useful records.
Are level names the same everywhere?
No. Libraries and platforms differ; document your semantics and mapping rules.