Log Levels Explained: DEBUG, INFO, WARN, ERROR — When to Use Each

The Log Level Decision That Haunts You at 3 AM

You're debugging a production issue at 3 AM. You search the logs for clues. And you find... 47 million DEBUG messages about database connection pool stats, HTTP header values, and cache hit ratios.

The actual error? Buried somewhere in the noise.

Log levels exist to prevent this. Used correctly, they let you filter signal from noise instantly.

The Six Standard Levels

From least to most severe:

TRACE

The most verbose level. Method entry/exit, variable values, loop iterations.

When to use: Never in production. Only during local development for step-through debugging.

Example: TRACE: Entering processOrder() with orderId=abc123

DEBUG

Detailed diagnostic information useful during development.

When to use: Development and staging. Sometimes enabled temporarily in production for a specific module to investigate an issue.

Example: DEBUG: Cache miss for key user:456, fetching from database

INFO

General operational events that confirm the system is working.

When to use: Production. Log significant events like startup, shutdown, successful operations, and configuration changes.

Example: INFO: Server started on port 8080 or INFO: Order abc123 processed successfully

WARN

Unexpected but recoverable situations.

When to use: Something is off but the application continues. The issue should be investigated but isn't urgent.

Example: WARN: API response took 4.2s (threshold: 3s) or WARN: Using deprecated endpoint /v1/users

ERROR

Something failed. A request couldn't be processed, an operation didn't complete.

When to use: The specific operation failed, but the application is still running.

Example: ERROR: Failed to charge card for order abc123: CardDeclinedError

FATAL / CRITICAL

The application cannot continue. Unrecoverable state.

When to use: The process is about to exit. Database connection permanently lost, required config missing, out of memory.

Example: FATAL: Cannot connect to database after 10 retries, shutting down

The Golden Rules

1. Production should run at INFO or WARN — DEBUG is too noisy
2. ERROR means someone should be notified — if nobody needs to act, it's a WARN
3. INFO should be readable by a human — if your INFO logs are wall-of-text, they're DEBUG
4. Each log line should be actionable — if you can't act on it, why log it?

Framework Mappings

Different frameworks use different names. See our [interactive log levels reference](/tools/log-levels) for a side-by-side comparison across Python, Java (Log4j/SLF4J), Node.js (Pino/Winston), Go (slog/zap), and syslog.

From Logging to Error Tracking

Logs are the foundation, but they're passive — you have to go looking. Error tracking is active — it finds the errors and brings them to you.

Bugsly captures ERROR and FATAL events automatically, enriches them with stack traces and context, and uses AI to explain what went wrong. Think of it as log analysis on autopilot. [Try it free](/signup).