Overview

Debug logging is for troubleshooting. It increases visibility into system behavior, but it can also increase noise and overhead—especially in production—so use it intentionally.

Related: Audit logs.

Log levels (typical)

| Level | What it’s good for | | --- | --- | | Error | Production defaults; only failures | | Warning | Failures plus warnings that may become failures | | Info | Operational visibility (startup, key lifecycle events) | | Debug | Deep troubleshooting (high volume) |

Higher verbosity includes all lower levels.

Output destinations

Depending on deployment, logs may be written to:

file (persistent, easy to share with support)
console (real-time viewing)
database (queryable, if enabled)

File rotation (recommended)

To avoid disk issues:

set max file size limits
cap the number of retained files
archive logs when troubleshooting is complete

Protect sensitive data

Never log secrets. Ensure sensitive fields (passwords, API keys, tokens, secrets) are masked or redacted before storage.

Best practices

Enable debug logging only when needed, then turn it off.
Reproduce the problem with the smallest possible run (1–3 endpoints).
Pair debug logs with a specific time window and user/session context.

Debug Logging