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.
Where this shows up outside engineering
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.
The tell is the same everywhere: a system says everything is fine, and the person relying on that signal has no reason to look closer, so a real problem runs for weeks or months before anyone notices. The fix is also the same everywhere. Before trusting a status, ask what outcomes it could actually be hiding, and whether a single word is doing the work of three.
If part of your business runs on automated systems, and you've never actually audited what your own success signals can and can't tell you, that's worth an hour before it costs you more than that.
Working on something like this? Tell us what you need or see the related service.
