DEBUG vs INFO vs WARN: Use Them Right

Most teams misuse log levels. The right discipline by level, with examples of what should land where.

DEBUG

Log levels are the discipline of choosing when to emit log entries and at what severity. Different levels serve different audiences and access patterns. DEBUG, INFO, and WARN are the three most operationally significant; understanding what belongs at each level produces logs that are useful when needed and quiet when not.

What DEBUG is for:

• Off in production.: DEBUG is too verbose for production. Enabling it produces enormous log volume; the cost spikes; the storage strains; the signal is buried in noise.
• Used in dev to trace execution.: DEBUG is the dev-time diagnostic level. The engineer enables it to trace what is happening in their local environment; the volume is acceptable because it is one engineer's machine.
• If you find yourself enabling debug in prod, the issue is insufficient INFO.: The temptation to flip prod to DEBUG comes when INFO is not capturing enough. The right response is to add INFO-level logging at the missing decision points, not to enable DEBUG broadly.
• Detail of internal logic.: DEBUG logs internal state, branch decisions, intermediate values. Things that help understand internal behavior; things that are not useful for production observability.
• Per-request use.: Some teams use feature flags to enable DEBUG for specific requests in production. The targeting limits volume; the access pattern matches the use case (one specific bug to investigate).

DEBUG is the dev-time tool. Production should rarely need it; when it does, scope it to specific requests rather than enabling globally.

INFO

INFO is the production logging level. The events that matter for understanding production flows go here. Volume is significant; the value is significant.

• Significant events.: Requests received, responses sent, jobs completed. The events that mark important moments in production execution.
• Requests received, responses sent, jobs completed.: Each significant event produces an INFO log. The log contains the relevant context: request ID, user ID, status, duration. The data supports debugging and analysis.
• Useful for tracing real production flows.: An engineer reading INFO logs can trace what happened in production. The flow is reconstructable; the investigation produces understanding.
• Volume: significant but bounded.: INFO produces real volume; it should not be unbounded. The volume scales with traffic; it does not scale per-iteration of internal loops.
• Manage with sampling on high-traffic endpoints.: Some endpoints have such high traffic that even INFO is too much. Sampling at the endpoint produces a representative subset at lower cost. The team gets the visibility without the full bill.

INFO is the workhorse. Most production logs are INFO; most production observability comes from INFO.

WARN

WARN is the level that indicates "something unusual happened but we recovered". It signals issues that deserve attention but did not cause failure. The discipline is using WARN sparingly so that WARN logs actually mean something.

• Recoverable issues.: Retries that succeeded, fallbacks that triggered, deprecation warnings, soft failures. Things that did not break the request but indicate a non-ideal condition.
• Retries, fallbacks, deprecation warnings.: Each is a specific category. A retry that succeeded after one failure is a WARN; a fallback to a degraded path is a WARN; a deprecated API being called is a WARN.
• Anyone reading WARN should consider it actionable.: The bar for WARN is high. If a WARN log entry is informational and not actionable, it should be INFO instead. The distinction matters because WARN dashboards drive operational attention.
• Otherwise it is INFO.: Misclassification of WARN as INFO undersells issues; misclassification of INFO as WARN dilutes signal. The team's discipline at choosing the right level pays off in operational clarity.
• WARN dashboards.: WARN logs feed dashboards that show recent unusual activity. The dashboard is reviewed during incident response and during routine reviews; the data drives investigation.

Debug vs info vs warn levels are one of those engineering disciplines that compound over the system's lifetime. Nova AI Ops integrates with logging telemetry, surfaces level-misuse patterns (DEBUG entries reaching production, WARN entries that are really INFO), and produces the queryable view that the platform team uses to enforce log level discipline.