We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Observability Monitoring
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Observability Monitoring
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A few months ago, a team at a fintech startup got paged at 3 AM. The monitoring system screamed that something was critically wrong. The on-call engineer stumbled out of bed, opened the laptop, checked the logs, and found... A deprecation warning. A library they used had printed a warning about a function that would be removed in three years. Not a crash. Not data loss. A polite heads-up from an open-source maintainer.
The problem? Every log message in their system was treated the same. Warnings, errors, debug traces, informational notes, all dumped into one stream with no priority. Their alerting system couldn't tell the difference between "the database is on fire" and "this function will be renamed eventually."
Log levels exist to solve exactly this. They're a severity hierarchy, a way to tag every log message with how much you should care about it. Get them right, and your team sleeps through the night unless something genuinely matters. Get them wrong, and you either drown in noise or miss the one message that could have saved you.
Most logging frameworks use the same six levels, ordered from least severe to most severe:
| Level | When to Use | Example |
|---|---|---|
| TRACE | Ultra-detailed debugging. Every function entry, every variable state. | TRACE: Entering calculateTax() with amount=49.99, region=US-CA |
| DEBUG | Useful during development. Details about internal state. | DEBUG: Cache miss for user_123, fetching from database |
| INFO | Normal operations. Things that should happen. | INFO: User alice@example.com logged in successfully |
| WARN | Something unexpected but not broken. The system handled it. | WARN: API response took 4.2s (threshold: 3s), retrying |
| ERROR | Something failed. A specific operation couldn't complete. | ERROR: Payment processing failed for order #8834, gateway timeout |
| FATAL | The entire application is going down. Unrecoverable. | FATAL: Database connection pool exhausted, shutting down |
The key insight: log levels are a filter, not just a label. When you set your application's log level to WARN, you're saying "show me WARN, ERROR, and FATAL only." Everything below that threshold gets silently dropped.
In production, most teams run at INFO or WARN. In staging, DEBUG. In local development, whatever helps you understand what's happening, usually DEBUG or TRACE.