Log Levels

Log levels express the significance of an application event and help control logging verbosity. A common ordering, from most detailed to most severe, is TRACE, DEBUG, INFO, WARN, ERROR, and FATAL or CRITICAL. Frameworks differ in their supported names and numeric values, so applications should define and document their conventions rather than assume that every logging system uses the same scale.

TRACE typically captures fine-grained execution details, while DEBUG records information useful during diagnosis, such as retry decisions or selected configuration values. INFO describes expected operational events, such as a job starting or an order completing. WARN identifies an unexpected condition that does not currently prevent the operation from succeeding, such as a dependency timeout followed by a successful retry. ERROR indicates that an operation failed. FATAL or CRITICAL usually describes a condition that prevents a process or major component from continuing, although assigning that level does not itself terminate the process.

A logger's configured threshold normally includes that level and more severe levels. For example, an INFO threshold generally emits INFO, WARN, ERROR, and FATAL events while suppressing DEBUG and TRACE. Setting DEBUG therefore increases diagnostic detail; it does not mean recording only DEBUG events. Handler, collector, and destination filters can impose additional restrictions, so engineers must check the complete logging pipeline when an expected event is missing.

In cloud applications, use a logging library rather than scattered unstructured print statements. Emit structured records, commonly JSON, with a timestamp, severity, service name, deployment environment, message, and request or trace identifier. Include relevant application state, such as an operation name, attempt count, duration, or sanitized error code. For a payment request, an INFO event might record completion, a WARN event might describe a recoverable retry, and an ERROR event might record failure after retries are exhausted. Avoid repeatedly logging the same exception at every layer; capture it where useful context and the final outcome are known.

Production applications often use INFO as a baseline and temporarily enable DEBUG for a specific component during an incident. This is a starting point, not a universal rule: high-throughput applications may need more selective logging. Configure levels through deployment settings or controlled runtime configuration, and restore normal verbosity after troubleshooting. More verbose logging increases ingestion, storage, and query costs and may add CPU, serialization, and network overhead. Guard expensive diagnostic calculations because some logging APIs evaluate arguments even when the event is suppressed.

Centralized cloud logging services collect and search records, but collection alone does not guarantee correct severity classification. Configure severity in application instrumentation and preserve it through transport. Filtering a search to ERROR does not recover DEBUG events that the application never emitted, nor does it avoid the ingestion cost of records already collected. Establish retention and access controls separately from severity thresholds.

Severity must reflect application impact rather than exception presence alone. An expected validation rejection is not automatically an ERROR, and a recovered transient failure need not trigger paging. Build alerts from meaningful error rates, repeated failures, or customer impact rather than every individual error record. Never log credentials, tokens, or sensitive payloads at any level; DEBUG is not a security exemption. Finally, logs complement metrics and traces: severity helps prioritize events, while correlation identifiers connect those events across distributed requests.