Log levels and when to use them in Express - Deep Dive

Overview - Log levels and when to use them

What is it?

Log levels are categories that help organize messages your application writes about what it is doing. They range from very detailed information to critical errors. In Express, using log levels helps you decide which messages to record and when, making it easier to understand your app's behavior. This helps developers find problems and monitor performance.

Why it matters

Without log levels, your logs would be a confusing mix of all messages, making it hard to find important issues or understand app behavior. This can slow down fixing bugs and cause downtime. Log levels let you focus on what matters at the right time, improving reliability and saving time.

Where it fits

Before learning log levels, you should understand basic logging and Express app structure. After mastering log levels, you can learn advanced logging tools like Winston or Morgan and how to analyze logs for monitoring and alerting.

Mental Model

Core Idea

Log levels are like filters that let you choose which messages to see based on their importance or detail.

Think of it like...

Imagine a radio with volume and channel controls. Log levels are like channels that separate quiet background chatter from loud emergency alerts, so you only listen to what you need.

┌─────────────┐
│   Log Levels │
├─────────────┤
│ ERROR       │ ← Critical problems
│ WARN        │ ← Warnings to check
│ INFO        │ ← General info
│ DEBUG       │ ← Detailed debug info
│ TRACE       │ ← Very detailed tracing
└─────────────┘

Build-Up - 7 Steps

1

Foundation

What are log levels in Express

Concept: Log levels categorize messages by importance or detail.

In Express, logs can be messages about errors, warnings, or normal operations. Log levels help you label these messages so you can control which ones to save or show. Common levels include ERROR, WARN, INFO, DEBUG, and TRACE.

Result

You understand that logs are not all equal and can be grouped by importance.

Understanding that logs have levels helps you organize messages and avoid being overwhelmed by too much or too little information.

2

Foundation

Basic log levels and their meanings

Concept: Each log level has a specific meaning and use case.

ERROR means something broke and needs fixing. WARN means something unexpected happened but the app can continue. INFO is normal operation messages like server start. DEBUG is detailed info for developers. TRACE is very fine-grained info for deep troubleshooting.

Result

You can identify what kind of message fits each log level.

Knowing the meaning of each level helps you write meaningful logs and filter them effectively.

3

Intermediate

When to use each log level in Express

🤔Before reading on: do you think ERROR logs should be used for all problems or only critical failures? Commit to your answer.

Concept: Choosing the right log level depends on the message's importance and audience.

Use ERROR for crashes or failed requests. WARN for recoverable issues like deprecated API use. INFO for startup, shutdown, or request summaries. DEBUG for detailed request data or variable values. TRACE for step-by-step function calls.

Result

You can decide which log level to assign to different events in your app.

Understanding when to use each level prevents log clutter and helps focus on real issues.

4

Intermediate

Configuring log levels in Express apps

🤔Before reading on: do you think log level settings affect what messages are recorded or just what is displayed? Commit to your answer.

Concept: You can set a minimum log level to control which messages are saved or shown.

In Express, you can use middleware like Morgan or libraries like Winston to set log levels. For example, setting level to WARN means only WARN and ERROR messages are logged, ignoring INFO and DEBUG. This helps reduce noise in production.

Result

You know how to configure your app to log only important messages.

Knowing how to configure log levels lets you balance between too much and too little logging.

5

Intermediate

Using log levels for debugging and monitoring

🤔Before reading on: do you think DEBUG logs should be enabled in production by default? Commit to your answer.

Concept: Different log levels serve different purposes in development and production.

During development, DEBUG and TRACE logs help find bugs by showing detailed info. In production, INFO and WARN are common to monitor app health without slowing it down. ERROR logs alert you to fix critical problems quickly.

Result

You understand how to adjust log levels based on environment and needs.

Recognizing the role of log levels in different stages improves app reliability and developer efficiency.

6

Advanced

Combining multiple log levels and transports

🤔Before reading on: do you think all log messages should go to the same place or can they be sent differently? Commit to your answer.

Concept: Advanced logging sends different levels to different outputs for better management.

Using libraries like Winston, you can send ERROR logs to alert systems, WARN and INFO to files, and DEBUG to console. This separation helps teams respond faster and keeps logs organized.

Result

You can set up complex logging strategies that improve monitoring and debugging.

Knowing how to route logs by level enhances operational awareness and reduces noise.

7

Expert

Performance impact and best practices of log levels

🤔Before reading on: do you think logging at DEBUG level always has negligible performance cost? Commit to your answer.

Concept: Logging too much or at wrong levels can slow down your app and fill storage quickly.

Excessive DEBUG or TRACE logging in production can cause delays and large log files. Best practice is to disable detailed logs in production and use asynchronous logging. Also, avoid expensive operations inside log statements unless needed.

Result

You can optimize logging to keep your app fast and logs useful.

Understanding the performance cost of logging prevents hidden slowdowns and resource waste.

Under the Hood

Log levels work by tagging each message with a priority number internally. When the app runs, it compares the message's level with the configured minimum level. If the message's level is equal or higher priority, it is processed and saved or displayed; otherwise, it is ignored. This filtering happens before writing to files or consoles, saving resources.

Why designed this way?

Log levels were created to manage the flood of messages from complex systems. Early systems logged everything, making it hard to find important info. Levels let developers focus on critical issues or detailed debugging as needed. This design balances information richness with usability and performance.

┌───────────────┐
│ Log Message   │
│ (with level)  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Compare level │
│ to threshold  │
└──────┬────────┘
       │ yes
       ▼
┌───────────────┐
│ Process &     │
│ output log    │
└───────────────┘
       │ no
       ▼
   (Ignore log)

Myth Busters - 4 Common Misconceptions

Quick: do you think DEBUG logs should always be enabled in production? Commit to yes or no.

Common Belief: DEBUG logs are harmless and should always be on to catch all issues.

Reality: DEBUG logs can slow down the app and create huge log files, so they are usually disabled in production.

Why it matters: Leaving DEBUG logs on in production can cause performance problems and make it harder to find real errors.

Quick: do you think WARN logs mean the app is broken? Commit to yes or no.

Common Belief: WARN logs mean the app is broken and needs immediate fixing.

Reality: WARN logs indicate something unexpected but not critical; the app can still work fine.

Why it matters: Misinterpreting WARN as errors can cause unnecessary panic and wasted time.

Quick: do you think all logs should be saved forever? Commit to yes or no.

Common Belief: All logs should be kept indefinitely for safety.

Reality: Storing all logs forever wastes space and makes searching harder; logs should be rotated and archived.

Why it matters: Ignoring log management leads to storage issues and slow troubleshooting.

Quick: do you think log levels are just labels with no real filtering? Commit to yes or no.

Common Belief: Log levels are just tags and do not affect what gets logged.

Reality: Log levels control which messages are actually recorded or shown, filtering out less important ones.

Why it matters: Not understanding filtering leads to confusion about missing logs or too many logs.

Expert Zone

1

Some logging libraries allow custom log levels beyond the standard ones for specialized needs.

2

Log messages can include structured data (like JSON) to make searching and analysis easier.

3

Asynchronous logging improves performance by not blocking the main app flow during log writes.

When NOT to use

Avoid using verbose log levels like DEBUG or TRACE in high-traffic production environments; instead, use INFO or WARN. For critical systems, consider centralized logging and alerting tools rather than simple console logs.

Production Patterns

In production, teams often log ERROR and WARN to alert systems, INFO to files for audits, and enable DEBUG only temporarily during incidents. Logs are rotated daily and stored in centralized systems like ELK or Splunk for analysis.

Connections

Event-driven architecture

Log levels help filter events by importance, similar to how event systems prioritize messages.

Understanding log levels aids in designing event systems that handle critical and non-critical events differently.

Human attention management

Log levels manage the flow of information like how humans prioritize urgent vs. routine tasks.

Knowing how log levels work helps design systems that respect human limits on processing information.

Library classification in a library system

Just as books are categorized by topic and importance, logs are categorized by level to organize information.

Recognizing categorization patterns across domains improves how you organize and retrieve information efficiently.

Common Pitfalls

#1 Logging everything at DEBUG level in production.

Wrong approach:

logger.debug('User data:', userData); // DEBUG level always on

Correct approach:

if (logger.isLevelEnabled('debug')) { logger.debug('User data:', userData); } // DEBUG enabled only in dev

Root cause:

Not realizing that DEBUG logs can slow down production and fill storage.

#2 Using ERROR level for minor warnings.

Wrong approach:

logger.error('Deprecated API used'); // Should be WARN

Correct approach:

logger.warn('Deprecated API used');

Root cause:

Confusing severity levels leads to misleading log importance.

#3 Not setting a minimum log level, causing log overload.

Wrong approach:

app.use(morgan('combined')); // logs everything without filtering

Correct approach:

app.use(morgan('combined', { skip: (req, res) => res.statusCode < 400 })); // logs only warnings and errors

Root cause:

Ignoring log level filtering causes excessive log volume.

Key Takeaways

Log levels organize messages by importance, helping you focus on what matters.

Choosing the right log level for each message prevents clutter and aids troubleshooting.

Configuring log levels lets you control what logs are recorded or shown in different environments.

Excessive logging at detailed levels can harm performance and should be avoided in production.

Advanced logging setups route different levels to different outputs for better monitoring and alerting.