The instinct behind logging everything is a good one: you can’t know in advance which detail will matter, and there’s nothing worse than an incident where the line you need was never written. So the safe-feeling move is to write all of it and sort it out later. The trouble is that “later” has costs that don’t show up at the moment you add the line. Volume becomes a storage bill, then a retention policy shortened to control that bill, then — quietly — a situation where the incident you’re investigating happened just outside the window you can still afford to keep.

The subtler cost is what volume does to searchability. Signal doesn’t scale with lines written; it competes with them. A service emitting a handful of meaningful lines per request is one you can read. The same service emitting hundreds, most of them confirming that things proceeded normally, is one where finding the meaningful line requires already knowing what you’re looking for — which is exactly the knowledge you lack when it matters. Volume also makes queries slow, and a query that takes four minutes during an incident is one people stop running, falling back to guessing because guessing is faster.

The previous piece in this thread argued that logs should be written for a reader with no context. This is the same argument applied to quantity rather than content: the reader has finite attention, and every line spends some of it. That reframes the “just in case” line as something other than free insurance — it’s a small tax on every future investigation, paid by whoever is searching, in exchange for a possibility that usually doesn’t materialize. Most such lines are never read once. The few that are tend to be the ones someone deliberately wrote to answer a question they’d already had.

What works better is deciding what each level is for and holding the line. Errors and warnings should be rare enough that their presence is itself informative — if a warning fires ten thousand times a day, it has become background texture and no longer warns anyone. Info-level lines should mark meaningful state transitions, not narrate control flow. Debug-level detail is worth keeping in the code but not worth emitting by default; making it switchable per-service or per-request gives you the depth when you need it without paying for it constantly. And sampling is legitimate for high-volume paths: one in a thousand successful requests logged in full tells you what normal looks like, which is all a successful request needs to contribute.

Underneath all of it is a question worth asking before adding any line: what question would this help someone answer? If there’s a clear answer, the line is probably worth its cost, and knowing the question usually improves the wording too. If the honest answer is “I don’t know, but maybe something,” that’s not insurance — it’s deferred cost with no identified beneficiary. Keeping fewer, better lines isn’t about spending less. It’s about the search still working on the day you actually need it.