WARN vs ERROR Log Levels

Q: WARN vs ERROR Log Levels

WARN usually marks an unexpected or degraded condition that the application handled, while ERROR marks an operation that failed or a serious condition that needs investigation. This is a convention, not an alert guarantee: monitoring policy decides whether either level pages someone. Classify the event from the caller's outcome and avoid logging the same failure at several layers.

The difference between WARN and ERROR comes down to whether the operation actually completed. WARN is for when something unexpected happened but the application handled it and the operation still succeeded. For example, you tried to read a config property, it wasn't set, so you fell back to a default — that's WARN, the app kept working but it's worth noting. Or a downstream service was slow, you retried, and it eventually worked — also WARN. The user's request succeeded; you were just in a degraded mode for a moment. ERROR is for genuine failures where the operation couldn't complete or produced a wrong result. If you try to save an order but the database is down, that's ERROR — the order didn't get saved. If a payment gateway rejects the transaction and you can't process the payment, that's ERROR, because the thing the caller asked for failed. The operational distinction is what interviewers really want to hear: ERROR logs typically trigger alerts and page on-call engineers, while WARN logs are reviewed during business hours. So if you mislabel things and log routine events at ERROR, you create alert fatigue — people start ignoring alerts, and a real outage gets missed. The most common fresher mistake is logging every caught exception at ERROR. Not every exception is an error. A user entering the wrong password isn't a system failure, it's normal behavior, so that's INFO. Expected business exceptions like a validation failure or an insufficient-balance exception aren't ERROR either — those are scenarios you designed for. My simple rule is: if the user's action still succeeded despite the hiccup, use WARN; if their action failed, use ERROR. And a secondary check — should this page someone right now? If yes, ERROR. If it can wait until morning, WARN.

The difference between WARN and ERROR comes down to whether the operation actually completed.

WARN is for when something unexpected happened but the application handled it and the operation still succeeded.

For example, you tried to read a config property, it wasn't set, so you fell back to a default — that's WARN, the app kept working but it's worth noting. Or a downstream service was slow, you retried, and it eventually worked — also WARN. The user's request succeeded; you were just in a degraded mode for a moment.

ERROR is for genuine failures where the operation couldn't complete or produced a wrong result. If you try to save an order but the database is down, that's ERROR — the order didn't get saved. If a payment gateway rejects the transaction and you can't process the payment, that's ERROR, because the thing the caller asked for failed.

The operational distinction is what interviewers really want to hear: ERROR logs typically trigger alerts and page on-call engineers, while WARN logs are reviewed during business hours. So if you mislabel things and log routine events at ERROR, you create alert fatigue — people start ignoring alerts, and a real outage gets missed. The most common fresher mistake is logging every caught exception at ERROR.

Not every exception is an error. A user entering the wrong password isn't a system failure, it's normal behavior, so that's INFO. Expected business exceptions like a validation failure or an insufficient-balance exception aren't ERROR either — those are scenarios you designed for.

My simple rule is: if the user's action still succeeded despite the hiccup, use WARN; if their action failed, use ERROR. And a secondary check — should this page someone right now? If yes, ERROR.

If it can wait until morning, WARN.

The difference between WARN and ERROR comes down to whether the operation actually completed.

WARN is for when something unexpected happened but the application handled it and the operation still succeeded.

My simple rule is: if the user's action still succeeded despite the hiccup, use WARN; if their action failed, use ERROR. And a secondary check — should this page someone right now? If yes, ERROR.

If it can wait until morning, WARN.

Quick revision

Interview answer