Logging in LLD - Learning Module

Loading content...

0/246

Logging Levels and When to Use Them

The Signal vs. Noise Problem

You're investigating a production incident. The system is serving errors to customers, and every minute of downtime costs money. You open the log aggregator, search for the problematic service, and... you're drowning in noise.

Millions of log entries pour through. Most are routine health checks. Thousands track normal request processing. Buried somewhere in this deluge is the one error that explains everything—but finding it is like searching for a specific grain of sand on a beach.

Now imagine the opposite extreme: you open the logs and find... almost nothing. The service was configured to log only critical errors, and whatever went wrong wasn't classified as critical. You have no visibility into what led up to the failure, no breadcrumbs to follow.

Both scenarios represent logging failures. The solution is logging levels—a hierarchy that categorizes log messages by severity, enabling you to tune the verbosity based on context and filter effectively during investigations.

What You Will Learn

By the end of this page, you will understand the standard logging levels, know exactly when to use each one, appreciate how levels work together in a coherent strategy, and avoid common mistakes that undermine logging effectiveness.

What Are Logging Levels?

Logging levels are a severity-based classification system for log messages. Each log statement is assigned a level that indicates its importance, urgency, and intended audience. This classification serves multiple purposes:

Filtering: Configure your logging system to capture only messages at or above a certain threshold
Alerting: Trigger notifications for high-severity logs while ignoring routine ones
Visualization: Display logs by severity in dashboards and investigation tools
Storage: Apply different retention policies based on severity
Communication: Immediately convey the urgency of a log entry to the reader

Most logging frameworks implement a similar hierarchy, though exact names and numbers may vary. The core concept is universal: higher severity levels indicate more urgent situations that demand attention.

Converting Mermaid diagram...

The Threshold Concept:

When you configure a logging level (e.g., "INFO"), you capture all messages at that level and above. If your production logging is set to INFO, you'll see INFO, WARN, ERROR, and FATAL messages—but not DEBUG or TRACE.

This threshold mechanism is what makes logging levels powerful. You can inject detailed DEBUG logging during development without worrying about it cluttering production logs—as long as production is configured at a higher level.

However, this only works if you assign levels correctly. Misuse of levels—logging errors as INFO, or debugging information as WARN—undermines the entire system.

TRACE and DEBUG: For Deep Investigation

TRACE and DEBUG are the most verbose levels, used for detailed diagnostic information that's typically too noisy for production but invaluable during development and troubleshooting.

TRACE Level

•Purpose: Fine-grained diagnostic information, often including step-by-step execution traces
•Volume: Extremely high—can generate megabytes per minute
•Audience: Developers during intensive debugging sessions
•Examples: Method entry/exit, loop iterations, intermediate calculation values, raw request/response bodies
•Production: Almost never enabled; may impact performance

DEBUG Level

•Purpose: Information useful for diagnosing issues and understanding system behavior
•Volume: High—significantly more than INFO
•Audience: Developers and senior operators investigating specific issues
•Examples: Variable values, decision points, cache hit/miss, connection pool states
•Production: Sometimes enabled temporarily for specific components during incidents

TraceDebugExamples.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public class PaymentProcessor {
    private static final Logger logger = LoggerFactory.getLogger(PaymentProcessor.class);
    
    public PaymentResult processPayment(PaymentRequest request) {
        // TRACE: Extremely detailed, step-by-step execution
        logger.trace("ENTERING processPayment: request={}", request);
        
        // DEBUG: Useful diagnostic information
        logger.debug("Processing payment: amount={}, currency={}, merchantId={}", 
            request.getAmount(), request.getCurrency(), request.getMerchantId());
        
        // Validate request
        ValidationResult validation = validator.validate(request);
        logger.debug("Validation result: valid={}, errors={}", 
            validation.isValid(), validation.getErrors());
        
        if (!validation.isValid()) {
            logger.debug("Payment rejected due to validation: errors={}", validation.getErrors());
            return PaymentResult.invalid(validation.getErrors());
        }
        
        // Select payment gateway
        PaymentGateway gateway = gatewaySelector.select(request);
        logger.debug("Selected gateway: name={}, priority={}", 
            gateway.getName(), gateway.getPriority());
        
        // Process through gateway
        logger.trace("Calling gateway.process with cardToken={} (masked)", 
            maskToken(request.getCardToken()));
        
        GatewayResponse response = gateway.process(request);
        
        logger.trace("Gateway response received: rawResponse={}", response.getRawResponse());
        logger.debug("Gateway response: status={}, transactionId={}, responseTimeMs={}", 
            response.getStatus(), response.getTransactionId(), response.getResponseTimeMs());
        
        // TRACE: Method exit
        logger.trace("EXITING processPayment: result={}", response.getStatus());
        
        return PaymentResult.from(response);
    }
}

Performance Considerations

TRACE and DEBUG logs can significantly impact performance, even when disabled. Many logging frameworks still evaluate log arguments before checking the level. Use lazy evaluation or level guards: if (logger.isDebugEnabled()) { logger.debug(...); } for expensive operations.

INFO: The Heartbeat of Your System

INFO is the default production logging level in most systems. It captures significant events in the normal operation of your application—the "heartbeat" that tells you the system is alive and functioning correctly.

INFO logs should answer: "What is the system doing right now?" without drowning you in detail.

What to Log at INFO Level

•Service lifecycle events — Startup, shutdown, configuration loaded, dependencies connected
•Significant business operations — Order placed, payment processed, user registered, report generated
•External integration events — API calls made, messages sent/received, files uploaded
•Batch job progress — Job started, progress milestones, job completed
•Configuration changes — Feature flags toggled, settings updated, deployments detected
•Periodic summaries — Aggregated statistics, health status, throughput metrics

InfoLevelExamples.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
public class ApplicationLifecycle {
    private static final Logger logger = LoggerFactory.getLogger(ApplicationLifecycle.class);
    
    public void startup() {
        // Service lifecycle: startup
        logger.info("SERVICE_STARTING: version={}, environment={}, instance={}",
            config.getVersion(), config.getEnvironment(), config.getInstanceId());
        
        // Configuration loaded
        logger.info("CONFIG_LOADED: databaseHost={}, cacheEnabled={}, maxConnections={}",
            config.getDatabaseHost(), config.isCacheEnabled(), config.getMaxConnections());
        
        // Dependencies connected
        connectDatabase();
        logger.info("DATABASE_CONNECTED: host={}, connectionPoolSize={}",
            config.getDatabaseHost(), connectionPool.getSize());
        
        connectCache();
        logger.info("CACHE_CONNECTED: host={}, cluster={}",
            config.getCacheHost(), config.getCacheCluster());
        
        // Ready to serve
        logger.info("SERVICE_STARTED: readyToServeTraffic=true, startupTimeMs={}",
            System.currentTimeMillis() - startTime);
    }
}
 
public class OrderService {
    private static final Logger logger = LoggerFactory.getLogger(OrderService.class);
    
    public Order createOrder(CreateOrderRequest request) {
        // Business operation: order created
        Order order = orderRepository.save(buildOrder(request));
        
        logger.info("ORDER_CREATED: orderId={}, userId={}, itemCount={}, totalAmount={}, currency={}",
            order.getId(), order.getUserId(), order.getItems().size(), 
            order.getTotalAmount(), order.getCurrency());
        
        return order;
    }
    
    public void shipOrder(String orderId) {
        Order order = orderRepository.findById(orderId);
        order.setStatus(OrderStatus.SHIPPED);
        orderRepository.save(order);
        
        logger.info("ORDER_SHIPPED: orderId={}, userId={}, shippingProvider={}, trackingNumber={}",
            order.getId(), order.getUserId(), 
            order.getShippingProvider(), order.getTrackingNumber());
    }
}
 
public class BatchProcessor {
    private static final Logger logger = LoggerFactory.getLogger(BatchProcessor.class);
    
    public void processInvoiceBatch(List<Invoice> invoices) {
        // Batch job: start
        logger.info("BATCH_STARTED: jobType=INVOICE_PROCESSING, totalItems={}, batchId={}",
            invoices.size(), batchId);
        
        int processed = 0;
        int failed = 0;
        
        for (Invoice invoice : invoices) {
            try {
                processInvoice(invoice);
                processed++;
                
                // Progress milestone (every 100 items)
                if (processed % 100 == 0) {
                    logger.info("BATCH_PROGRESS: batchId={}, processed={}, failed={}, remaining={}",
                        batchId, processed, failed, invoices.size() - processed - failed);
                }
            } catch (Exception e) {
                failed++;
                // Error would be logged at ERROR level
            }
        }
        
        // Batch job: complete
        logger.info("BATCH_COMPLETED: batchId={}, processed={}, failed={}, durationMs={}",
            batchId, processed, failed, System.currentTimeMillis() - startTime);
    }
}

The INFO Level Sweet Spot:

INFO logs should be:

Frequent enough to provide visibility into system behavior
Sparse enough to be readable without aggressive filtering
Informative enough to tell a story of what the system is doing
Concise enough to not overwhelm log storage

A useful rule of thumb: You should be able to read the INFO logs of a small service and understand what happened over the last hour in a few minutes.

The Read Aloud Test

Read your INFO logs aloud as if narrating the system's activities: 'The service started... connected to the database... processed an order... shipped the order...' If this sounds like a coherent story, your INFO logging is well-designed.

WARN: Early Warning Signs

WARN (or WARNING) indicates situations that are unusual or potentially problematic, but not yet failures. The system can continue operating, but something deserves attention—either now or soon.

WARN logs are your early warning system. They flag conditions that, if left unaddressed, may escalate to errors.

What to Log at WARN Level

•Resource exhaustion approaching — Connection pool at 80% capacity, disk space running low, memory usage high
•Degraded performance — Response times exceeding thresholds, timeouts requiring retries
•Fallback behavior activated — Using cached data because primary source unavailable, failover to backup service
•Unexpected but handled situations — Received malformed data that was successfully corrected, deprecated API used
•Approaching limits — Rate limiter nearing capacity, quota consumption at 90%
•Recoverable failures — Retry succeeded after initial failure, circuit breaker opened
•Configuration concerns — Default values used because configuration missing, deprecated settings detected

WarnLevelExamples.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
public class ResourceMonitor {
    private static final Logger logger = LoggerFactory.getLogger(ResourceMonitor.class);
    
    public void checkConnectionPool() {
        int used = connectionPool.getActiveConnections();
        int max = connectionPool.getMaxConnections();
        double utilizationPercent = (used * 100.0) / max;
        
        if (utilizationPercent >= 80) {
            // Resource exhaustion approaching
            logger.warn("CONNECTION_POOL_HIGH_UTILIZATION: used={}, max={}, utilization={}%",
                used, max, utilizationPercent);
        }
    }
}
 
public class ExternalApiClient {
    private static final Logger logger = LoggerFactory.getLogger(ExternalApiClient.class);
    
    public Response callWithRetry(Request request) {
        int attempts = 0;
        Exception lastException = null;
        
        while (attempts < maxRetries) {
            try {
                Response response = httpClient.execute(request);
                
                if (attempts > 0) {
                    // Retry succeeded - warn that initial attempts failed
                    logger.warn("API_CALL_RETRY_SUCCEEDED: endpoint={}, attempts={}, finalStatus={}",
                        request.getEndpoint(), attempts + 1, response.getStatus());
                }
                
                return response;
                
            } catch (TimeoutException e) {
                attempts++;
                lastException = e;
                
                logger.warn("API_CALL_TIMEOUT: endpoint={}, attempt={}, maxRetries={}, timeoutMs={}",
                    request.getEndpoint(), attempts, maxRetries, timeoutMs);
            }
        }
        
        throw new ApiCallFailedException("All retries exhausted", lastException);
    }
}
 
public class CacheService {
    private static final Logger logger = LoggerFactory.getLogger(CacheService.class);
    
    public Data getWithFallback(String key) {
        try {
            Data cached = cache.get(key);
            if (cached != null) {
                return cached;
            }
        } catch (CacheException e) {
            // Cache unavailable - fallback to database
            logger.warn("CACHE_FALLBACK_TO_DATABASE: key={}, cacheError={}, fallbackReason=CACHE_UNAVAILABLE",
                key, e.getMessage());
        }
        
        // Fallback to database
        return database.get(key);
    }
}
 
public class RateLimiter {
    private static final Logger logger = LoggerFactory.getLogger(RateLimiter.class);
    
    public boolean tryAcquire(String clientId) {
        TokenBucket bucket = buckets.get(clientId);
        double utilizationPercent = (1 - (bucket.getAvailableTokens() / bucket.getMaxTokens())) * 100;
        
        if (utilizationPercent >= 90) {
            // Approaching rate limit
            logger.warn("RATE_LIMIT_NEAR_EXHAUSTION: clientId={}, utilization={}%, tokensRemaining={}",
                clientId, utilizationPercent, bucket.getAvailableTokens());
        }
        
        return bucket.tryAcquire();
    }
}

WARN vs ERROR

The key distinction: WARN means 'something unusual happened, but we handled it.' ERROR means 'something failed, and we couldn't fully handle it.' If the operation ultimately succeeded (even with degradation or retries), it's WARN. If it failed, it's ERROR.

Actionable Warnings:

The best WARN logs imply an action:

High connection pool usage → Consider scaling or increasing pool size
Frequent retries → Investigate upstream service health
Cache fallbacks → Check cache infrastructure
Approaching quotas → Alert business/operations teams

If a WARN log doesn't imply any possible action, consider whether it belongs at DEBUG level instead.

ERROR: Something Failed

ERROR indicates that something has failed. An operation could not be completed, an exception was caught that prevents normal processing, or the system is unable to fulfill a request.

ERROR logs are the primary signal for incident detection and response. They should be:

Rare enough to warrant attention
Informative enough to enable diagnosis
Actionable enough to guide remediation

What to Log at ERROR Level

•Operation failures — Database insert failed, API call returned error, file operation failed
•Unexpected exceptions — NullPointerException, connection refused, timeout after all retries
•Business rule violations — Invariants violated, data inconsistencies detected
•Integration failures — External service unavailable, message queue producer failed
•Security events — Authentication failures, authorization denied for sensitive operations
•Data errors — Corrupt data encountered, required field missing, constraint violations

ErrorLevelExamples.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
public class OrderService {
    private static final Logger logger = LoggerFactory.getLogger(OrderService.class);
    
    public OrderResult processOrder(Order order) {
        try {
            // Attempt to process
            PaymentResult payment = paymentService.charge(order);
            
            if (!payment.isSuccess()) {
                // Business operation failed - but this is expected in normal operation
                // Consider if this should be WARN instead if declines are common
                logger.error("PAYMENT_DECLINED: orderId={}, userId={}, amount={}, " +
                    "declineReason={}, declineCode={}",
                    order.getId(), order.getUserId(), order.getAmount(),
                    payment.getDeclineReason(), payment.getDeclineCode());
                    
                return OrderResult.paymentDeclined(payment.getDeclineReason());
            }
            
            return OrderResult.success(order.getId());
            
        } catch (PaymentServiceException e) {
            // Payment service failed unexpectedly
            logger.error("PAYMENT_SERVICE_ERROR: orderId={}, userId={}, amount={}, " +
                "error={}, errorType={}, serviceHost={}",
                order.getId(), order.getUserId(), order.getAmount(),
                e.getMessage(), e.getClass().getSimpleName(), paymentService.getHost(), e);
                
            return OrderResult.serviceError("Payment service unavailable");
            
        } catch (DatabaseException e) {
            // Database operation failed
            logger.error("DATABASE_ERROR: operation=SAVE_ORDER, orderId={}, " +
                "error={}, sqlState={}",
                order.getId(), e.getMessage(), e.getSqlState(), e);
                
            throw new OrderProcessingException("Failed to save order", e);
        }
    }
}
 
public class DataIntegrityValidator {
    private static final Logger logger = LoggerFactory.getLogger(DataIntegrityValidator.class);
    
    public void validateUserAccount(User user) {
        // Check invariants
        if (user.getBalance() < 0) {
            // This should never happen - indicates bug or data corruption
            logger.error("DATA_INTEGRITY_VIOLATION: userId={}, issue=NEGATIVE_BALANCE, " +
                "balance={}, lastTransaction={}",
                user.getId(), user.getBalance(), user.getLastTransactionId());
                
            throw new DataIntegrityException("User balance cannot be negative");
        }
        
        if (user.getCreatedAt().isAfter(user.getLastLoginAt())) {
            logger.error("DATA_INTEGRITY_VIOLATION: userId={}, issue=INVALID_TIMESTAMPS, " +
                "createdAt={}, lastLoginAt={}",
                user.getId(), user.getCreatedAt(), user.getLastLoginAt());
                
            // Don't throw - this might be clock skew, just flag for investigation
        }
    }
}
 
public class MessageProcessor {
    private static final Logger logger = LoggerFactory.getLogger(MessageProcessor.class);
    
    public void processMessage(Message message) {
        try {
            handler.handle(message);
            
        } catch (InvalidMessageException e) {
            // Message format error - data issue
            logger.error("MESSAGE_INVALID: messageId={}, queue={}, error={}, " +
                "messagePreview={}",
                message.getId(), message.getQueue(), e.getMessage(),
                truncate(message.getBody(), 200), e);
                
            // Send to dead-letter queue
            deadLetterQueue.send(message);
            
        } catch (ProcessingException e) {
            // Processing logic failed
            logger.error("MESSAGE_PROCESSING_FAILED: messageId={}, queue={}, " +
                "error={}, retryable={}, attemptNumber={}",
                message.getId(), message.getQueue(), e.getMessage(),
                e.isRetryable(), message.getAttemptNumber(), e);
                
            if (e.isRetryable() && message.getAttemptNumber() < maxRetries) {
                requeue(message);
            } else {
                deadLetterQueue.send(message);
            }
        }
    }
}

Include Context and Stack Traces

ERROR logs without sufficient context are frustrating to debug. Always include: 1) What operation was attempted, 2) What input/identifiers were involved, 3) What error occurred, 4) The full stack trace for unexpected exceptions. A cryptic 'Error occurred' message is nearly useless.

Error Log Best Practices:

Include the exception: Always pass the exception object to the logger (most frameworks handle stack trace extraction)
Add identifiers: Request ID, user ID, transaction ID—anything that helps correlate
Describe the context: What were you trying to do when this happened?
Classify the error: Is it a user error, system error, data error, external dependency failure?
Consider alerting: ERROR logs often trigger alerts. Make sure they contain enough information to decide on remediation without additional investigation.

FATAL/CRITICAL: Catastrophic Failures

FATAL (or CRITICAL) indicates the most severe failures—situations where the application cannot continue operating or has suffered an unrecoverable error. These logs should be extremely rare and always trigger immediate alerts.

In many applications, you may never log at FATAL level. It's reserved for catastrophic situations that prevent the system from functioning at all.

What to Log at FATAL Level

•Application startup failure — Cannot connect to required database, missing critical configuration, license invalid
•Unrecoverable state corruption — Critical data structures corrupted, cannot continue safely
•Infrastructure breakdown — Cannot allocate memory, disk completely full, network stack failed
•Security compromise detected — Evidence of active attack, integrity checks failed
•Graceful shutdown impossible — Cannot complete required cleanup, data may be lost

FatalLevelExamples.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
public class ApplicationBootstrap {
    private static final Logger logger = LoggerFactory.getLogger(ApplicationBootstrap.class);
    
    public void initialize() {
        try {
            // Load required configuration
            Config config = loadConfiguration();
            
            // Connect to required database
            connectDatabase(config);
            
        } catch (ConfigurationException e) {
            // Cannot start without valid configuration
            logger.error("FATAL: CONFIGURATION_LOAD_FAILED - Application cannot start. " +
                "error={}, configPath={}",
                e.getMessage(), configPath, e);
            System.exit(1);
            
        } catch (DatabaseConnectionException e) {
            // Cannot start without database
            logger.error("FATAL: DATABASE_CONNECTION_FAILED - Application cannot start. " +
                "host={}, port={}, error={}, retriesAttempted={}",
                config.getDbHost(), config.getDbPort(), e.getMessage(), maxRetries, e);
            System.exit(1);
        }
    }
}
 
public class DataIntegrityChecker {
    private static final Logger logger = LoggerFactory.getLogger(DataIntegrityChecker.class);
    
    public void verifyStartupIntegrity() {
        // Check critical data structures
        if (!ledger.isBalanced()) {
            // Financial ledger out of balance - catastrophic data corruption
            logger.error("FATAL: LEDGER_INTEGRITY_VIOLATION - Financial ledger is not balanced. " +
                "expectedSum={}, actualSum={}, discrepancy={}. " +
                "Application halted to prevent further damage.",
                ledger.getExpectedSum(), ledger.getActualSum(), 
                ledger.getExpectedSum() - ledger.getActualSum());
            
            // Trigger emergency alert
            emergencyAlert.send("CRITICAL: Ledger integrity failure - immediate investigation required");
            
            System.exit(1);
        }
    }
}
 
public class SecurityMonitor {
    private static final Logger logger = LoggerFactory.getLogger(SecurityMonitor.class);
    
    public void onIntegrityCheckFailed(IntegrityViolation violation) {
        // Evidence of tampering or attack
        logger.error("FATAL: SECURITY_INTEGRITY_VIOLATION - Possible security breach detected. " +
            "type={}, resource={}, expectedHash={}, actualHash={}, " +
            "Initiating security lockdown.",
            violation.getType(), violation.getResource(),
            violation.getExpectedHash(), violation.getActualHash());
        
        // Initiate security response
        securityResponse.initiateLockedown(violation);
        
        // In some cases, we might not exit but enter a restricted mode
    }
}

FATAL Logs Demand Immediate Response

Every FATAL log should trigger an immediate page to on-call engineers. These events indicate the system has failed in a way that requires human intervention. If you're logging FATAL regularly, either the system has serious problems or you're misusing the level.

Level Selection Decision Framework

Choosing the correct logging level requires judgment. Here's a decision framework to help you select appropriately:

Logging Level Decision Matrix
If the situation is...	Level	Example
Fine-grained execution details for deep debugging	TRACE	Entering/exiting methods, loop iterations
Information useful for diagnosing specific issues	DEBUG	Variable values, cache hit/miss, query parameters
Normal, significant business or operational events	INFO	Request processed, order shipped, batch completed
Unusual situation handled, but worth monitoring	WARN	Retry succeeded, fallback used, resource near limit
Operation failed, but system continues	ERROR	Payment declined, database timeout, API error
System cannot continue, human intervention required	FATAL	Startup failed, critical data corruption

Key Questions to Ask

•Will this be needed every time we investigate any issue? → INFO or lower
•Does this indicate a current or imminent problem? → WARN or ERROR
•Did the operation fail? → ERROR; Did it succeed with issues? → WARN
•Would I want to be paged about this at 3 AM? → ERROR or FATAL; No? → Lower level
•Is this only useful during development or specific debugging sessions? → DEBUG or TRACE
•Could this create alert fatigue if it happens frequently? → Consider lower level

The Volume Test

Imagine your system handling peak traffic. Will this log statement generate thousands of messages per second? If so, it probably shouldn't be INFO or higher. If errors occur at high volume, aggregate them rather than logging each individually.

Common Logging Level Mistakes

Even experienced engineers make mistakes with logging levels. Here are the most common anti-patterns and how to avoid them:

Logging Level Anti-Patterns

•Logging expected outcomes as ERROR — User entering wrong password is not an error in your system. It's expected behavior. Use DEBUG or INFO for expected validation failures; reserve ERROR for unexpected failures.
•Using INFO for debugging information — 'Before calling service X', 'After processing, value is Y'. This clutters production logs. Use DEBUG for execution flow details.
•Logging all exceptions as ERROR — Not all exceptions are errors. A 'RecordNotFoundException' when checking if a username exists is normal. Consider the business context.
•WARN for everything 'might' be a problem — If you're not sure it's a problem, it's probably DEBUG. Reserve WARN for actual early warning signs.
•Inconsistent levels across codebase — Same type of event logged as INFO in one service, DEBUG in another. Establish and follow team conventions.
•Logging at ERROR then re-throwing — This often results in the same error being logged multiple times at different stack levels. Log at the handling point, not every catch block.

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// ❌ BAD: Expected behavior logged as ERROR
public boolean login(String username, String password) {
    User user = userRepo.findByUsername(username);
    if (user == null) {
        // This is expected - users mistype usernames
        logger.error("User not found: {}", username);
        return false;
    }
    
    if (!passwordEncoder.matches(password, user.getPasswordHash())) {
        // This is expected - users mistype passwords
        logger.error("Invalid password for user: {}", username);
        return false;
    }
    
    return true;
}

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ✅ GOOD: Expected behavior at appropriate level
public boolean login(String username, String password) {
    User user = userRepo.findByUsername(username);
    if (user == null) {
        // Expected - DEBUG level, or INFO if needed for security monitoring
        logger.info("LOGIN_FAILED: reason=USER_NOT_FOUND, username={}", 
            maskUsername(username));
        return false;
    }
    
    if (!passwordEncoder.matches(password, user.getPasswordHash())) {
        // Could be security concern at volume - WARN if repeated
        logger.info("LOGIN_FAILED: reason=INVALID_PASSWORD, userId={}", 
            user.getId());
        return false;
    }
    
    return true;
}

Summary: Logging Levels Mastery

Let's consolidate the key insights about logging levels:

Key Takeaways

•TRACE/DEBUG are for development and specific debugging sessions—verbose, detailed, rarely enabled in production
•INFO is the production baseline—significant events that tell the story of what the system is doing
•WARN signals potential problems—handled but unusual situations that deserve monitoring
•ERROR indicates failures—operations that could not complete, requiring attention but not immediate action
•FATAL indicates catastrophic failures—the system cannot function, immediate human intervention required
•Consistent usage across teams and services is essential—establish conventions and enforce them
•Consider the reader in a crisis—will this log help or hinder incident response?

What's Next:

Knowing the levels is only half the story. The next page covers what to log—the specific information and context that makes logs useful for investigation, monitoring, and auditing.

Page Complete

You now understand the logging level hierarchy and when to use each level. Consistent, appropriate level usage is a hallmark of professional-grade logging. Next, we'll explore what specific information to capture in your logs.