Log Levels Explained: When to Use Debug, Info, Warn, and Error

Key takeaways

• Debug records diagnostic detail, info records normal milestones, warn highlights concerning conditions, and error records operational failures.
• An exception or HTTP status code does not determine severity without application context.
• A recovered retry and an exhausted operation should produce distinguishable events.
• Severity describes an event; alerting decides whether its impact requires someone to act.

Log levels classify the significance of events so people and logging systems can filter them consistently. The common levels debug, info, warn, and error distinguish diagnostic detail from normal activity, concerning conditions, and operational failures.

Suppose an export worker times out while uploading a report, retries, and succeeds. That history is different from an export that exhausts its retries and never produces a report.

If both paths emit the same error message, operators cannot tell whether the system recovered without reconstructing every request.

A Practical Log-Level Reference

Treat this table as a team convention to adapt and document, rather than a universal rule enforced by every library.

Level	Typical meaning	Export-worker example
Debug	Detail useful for diagnosis	An upload attempt is being retried
Info	Normal milestone worth retaining	The export completed
Warn	A concerning or degraded condition	The primary storage path failed and a fallback was used
Error	An operational failure needing visibility	The export could not complete after retries

An expected business outcome, such as rejecting an invalid request, does not automatically belong at error. Severity should reflect the event’s meaning in the service.

Debug Explains the Path Taken

Debug events describe decisions and intermediate activity that help reconstruct behavior.

For the export worker, useful details might include the attempt number, selected destination, or backoff delay. Recording every processed row is unlikely to help unless the investigation specifically needs it.

{
  "level": "debug",
  "event": "report.upload.retry_scheduled",
  "job_id": "job_842",
  "attempt": 2,
  "delay_ms": 500,
  "message": "Upload retry scheduled"
}

Debug does not mean harmless. Payloads can contain sensitive data, and preparing a large diagnostic object can be expensive even when a logger eventually filters the event. Use the library’s level checks or lazy evaluation where necessary.

Info Records Useful Normal Milestones

Info captures normal activity worth retaining: a worker starting, an export completing, or a batch finishing with a useful summary.

For an export, include its job ID, duration, and outcome. That provides a record support staff can use when someone asks whether the report was produced.

Avoid making every function announce its entry and exit at info. The additional volume can hide meaningful events without explaining the operation any better.

Whether every successful request needs a log depends on traffic, support needs, and the other telemetry available. Metrics may already provide the aggregate completion count.

Warn Highlights Conditions Worth Attention

A warning describes a concerning situation that has not necessarily caused the surrounding operation to fail.

For example, the worker might complete an export through a slower fallback after its primary storage service becomes unavailable. The customer received the report, but the system is operating in a degraded state.

Not every successful retry deserves a warning. If occasional retries are routine and remain within expected behavior, debug detail and aggregate metrics may be sufficient.

Warnings should retain useful context about the condition and the response. “Fallback used after primary storage timeout” is more informative than “Something went wrong.”

Error Identifies an Operational Failure

Error is appropriate when the export exhausts its allowed attempts and cannot complete.

{
  "level": "error",
  "event": "report.export.failed",
  "job_id": "job_842",
  "attempts": 3,
  "error_code": "storage_timeout",
  "message": "Report export failed after retries"
}

Record the event at a boundary that knows the outcome. A storage helper may know that one call failed; the job runner knows whether the export ultimately failed.

When several layers record the same exception, error counts become misleading. OpenTelemetry’s exception logging conventions address severity according to impact and avoiding duplicate recording.

Separate events can still describe different consequences. A failed upload and a failed recovery action are not necessarily duplicates, provided their meanings are clear.

Exceptions and HTTP Codes Need Context

A caught exception may be part of an expected parsing strategy. A missing optional file may simply cause defaults to be used. Conversely, a dependency returning an apparently ordinary response can still break an important workflow.

HTTP status codes describe protocol outcomes, while application severity describes operational significance.

A 404 for an unknown public page is usually routine. A 404 for a required configuration document during startup may prevent the service from running. An expected authentication rejection is not automatically a server error, though repeated attempts may be relevant to separate security monitoring.

Document examples from your own service so reviewers apply the same reasoning.

A Log Level Is Not an Alert Policy

One error event does not necessarily require paging someone. A sustained increase in failed exports, an unavailable critical workflow, or a missed service objective may.

Google’s SRE monitoring guidance emphasizes actionable signals and the cost of noisy paging. Use severity as evidence alongside frequency, duration, and impact.

Keep logs available for explaining individual failures. Use suitable metrics for measuring their scale, particularly if logs are sampled or can be dropped.

Changing an event from error to warn merely to silence an alert hides the original problem. Correct the event meaning or the alert rule according to which one is wrong.

Trace, Fatal, and Production Thresholds

Some libraries add trace for more detailed diagnostics and fatal or critical for failures affecting continued operation. A fatal-level call does not universally terminate the process; that depends on the library and application.

OpenTelemetry’s severity model provides normalized ranges while preserving source severity text. Check mappings when several logging libraries feed the same backend.

A trace-level log is also distinct from a distributed trace.

A production threshold of info and above can be a reasonable starting point, with debug enabled temporarily for a bounded service or investigation. Set an expiry for that change and account for added volume.

Pair the chosen level with structured fields. Severity narrows the search; operation identifiers and explicit outcomes explain what happened.

Choose a log level that tells the next reader what the event means for the operation.