For a long time, the only record of something going wrong on a client’s site or server was a line written to a log file that nobody was looking at unless they already suspected a problem. No list, no history, nothing that said “here’s what’s currently broken” without someone deciding to go and check first.
The bug hiding inside the bug tracking
While building a proper fix for this, we found something worth fixing on its own. The existing check-in process was meant to catch new errors on a site, but it was re-recording every unresolved error on every single check, not just the new ones. A site with one persistent problem didn’t produce one log entry. It produced a new one every time the site checked in, forever, until someone happened to notice and clear it.
That’s a strange failure mode: a monitoring system that gets noisier the longer a real problem sits unfixed, instead of easier to spot. The fix came before anything else got built. Only genuinely new errors, the ones not already known from the last check, get recorded going forward. Everything else stays quiet, the way it should.
One shared way to see it, not three
Errors don’t belong to just one thing. Some are specific to a single site, some to the server underneath it, and some are really about the client relationship as a whole. The tempting shortcut was building a separate error screen for each of those three views. We didn’t take it.
Instead, one underlying error record and one shared way of viewing it got built once, then reused with a different filter for each level: a site’s own error history, a server’s error history, and a global view that also rolls up into a per-client picture. Adding the server view or the client view afterwards didn’t mean writing a new screen from scratch. It meant pointing the existing one at a different filter.
From “something’s wrong” to “someone’s on it,” in one step
Seeing an error is only half the job. What used to happen next was manual: someone spots it, opens a ticket, retypes what the error actually said. That’s a second chance to lose detail, or to just not get around to it.
Now a logged error can become a tracked piece of work directly, in one action, carrying its original message and detail straight into the new ticket rather than someone re-describing it from memory. The original error record itself doesn’t change when this happens. It stays exactly as it was logged, a permanent account of what actually happened, with the resulting ticket linked alongside it rather than replacing it.
Final thoughts
None of this was really about building a dashboard. Fixing the duplicate-logging bug first mattered because a system that gets noisier the longer a problem sits unfixed will train people to ignore it. Everything after that was about shortening the distance between something breaking and someone actually owning it.
If the honest answer to “how would we know if that broke” is currently “a client would probably tell us,” more logging usually isn’t the fix. A single owner for that record, and one action to turn it into work, tends to matter more than the logging itself.
Ready to stop finding out from your client?
If a client mentioning a problem is currently how your team finds out about it, we’re happy to talk through what a proper error record, and a shorter path from spotting one to fixing it, would look like for your setup.
