When and what should I be logging?

Summary

Targeted structured logging provides a fast way to capture operational behavior in production without requiring new deployments for debugging. Developers benefit most from logging key runtime decisions, multi-step algorithm outcomes, mutating audit operations, and context around non-critical or retried errors. Rather than outputting plain text, applications should record structured key-value pairs that capture who performed an action, what occurred, and associated trace identifiers. Sensitive information such as secrets and personally identifiable data must be excluded or scrubbed, and large unparsed payloads should be avoided to prevent excessive costs. Managing log levels appropriately and treating logs as potentially temporary instrumentation helps maintain actionable telemetry without generating unnecessary noise.

Context

Choosing among telemetry options like traces, profiles, metrics, and logs can be difficult when building and debugging applications. Developers need fast, reliable ways to capture production runtime behavior without over-instrumenting code or leaking sensitive data.

Approach / What changed

The author recommends starting with targeted, structured key-value log lines to capture runtime decisions, multi-step algorithm outcomes, audit events, and non-critical error context. Structured logs should accumulate request context, include trace identifiers, use appropriate log levels, and avoid full payload blobs, passwords, or personal data.

Takeaways

• Structured logs using consistent key-value pairs enable searching, visualizations, and alerts, while answering who performed an action, what happened, and when it occurred.
• Applications should log runtime decision branches, intermediate algorithm progress, mutating audit events, and failure context such as retry counts instead of logging every line of code.
• To manage security, compliance, and volume costs, sensitive data and secrets must be scrubbed or replaced with opaque IDs, and large unstructured payloads should be avoided.

Related reading

• Sentry · May 7, 2026

  Fixing JavaScript observability, one library at a time

  JavaScript application performance monitoring tools rely on monkey-patching via require-in-the-middle and import-in-the-middle, which breaks with ECMAScript Modules, bundlers, and non-Node runtimes. To solve this, an initiative is replacing monkey-patching with Node's built-in diagnostics_channel TracingChannel API across server-side JavaScript libraries. Under this pattern, libraries publish structured events while monitoring vendors subscribe to them with zero overhead when unlistened. The author leveraged Claude Code workflows alongside direct maintainer communication to draft proposals, implement code, and manage reviews across 44 target packages. Ten libraries including mysql2, node-redis, ioredis, and unjs modules have merged support, while active efforts continue on shared OpenTelemetry mapper registries and remaining ecosystem packages.

  Abdelrahman Awad

• Sentry · Jun 5, 2026

  Errors, traces, logs, metrics: when to reach for what