[HN Gopher] Log messages are mostly for the people operating you...
___________________________________________________________________
Log messages are mostly for the people operating your software
Author : todsacerdoti
Score : 87 points
Date : 2026-03-03 21:15 UTC (5 days ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| Etheryte wrote:
| While I see the point the author is trying to make, I'm not
| really sure I agree. Most users don't even read error messages,
| never mind logs. At best, logs are something they need for
| compliance, for most, the concept doesn't exist at all. I do
| agree that the logs should help you understand what went wrong
| and why, but in that regard the principle is the same for both
| sysadmins and developers and I don't really see the difference?
| hk__2 wrote:
| > Most users don't even read error messages, never mind logs.
|
| Yes, see all the questions on StackOverflow with people posting
| their error message without reading it, like "I got an error
| that says 'fail! please install package xyz!', what should I
| do?!?".
| dexwiz wrote:
| That question is more likely how do I install, not what to
| install.
| dylan604 wrote:
| I think that's being very generous. If you've ever been in
| tech support, you'll be amazed at how often you'll be asked
| what to do when it tells me to do X.
|
| If they don't know how to do X, then they should be able to
| look up how to do X. If it's something like install 3rd
| party library, then that's not the first party's
| responsibility. Especially OSS for different arch/distros.
| They are all different. Look up the 3rd party's repo and
| figure it out.
|
| But no, it's contact support straight away.
| dexwiz wrote:
| I've worked in tech support. I get that 25-50% of the
| cases appear to be "read the docs to me." But the
| majority of those is because docs are poorly written, are
| overwhelming for new users, or they don't understand them
| and won't admit that directly.
| butterbomb wrote:
| Oddly enough though, my journey into computers was greatly
| assisted by my curiosity at random log files that were being
| dumped to my desktop constantly.
| tempest_ wrote:
| Sysadmins needs logs that tell them what action they can do fix
| it. Developers need logs that tell them what a system is doing.
|
| Generally a sysadmin needs to know "is there an action I can do
| to correct this" where as a dev has the power to alter source
| code and thus needs to know what and where the system is doing
| things.
| EvanAnderson wrote:
| In my sysadmin work I curse every developer who makes me fire
| up strace, tcpdump, procmon, Wireshark, etc, because they
| couldn't be bothered to actually say what file couldn't be
| found, what TCP connection failed to be established. etc.
| lucianbr wrote:
| I get the impression that often it isn't laziness but the
| concept that error details leak information to an attacker
| and are therefore a vulnerability.
|
| I disagree with this view, but it definitely exists.
| EvanAnderson wrote:
| In a message returned by a server to a client I suppose
| it's defensible. For writing to syslog, event log, a log
| file, etc, it's not.
| superjan wrote:
| Yeah, along those lines we have requirements on never
| logging PII, and not logging anything that potentially
| contains PII, such as folder names.
| PunchyHamster wrote:
| > Most users don't even read error messages, never mind logs.
|
| They don't need to. The log message is so helpdesk have
| something actionable, or so it can be copy pasted into google
| to find people with similar problem maybe having solution.
| ragall wrote:
| > but in that regard the principle is the same for both
| sysadmins and developers and I don't really see the difference?
|
| No, it's very different: developers generally want to know
| about things they control, so they want detailed debugging info
| about a program's internal state that could have caused a
| malfunction. Sysadmins don't care about that (they're fine with
| coalescing all the errors that developers care about under a
| general "internal error"), and they care about what in the
| program environment could have triggered the bug, so that they
| may entirely avoid it or at least deploy workarounds to
| sidestep the bug.
| ignoramous wrote:
| For a FOSS Android app I co-develop, we go out of our way to make
| verbose logging efficient to collect & easy to share (one-click
| copy). I've seen users get good mileage out of asking an LLM just
| what has gone wrong. We are adding more structure to log messages
| and add in as much state (like callstack) as possible with each
| log line, and diagnostics from procfs on resources held (like
| memory, threads, fds).
| LgWoodenBadger wrote:
| All software should provide something meaningful for anybody to
| diagnose, if they're inclined to. It's particularly bad in the
| (Apple) mobile ecosystem, including AppleTV.
|
| I have AdGuard Home but one of my spouse's streaming services
| wouldn't work. "There was a problem." Gee thanks. Eventually
| figured out that I had to unblock a few hosts so it would work.
| Only found which ones by googling and finding some other poor
| soul who fixed it and documented it.
| thayne wrote:
| > It's particularly bad in the (Apple) mobile ecosystem
|
| It's been years since I've significantly used Apple software,
| but when I had to use a Mac at work, or helped friends or
| family troubleshoot some problem on Mac OS, I had a similar
| experience. When things don't "just work", it was very
| difficult to figure out why it didn't work.
| bonoboTP wrote:
| They don't want tinkering or tinkerers.
|
| Apple is all about walled-off, locked-down, black box, just-
| works (when it does) etc. It's supposed to seem like magic.
| You're not supposed to tinker with magic, it makes it
| pedestrian. Apple as a brand is a lifestyle, a feeling. The
| slick, polished brand. Remember "I'm a Mac, and I'm a PC"? PC
| is where you tinker, and there is screws and nuts and bolts and
| jargon and troubleshooting etc. In Apple land, you just take it
| to a slick genius bar and they do their magic. Or you just buy
| a new one.
|
| As a European I'm always baffled how Apple got so much market
| share among the actual techies and power users in the US. You
| do it to yourself by buying this stuff. It's for people who
| don't want to spend one second thinking about actual technical
| issues.
| yjftsjthsd-h wrote:
| Okay, but then their stuff needs to be perfect as designed.
| Because the moment there's a bug, we're back to needing
| diagnostic tools.
| bonoboTP wrote:
| There is a self-regulating loop that Apple users quickly
| learn not to "draw outside the lines" and just use the
| thing as designed and intended by Apple. If you use stuff
| like AdGuard, custom DNS etc, that's tinkerer tier stuff. A
| good Apple user either watches the ads or pays not to see
| them.
| yjftsjthsd-h wrote:
| My point is that even inside the lines there are still
| bugs.
| detourdog wrote:
| People make decisions based on their own value system. I'm
| glad to have choices. I can get everything done with the
| tools we call computers.
|
| When I view the logs on my Apple systems they make sense to
| me. One does have to understand the logs which implies
| understanding the system under diagnosis.
| DharmaPolice wrote:
| I totally agree but you can attribute a lot of the Apple
| worship to Microsoft and their OEM partners making PC laptops
| an often miserable experience.
| alpaca128 wrote:
| There's a difference between Apple's mobile devices which are
| an actual walled garden, and Mac OS which (begrudgingly)
| still lets you install and run pretty much anything. It has a
| nice terminal, no driver issues, and is not nearly as
| distracting and annoying as modern Windows (still has more
| than enough bugs and quirks though). And once update support
| runs out I can install Linux on it.
|
| iPads are a completely different world and really feel not
| just restrictive but the whole ecosystem constantly tries to
| push you towards subscriptions for everything, including the
| OS which conveniently offers the only sane backup solution
| that can cover all apps. It incentivises content consumption
| and giving up control over one's data. Not my cup of tea.
| naomi_kynes wrote:
| The interesting edge case with AI agents: the "operator"
| collapses into whoever owns the agent, and the log's job changes
| fundamentally.
|
| When a regular app logs an error, it's a passive record -- the
| operator investigates at leisure. When an agent logs "I'm about
| to delete these 47 files -- is that right?", it's an active
| interrupt. The log becomes a decision request, not an event
| record. "Waiting for human approval" is a semantically different
| thing than "ERROR: something failed."
|
| Most agent setups treat this badly -- write to stderr, fire a
| webhook, hope the human checks Slack. There's no canonical "agent
| pausing for human input" primitive in most stacks. It's logging's
| open problem for the agentic era.
| mfuzzey wrote:
| Depends a lot on the context and type of software.
|
| For server side software where there is a sysadmin in charge of
| keeping it running I generally agree.
|
| But for end user software (desktop, mobile, embedded) no one wil
| read the logs and there the logs can, and probably should, be
| aimed at the developers. Of course you can and should still
| provide usable and informative end user oriented error messages
| but they're not the same thing as logs
| PunchyHamster wrote:
| It doesn't. The detailed log might be nonsense to the user but
| so is generic error, and the difference is that the specific
| log message makes it far easier to find solution than generic
| one.
|
| I.e. SEO-optimized
| ragall wrote:
| > But for end user software (desktop, mobile, embedded) no one
| wil [sic] read the logs
|
| Lots of end user software is used in an enterprise context
| where the helpdesk staff will have to read those logs. And for
| B2C (or retail, or amateur, whatever you want to call them)
| users, often they will go through online tutorials to try to
| self-diagnose because the developers are most of the time
| unreachable.
| RadiozRadioz wrote:
| A small subset of technical users do read logs. If a desktop
| app has a problem, I have a fighting chance of fixing it if I
| have logs. Error messages may not give the full picture; what
| was the app trying to do before the error occurred? Logs let me
| debug slowness and crashes.
| majkinetor wrote:
| Any group of people is target of specific log level. INFO for
| random folks, DEBUG for programmers etc.
| thangalin wrote:
| Of possible interest:
|
| * https://dave.autonoma.ca/blog/2022/01/08/logging-code-smell/
|
| * https://dave.autonoma.ca/blog/2026/02/03/lloopy-loops/
|
| Both of these posts discuss using event-based frameworks to
| eliminate duplicative (cross-cutting) logging statements
| throughout a code base.
|
| My desktop Markdown editor[1], uses this approach to output log
| messages to a dialog box, a status bar, and standard error,
| effectively "for free".
|
| [1]:
| https://repo.autonoma.ca/repo/keenwrite/tree/HEAD/src/main/j...
| woeirua wrote:
| I feel like this is an outdated point of view now. Logs are
| clearly going to be read primarily by agents very soon, if
| they're not already now.
|
| For example, we're experimenting with having Claude Desktop read
| log files for remote users. It's often able to troubleshoot and
| solve issues for our users faster than we can, especially after
| you give it access to your codebase through GH MCP or something
| like that. It's wild.
| gnoack wrote:
| How does this change the point that is being made in the
| article? Your agent is also only taking one of the existing
| roles that humans today occupy (e.g. the software operator or
| developer)
| woeirua wrote:
| If the logs are being read by agents then they should be more
| detailed and verbose to help the agent understand the root
| cause. We reduce the volume of information for humans. That
| doesn't need to be the case any longer.
| justsomehnguy wrote:
| > But if your software is successful (especially if it gets
| distributed to other people), most of the people running it won't
| be the developers, they'll only be operating it.
|
| The biggest problem is what when you wrote a code for a 'totally
| obvious message' you yourself was in the context. Years, year,
| heck even weeks later you would stare at it and wonder 'why tf I
| didn't wrote something more verbose?'.
|
| Anecdote: I wrote some supporting scripts to 'integrate' two
| systems three times - totally oblivious the second and the third
| times what I already did it. Both times I was somewhere 60% when
| I though 'wait I totally recognize this code but I just wrote it!
| What in Deja-vu-nation?!'.
| jauntywundrkind wrote:
| This is a not-so subtle advantage JavaScript has over 90% of
| everything else: Chrome DevTools Protocol (CDP), which exists/is-
| great in-large-part thanks to JavaScript being an alive language.
| Of the _Stop Writing Dead Programs_ variety
| (https://jackrusher.com/strange-loop-2022/,
| https://news.ycombinator.com/item?id=33270235). It's just
| astoundingly capable, so _very_ richly exposes such a featureful
| runtime, across so many dimensions of tooling. REPL, logging,
| performance, heap, profile, storage, tracing and others, just for
| the core, before you get into the browser based things.
| https://chromedevtools.github.io/devtools-protocol/
|
| This is such a _core_ advantage to javascript: that it is an
| alive language. The runtime makes it very easy to change and
| modify systems ongoingly, and as an operator, that is so so so
| much better than having a statically compiled binary, in terms of
| what is possible.
|
| One of my favorite techniques is using SIGUSR1 to start the node
| debugger. Performance impact is not _that_ bad. Pick a random
| container in prod, and... just debug it. Use logpoints instead of
| breakpoints, since you don 't want to halt the world. Takes some
| scripting to SSH port forward to docker port forward to the
| container, but an LLM can crack that script out in no time.
| https://nodejs.org/en/learn/getting-started/debugging#enable...
|
| My cherry on top is to make sure the services my apps consume are
| attached to globalThis, so I can just hit my services directly
| from the running instance, in the repl. Without having to trap
| them being used here or there.
| keithnz wrote:
| From recent experience, I'm thinking logs need to be written for
| AI. Over the last few months, I've had a couple of issues where I
| took a bunch of logs from a bunch of interacting programs,
| pointed the AI at the logs and the source code and it's been
| really effective and finding the problems, often seeing patterns
| that would have been really hard for me to spot in all the noise.
| mjevans wrote:
| The log needs to document, at least in broad steps and critical
| details, what the next operation is and what key parameters
| were provided to it.
|
| A human, or an 'agent' can use those to figure out why said
| next step might have gone wrong.
| ziml77 wrote:
| This is the way I like to do it. I know bloating the logs too
| much can be a problem, but it's even worse if you're lacking
| information to reconstruct what happened when there ends up
| being a problem. And only providing that detail when there's
| an error isn't enough. What if the issue never triggered an
| error in the application and it was only caught later on
| either by a person seeing something was off or by an error a
| downstream system?
|
| Also it's helpful to log before operations rather than after
| because if a step gets stuck it's possible to know what it's
| stuck on.
| nubinetwork wrote:
| I recently went all-in on the systemd ecosystem as much as I
| could on some recent hardware installs, and my biggest pet peeve
| is the double timestamps and double logs I find in journalctl...
| it's like they never intended you to read the logs...
| hinkley wrote:
| Well the useful ones are. The rest are screaming into the void,
| or rather, the operator's ear.
| hinkley wrote:
| For years now I've been pushing for moving of all non actionable
| error messages and all aggregate-actionable error messages into
| telemetry data instead.
|
| Not the least of which because log processing SaaS companies seem
| to be overcharging for their services even versus hosted Grafana
| services, and really many of us could do away with the rent
| seeking entirely.
|
| The computational complexity of finding meaning in log files
| versus telemetry data leans toward this always being the case. It
| will never change except in brief cases of VC money subsidizing
| your subscription.
|
| If an error shouldn't trigger operator actions, but 1000 should,
| that's a telemetry alert not a data dog or Splunk problem.
___________________________________________________________________
(page generated 2026-03-08 23:00 UTC)