Structured Logging

Structured logging means emitting each log event as data with named fields, such as a JSON object, instead of a free-form sentence. A tool can then query by field rather than guessing with text patterns.

Why it matters

A line like User 4821 failed login from 203.0.113.9 after 3 tries is easy to read but hard to count. Parsing it with regular expressions breaks the moment someone rewords the message. Structured logs let you ask precise questions such as "how many 502s did service=api return per minute," and they feed dashboards and alerts directly.

Example

{
  "ts": "2026-10-08T09:14:02Z",
  "level": "error",
  "service": "api",
  "route": "/orders",
  "status": 502,
  "duration_ms": 5003,
  "request_id": "7f3c9e1a"
}

Consistent field names across services matter more than the exact schema. Include a correlation ID, the severity level, and timing. You can check that a sample line is valid with the JSON validator.

Common mistakes

• Logging secrets, tokens, or personal data. Fields are easy to search, which makes leaks easy to find too.
• Inventing a different field name per team, such as status, code, and http_status.
• Putting high-cardinality values like full URLs with IDs into fields that you also use as metric labels.
• Logging at debug level in production and paying for storage nobody reads.

Related

• Logs
• Log aggregation
• Cardinality
• Observability

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.