Log levels are severity labels attached to each log entry, controlling what gets recorded, what gets displayed, and what triggers alerts. The mainstream standard defines five levels โ DEBUG, INFO, WARN, ERROR, FATAL โ in increasing order of severity. The core value of the level system: keep noise to a minimum in normal operation, yet filter and alert quickly by level when something goes wrong.
Quick Reference: The Five Standard Levels
| Level |
Meaning |
Typical content |
Production |
Triggers alert |
| DEBUG |
Debugging detail |
Variable values, SQL statements, function arguments |
Off |
No |
| INFO |
Normal business milestones |
User login, order created, task started |
On |
No |
| WARN |
Abnormal but self-recovering |
Retry succeeded, fallback triggered, slow request |
On |
Aggregate and review manually |
| ERROR |
Operation failed, affects current action |
API 5xx, payment failed, null pointer |
On |
Yes |
| FATAL |
System-level outage |
Database unreachable, service won't start |
On |
Yes (P0 response) |
How to Decide Which Level to Use
In practice, misusing levels is more common than missing logs. Here are workable criteria:
DEBUG: for the developer's own eyes
- Criterion: this information is worthless while the system runs normally, and useful only when investigating a specific bug;
- Typical content: function arguments and return values, intermediate computation results, cache hit rates;
- Key principle: off by default in production. Not deleted โ filtered, so you can temporarily turn it on when trouble hits.
INFO: for people asking "what is the system doing"
- Criterion: reading this log half a year later lets you reconstruct the user's journey;
- Typical content: key business actions (signup, purchase, publish), task start/end and durations;
- Anti-pattern: logging every HTTP 200 as INFO โ that's the access log's job; don't pollute business logs with it.
WARN: something went wrong, but the system coped
- Criterion: someone should know, but nobody needs to get up at 3 a.m.;
- Typical content: success after a retry, rate limiting/degradation triggered, request duration above threshold;
- Risk signal: a sudden spike in WARNs often precedes ERRORs โ hook it into trend monitoring.
ERROR: a user's action failed
- Criterion: if it isn't fixed, the user will hit the same problem again;
- Typical content: external service call failed, data validation exception, uncaught error;
- Key requirement: every ERROR must carry context (URL, user/tenant ID, request parameters, stack trace), otherwise it's just unactionable noise.
FATAL: the system is already down
- Criterion: the service as a whole can no longer function;
- Typical content: database connection failure, missing required configuration, startup failure;
- Practical tip: FATAL is rare in web applications โ most "the system is down" incidents show up as bursts of ERRORs, covered by a "sudden ERROR spike" alert. Don't overuse FATAL and dilute its severity.
Log Levels in the Browser Console
Front-end levels share names with the back end but differ in capability. The Console natively supports:
| Method |
Level in Console |
Purpose |
console.debug() |
Debug (hidden by default; enable Verbose) |
Development-time debugging |
console.log() |
Info |
General output |
console.info() |
Info |
Same as above, more explicit |
console.warn() |
Warning, yellow |
Recoverable-issue hints |
console.error() |
Error, red, with stack trace |
Failures and uncaught exceptions |
Two practical tips:
Use console.debug instead of console.log for debug output โ production builds hide it behind the default filter, no manual cleanup needed;
Uncaught exceptions (window.onerror / unhandledrejection) are ERROR level by default and are the first clue in production triage.
The Front End's Special Problem: Users Won't Collect Logs for You
Back-end logs sit on servers, ready to inspect whenever trouble appears. Front-end logs scatter across each user's browser โ the user reports "the page is broken", and the Console errors and failed requests vanish with that page session. By the time the user follows a tutorial to open DevTools (steps in how to open the browser console), a refresh has already flushed the errors away.
So the question a front-end logging strategy must answer isn't "how to assign levels" โ it's "how to preserve the logs from the exact moment something broke". Common approaches:
| Approach |
How it works |
Cost |
| Build your own reporter |
Ship all console output back to the server |
High storage/privacy cost, sampling is hard to tune |
| Front-end monitoring platform |
Full capture + session replay |
Pay per volume; expensive for small and mid-size teams |
| On-demand capture (attached to bug reports) |
When a user submits feedback, the Console/Network errors from that moment are attached automatically |
Lowest cost; covers "user-initiated reports", the biggest source of all |
The third approach fits bug reporting naturally: the moment a user reports a bug is exactly the moment the logs matter.
BugCapturer uses precisely this on-demand capture: when a user (even a completely non-technical one) submits an annotated screenshot/recording via the browser extension or the embedded page SDK, the report automatically carries the current Console errors (with ERROR stack traces) and failed Network requests, plus the URL and browser environment (see the diagnostics feature). The developer's report arrives with ERROR-level log context already attached โ no more asking users to "open F12 and copy it". Reports can be shared via a login-free link, or pushed automatically into a Slack / Microsoft Teams channel for centralized tracking.
Common Mistakes
| Mistake |
Correct practice |
console.log for everything, never cleaned up |
Use levels: debug for debugging, info for business milestones, minify out debug at build time |
| Logging failures as INFO "to avoid scaring ops" |
A failure is an ERROR; alerting relies on levels, not on people reading logs |
| ERROR with a message but no context |
Always attach URL, parameters and stack โ otherwise you didn't log anything |
| DEBUG on everywhere "for easier troubleshooting" |
Levels are a filter: keep DEBUG off normally, enable it on demand when a problem occurs |
| WARN piling up, never handled |
Route WARNs into trend alerts; a spike is the precursor of ERRORs |
FAQ
Q: How many log levels are there?
A: The mainstream standard is five โ DEBUG, INFO, WARN, ERROR, FATAL. Some frameworks (Syslog, Trace-style systems) add TRACE/NOTICE/CRITICAL variants, but the semantics map one-to-one to the table above.
Q: How should logging levels be chosen and configured?
A: Everything on in development (starting at DEBUG), INFO or WARN and above in production; ERROR alerts, WARN trend monitoring. Configure libraries separately from business code so a dependency's DEBUG doesn't flood you.
Q: Does the front end need logging levels like the back end?
A: Yes, but simplified: four levels โ debug / info / warn / error โ are enough. The priorities are ERROR with a stack trace, and solving the "preserve logs at the moment of failure" problem.
Q: How do I get users to send me Console errors when they report a bug?
A: Asking non-technical users to copy errors is a lost cause. Use a tool like BugCapturer to capture Console/Network errors automatically at submission โ see the "on-demand capture" section above.