Too Much vs Too Little Logging in Java
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Logging too much and too little both cause serious problems, just different ones.
Start with too much. The immediate issue is noise — if you log every method call and every variable at DEBUG in production, the logs become unreadable, and when a real error happens it's buried in thousands of routine lines. There's also a performance cost, because writing logs is disk I/O and disk is slow; at high volume you can actually saturate I/O and slow the whole application down.
Then there's money — cloud logging services charge by data volume, so shipping verbose DEBUG logs to something like CloudWatch or Datadog can add real cost to the monthly bill. But the worst consequence is alert fatigue: if you log every caught exception at ERROR, including things like validation failures, your on-call team gets paged constantly, they start ignoring alerts, and a genuine database outage gets missed.
On the flip side, too little logging leaves you blind. If a customer says their payment failed but you only logged successful payments, you have no idea what went wrong — was it a timeout, a validation error, a database failure? You end up deploying new code just to add logging, which stretches incident resolution from minutes to hours while customers are affected.
The right balance is intentional logging: business events at INFO, handled surprises at WARN, real failures at ERROR, and DEBUG off in production unless you're actively troubleshooting. And always include context like order IDs and user IDs so you can correlate events. The thing that impresses interviewers is acknowledging that logging has real costs — CPU to format, I/O to write, network to ship, storage to keep.
Treating it as expensive makes you more deliberate about what you log.
Too Much vs Too Little Logging in Java
Direct Answer
Too much logging buries the signal in noise, costs CPU/disk I/O, inflates storage bills, and — worst of all — causes alert fatigue when everything is ERROR. Too little logging leaves you blind: you can't reconstruct what happened during an incident. The goal is intentional, leveled logging with business context, not logging everything 'just in case'.
Code Example
// Noise: logs every iteration at INFO, no context
for (Item i : cart.items()) {
log.info("processing item"); // floods logs, says nothing useful
}
// Signal: one leveled, contextual line per meaningful event
log.debug("Pricing {} items for cart {}", cart.size(), cart.id()); // dev detail
log.info("Order {} placed: {} items, total {}",
order.id(), order.size(), order.total()); // business event w/ IDs
The second style is searchable, correlatable by order.id(), and stays quiet at production INFO level.
Common Mistakes & Pitfalls
- Logging every variable: leaving debug-everything statements in production code, treating logging as free.
- ERROR overuse: logging expected exceptions at ERROR, creating alert storms and desensitizing the team.
- No business context: logging 'operation failed' with no order ID or user ID, so the line is useless during an incident.
Check your understanding
Answer these without looking back at the article.
- How do you audit logging in a codebase to improve its quality?
- What is log sampling and when would you use it?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.