AddThisFeature

Structured Logging

Turn print statements into searchable records with stable fields.

moderate Developer Experience

What it adds

Every log line becomes a structured event with a fixed field schema, a real severity level, and redaction applied before it leaves the process.

What your agent is told to do

5
  1. 1

    Define the field schema once and write it down: timestamp, level, message, service, environment, release version, and the request or job context. Every log line carries the same field names, spelled the same way.

  2. 2

    Use severity levels with an agreed meaning. If everything is 'info', the levels are decoration. Reserve error for things a human must look at, and warn for things that degraded but recovered.

  3. 3

    Redact at the logging layer, not at the call sites. Maintain a deny list of field names — password, token, secret, authorization, card number, email where policy requires it — and truncate large payloads to a bounded size.

  4. 4

    Do NOT put unbounded high-cardinality values in indexed fields. A user ID is fine; a full URL with query string, a raw SQL statement, or a UUID per line will make the log store slow and expensive.

  5. 5

    Keep human-readable output in local development. Machine-readable JSON in production, pretty lines on a developer's terminal.

Edge cases it handles

6
  • Log lines emitted before the logger is configured must not be lost or crash the boot — buffer them or fall back to plain output.
  • Multi-line content like stack traces must stay in one event, not fragment into a line per frame.
  • Redaction must survive nesting. A token buried three levels down inside a serialized object is still a token.
  • An object that fails to serialize must not raise inside the logger and take down the request. Log the failure and move on.
  • Very high log volume must not become the bottleneck. Sample noisy repeated events rather than dropping them silently.
  • Third-party libraries and the web server write their own logs in their own format — decide whether to adapt them or accept two formats, but do not pretend the problem does not exist.

Definition of done

8
  • Every log event carries the same core fields with identical names.
  • Severity levels are documented and used consistently.
  • Secrets and personal data are redacted at the logging layer, including inside nested objects.
  • No indexed field carries unbounded high-cardinality values.
  • Development output is human-readable; production output is machine-parseable.
  • A serialization failure inside the logger never breaks the request.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.