---
title: Do Not Use Error Log For Non-critical
impact: HIGH
impactDescription: prevents alert fatigue and ensures meaningful monitoring
tags: logging, log-levels, error, observability, quality, kotlin
---

## Do Not Use Error Log For Non-critical

Incorrect log levels cause alert fatigue and hide real issues. When non-critical business events are logged as "ERROR", it becomes difficult for SRE/Developers to identify actual system failures.

**Incorrect (overusing error level):**

```kotlin
// NOT an error - expected business case
logger.error("User entered wrong password")

// NOT an error - validation failure
logger.error("Email format invalid")

// NOT an error - expected retry
logger.error("Retry attempt 2 of 5")
```

**Correct (appropriate log levels):**

```kotlin
// WARN - recoverable, may need attention if repetitive
logger.warn("Payment retry attempt: {}, max: {}", current, max)

// INFO - normal business events
logger.info("Login failed - invalid password for user: {}", userId)

// DEBUG - detailed troubleshooting information
logger.debug("Validation failed for field: {}, value: {}", field, value)

// ERROR - only for actual system failures or unhandled exceptions
logger.error("Database connection lost to host: {}", dbHost, exception)
```

**Log Level Guide:**

| Level | Use For |
|-------|---------|
| ERROR | System failures, unhandled exceptions, data loss, dependency down |
| WARN | Recoverable errors, degraded performance, deprecated API usage |
| INFO | Key business milestones, startup/shutdown, audit-level events |
| DEBUG | Detailed technical data for developers during troubleshooting |

**Tools:** Static analyzer, PR review, Log Monitoring (Sentry/Datadog) alerts configuration