Log Levels & When to Use Each
debt(d7/e3/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints indicate automated detection is 'no' and the only listed tool is Monolog, which is a logging library, not a static analyzer that flags wrong log levels. Misuse (e.g., logging 401s as ERROR) is invisible to compilers, linters, and most SAST tools — it only becomes apparent during code review or when alert fatigue / missed incidents surface in production.
Closest to 'simple parameterised fix' (e3). The quick_fix provides a direct mapping rule (4xx=INFO, 5xx=ERROR, etc.). Fixing a mis-levelled log call is a targeted find-and-replace across call sites, but it may touch multiple files where the same wrong pattern is repeated — slightly more than a single-line patch but well within one component or a consistent pattern replacement.
Closest to 'persistent productivity tax' (b5). Log levels apply across web, cli, and queue-worker contexts. Getting them wrong persistently degrades observability across all work streams — alert thresholds, on-call runbooks, and dashboards are all shaped by the level choices. It doesn't define the entire system shape, but consistently wrong levelling creates ongoing friction for every engineer touching monitoring or incident response.
Closest to 'notable trap' (t5). The misconception field directly identifies the canonical trap: WARNING and ERROR are treated as interchangeable by many developers. This is a documented, well-known gotcha (PSR-3 defines the distinction, yet common_mistakes confirm developers routinely log 401s as ERROR or use CRITICAL for recoverable errors). It contradicts intuition but is a learnable, documented rule rather than a catastrophic always-wrong pattern.
TL;DR
Explanation
Standard levels (RFC 5424 / PSR-3): EMERGENCY (system unusable), ALERT (immediate action needed), CRITICAL (component failure), ERROR (operation failed, handled), WARNING (unexpected but recovered), NOTICE (normal but significant), INFO (business events, milestones), DEBUG (developer details, queries, input). Production: log INFO and above. Development: log DEBUG and above. Rules: ERROR = operation that failed and was caught (payment declined). WARNING = degraded behaviour (cache miss, rate limited). INFO = key business events (order placed, user registered). DEBUG = everything else. CRITICAL = component down (DB, cache unavailable).
Common Misconception
Why It Matters
Common Mistakes
- Logging expected user errors as ERROR — 401 Unauthorized is INFO, not ERROR.
- Not logging at INFO for key business events — hard to audit.
- DEBUG logs in production — performance and cost impact.
- CRITICAL for recoverable errors — saves CRITICAL for actual outages.
Code Examples
Log::error('User login failed'); // Expected behaviour — should be INFO/WARNING
Log::debug('Processing payment', $data); // In production — noiseLog::info('User login failed', ['user_email' => $email, 'reason' => 'wrong_password']);
Log::error('Payment gateway timeout', ['order_id' => $orderId, 'gateway' => 'stripe']);
Log::critical('Database connection failed', ['host' => $dbHost]);
// In config — production:
// monolog.level: info (suppresses debug)