The Severity Hierarchy
Every logging framework uses a severity hierarchy to classify events. Understanding what belongs at each level is critical — misuse leads to either alert fatigue (too much noise at ERROR) or blind spots (real errors buried in DEBUG).
| Level | When to Use | Example |
|---|---|---|
DEBUG |
Detailed internal state, only useful during active development. Never enabled in production by default. | "Entering function calculateTax with args: {amount: 150, region: 'CA'}" |
INFO |
Normal, expected business events. The happy path. | "Order #8821 placed successfully by user bob" |
WARN |
Something unexpected happened, but the system recovered or degraded gracefully. Requires investigation but not immediate action. | "Payment gateway primary timed out, retrying with fallback" |
ERROR |
A specific operation failed. The system is still running, but this request/job/transaction failed. Requires investigation. | "Failed to process payment for order #8821: gateway returned 503" |
FATAL / CRITICAL |
The application cannot continue. Imminent crash or data corruption risk. | "Cannot connect to database after 10 retries, shutting down" |
The Common Mistakes
Over-logging at ERROR: If you log every 404 response as an ERROR, your error dashboards become meaningless. A 404 is expected user behavior — it belongs at INFO or WARN at most. Reserve ERROR for things that require a human to investigate.
Under-logging at INFO: The INFO level should tell the story of your application's business logic. If you can't reconstruct what a user did from INFO logs alone, you're not logging enough at that level.
Logging sensitive data: Never log passwords, API keys, credit card numbers, or PII (Personally Identifiable Information) at any level. Logs are often stored in systems with broader access than your production database, and they're frequently shipped to third-party services. Scrub sensitive fields before logging, or use a structured logging library that supports field-level redaction.