The dashboard that lied
We run a lot of automated jobs internally: nightly maintenance, content pipelines, alert systems that watch other systems. Every one of them reports a status, and for a long time that status was a single true or false.
One of ours was a cleanup job that checks disk space and clears out old cache files if things get tight. It reported success every single run. Meanwhile the actual problem it existed to catch kept happening, because the job was marking itself successful just for finishing, not for fixing anything.
A different job, built to catch broken internal links, did the opposite. It started reporting failure the moment it found even one broken link, so a routine day with a handful of findings looked identical to the tool itself being down. Two jobs, two directions, same root defect.
Two states pretending to cover three
Both jobs were squeezing a real outcome that has at least three states into a box built for two. A run can crash. A run can finish clean. A run can finish fine and still have something worth a human's attention. True or false cannot hold all three, so one of them always gets mislabeled.
The cleanup job collapsed 'ran without crashing' and 'actually solved the problem' into the same green checkmark. The link checker collapsed 'the tool is broken' and 'the tool works and found something' into the same red alarm. Neither lie was intentional. Both came from writing the status check before thinking through what outcomes the job could actually produce.
This is easy to miss because a boolean is the default. Most tools hand you a true/false return value for free, and it's tempting to just wire that straight into a dashboard. The mismatch only shows up once you're staring at a green light and a problem that has clearly not gone away.
The fix is naming the states, not adding more alerts
The instinct when a monitor lies is to add more monitoring. That usually makes it worse: more channels, more noise, more things to eventually ignore. The actual fix is smaller and less exciting. Write down every outcome the job can really produce, then build a status field with a slot for each one.
For the cleanup job, that meant separating 'did the run complete' from 'did it actually reclaim space' from 'is the system still in a degraded state despite running.' Once those were distinct fields instead of one boolean, the honest answer showed up immediately: the job had been completing and doing nothing, for weeks.
For the link checker, it meant splitting 'the pipeline itself is healthy' from 'the pipeline found issues to review.' Now a normal day with a few findings reads as exactly that, not as an outage. The fix took less code than the original alert did. It just required deciding what true and false were actually supposed to mean before shipping either one.
We fixed it, and now we build it that way from the start
This isn't a software-only problem. Any status you rely on without checking underneath it is a boolean pretending to cover more ground than it can. A monthly report that says 'campaign is live' doesn't tell you if it's producing anything. A 'ticket resolved' tag doesn't tell you if the customer agreed it was resolved.
We rebuilt both of our jobs on a three-state model: crashed, completed with nothing to report, and completed with something worth a look. That's the whole fix. No new alert channels, no extra dashboards, just a status that can't lie by omission because it has a slot for the outcome that used to get swallowed.
This is standard practice on every monitoring and automation system we build now, for ourselves and for clients: name the real states before you write the check. If your business runs on automated systems and you've never had someone confirm what your success signals can and can't actually tell you, that's exactly what we do. Tell us what you want monitored and we'll build it right or audit what's already in place.
Working on something like this? Tell us what you need or see the related service.
