March 8, 2026
Logs, lies & “There was a problem”
Log messages are mostly for the people operating your software
Logs vs People: stop writing errors for yourself—make them make sense to whoever’s running the app
TLDR: The essay argues logs should be written for the people operating software, not just for developers. Comments split: some say users never read logs, others push structured logs and even AI to decode them; consumer apps get roasted for useless errors, and AI agents make logs urgent decisions.
The essay says it plainly: log messages shouldn’t be secret developer diaries—they should help the folks actually running your software. The author urges writing messages that operators can understand without a decoder ring, echoing ideas from Evan Hahn’s post and the world of MTAs (mail transfer agents) that log useful “expected error” details.
Cue the comments, and the drama pops. Etheryte drops a cold splash: “Most users don’t even read error messages, never mind logs,” suggesting logs are mostly compliance dust. mfuzzey plays referee: for servers, yes—make logs operator-friendly; for consumer apps, make errors friendly but log internals for devs who’ll fix things later.
Then the plot twist: ignoramous says their Android app made logs one-tap shareable—and users are sending them straight to an AI chatbot to explain what went wrong. The crowd cackles: “ChatGPT, become my sysadmin.” Meanwhile LgWoodenBadger launches a roast of the Apple ecosystem’s infamous non-answers: the meme of the day is the blank-faced error, “There was a problem.” Gee thanks. That rant ends with a real story: a streaming app broke until they manually unblocked mystery hosts—found only by Googling.
Finally, naomi_kynes brings the spiciest twist: with AI agents, logs turn into live decision prompts—“I’m about to delete 47 files, is that right?” Suddenly logs aren’t just receipts, they’re red buttons. The vibe? Make logs for humans—or prepare for chaos.
Key Points
- •Non-debug log messages should primarily serve the needs of operators running the software.
- •Developers tend to write logs for their own context; production logs should be understandable without insider knowledge.
- •If a log message offers operators no value, it shouldn’t be enabled by default or should be rephrased.
- •The principle applies to both expected and unexpected errors; on abort, the program must state why for admins.
- •MTAs demonstrate that logging frequent expected errors (e.g., DNS failures) can be vital for tracing specific messages.