I still think logging is a product feature.
That sounds a bit dramatic until you are the one trying to figure out why something broke, why a user got blocked, or why a support case is taking too long to answer. At that point logging stops being an internal detail and starts looking like part of the experience.
Good logging saves time in two places. First, it cuts down support work because you can answer basic questions faster. Second, it shortens incident diagnosis because you can see what the system was doing instead of guessing from symptoms. Both matter more than teams admit when they are deciding how much time to spend on logs.
Logging is for people, not just machines
Too many systems log as if the only reader will be a developer already familiar with the codebase.
That is a mistake. The person reading logs might be a support engineer, an on-call developer who has never seen the path before, or your future self at 2 a.m. They do not need poetry. They need enough context to understand what happened and where to look next.
The best logs usually answer a small set of questions:
- what was the system trying to do
- what input or state mattered
- what failed
- where the failure happened
- what identifier or trail would help find the rest of the story
If a log line does not help answer one of those, it is probably just noise.
Bad logs make simple problems expensive
I have seen small issues turn into long investigations because the logs were useless.
Sometimes the problem is that the logs are too sparse. Sometimes they are too noisy. Sometimes the useful fields are there, but buried in a wall of text nobody wants to scan. All of that slows people down. It also creates a weird kind of operational fear, because nobody trusts the system to explain itself when it matters.
That is not just an engineering problem. It becomes a support problem, a delivery problem, and eventually a confidence problem.
If a team cannot tell whether a failure is expected, recoverable, or serious, they end up spending time on the wrong thing. Good logging reduces that uncertainty.
What I want from logs
I do not want every line to be clever. I want it to be useful.
For me, that usually means logs should be:
- structured enough to search reliably
- specific enough to correlate with a request, job, or user action
- clear about whether something is informational, suspicious, or broken
- consistent enough that you do not need to relearn the format every time
I also want logs to tell the truth. If something failed, say so. If the system retried, say that too. If a fallback path was used, make that obvious. The whole point is to reduce ambiguity.
Logging is cheaper than guessing
The real case for logging is not that it looks professional. It is that it removes guesswork.
Guessing is expensive. It costs support time. It costs incident time. It costs confidence when the team is trying to decide whether a problem is isolated or structural. A decent log trail usually gets you to the answer faster than a lot of extra ceremony does.
That is why I still treat logging as part of the product. Not because users read the logs directly, but because people who operate the product depend on them every day.
If the system is going to fail sometimes, it should at least explain itself.
