An AI (or any automated system) watching your processes can mislead you without inventing a single fact, just by mixing up two things that have nothing to do with each other: "I can't check right now" and "it's already fixed." It happened to us recently in the infrastructure behind one of our platforms, and the result was false alerts fired twice, back to back, until we caught it and fixed it.
The problem: silence got read as good news
We run a system that watches several pieces of infrastructure and emails us the moment it spots a problem. Nothing unusual so far. The bug was in how it decided a problem no longer existed: the moment it stopped getting a response from the piece it was watching, it marked the issue as resolved. It wasn't checking that things were fine, it was checking that it no longer received an error, and it treated that lack of a response as the best possible news.
The catch is that a piece of infrastructure can stop responding for perfectly normal reasons, like a restart that cuts off responses for a few seconds. That's exactly what was happening:
- The moment a restart began, the piece stopped answering for a few seconds.
- The monitor read that silence as "the problem is gone" and sent a resolved email.
- On the next cycle, once the piece was answering normally again, the monitor saw a state different from the previous one and sent a second email, this time a "new problem" alert.
Two false emails per real restart, with none of the pharmacies that depend on that platform having an actual problem. The same pair of alerts (3 problems marked resolved and the same 3 reopened 20 minutes later) repeated every time the watched system restarted, and a restart isn't a rare event: it's routine maintenance.
The decision rule: missing data is not a resolution
Here's the part that applies to any business, technical infrastructure or not: when a monitoring system (AI-driven or not) can't check the state of something, it has three possible answers, not two. It isn't "broken" or "fixed." It's "broken," "fixed," and "I don't know right now," and the third one can never be treated as if it were the second.
| Situation | Badly designed response | Well designed response |
|---|---|---|
| The piece doesn't answer | Marked "resolved" (absence = good news) | Keep the last known state until it can be verified |
| The piece answers correctly again | Marked "new problem" (because it changed from the previous cycle) | Compare against the real state, not the previous cycle, and if it was fine, stay silent |
| A real problem stays open but its state can't be read | Closed just because "there's no data saying it's still broken" | Stays open until something actually confirms it got fixed |
| The monitor itself stops responding | Total silence, nobody notices | A separate alarm, because a mute watchdog is a different blind spot (we wrote about that here) |
The short rule: if you don't have data, you don't have an answer, you have an unanswered question. Closing a problem without positive confirmation that it got fixed belongs to the same family of error as treating missing data as complete: here it's just the alerting system itself making the mistake, not whoever analyzes the business.
Why this gets more expensive the more you automate with AI
An occasional false email seems harmless. The real problem is what it causes over time: an alert channel that announces fixes that never happened stops being trusted just as fast as one that screams too often, and it's that lost trust, not the noise itself, that makes the next real alert get ignored. It's the same mechanism as the shepherd and the wolf, applied to an inbox.
This matters more the moment you add an AI that doesn't just alert but acts on that state: escalating an incident, deciding what to check first, or deciding whether it's worth waking someone up at 3am. If the input signal ("it's broken" / "it's fine") isn't reliable, any decision built on top inherits that same error, with the same apparent confidence as if the data were perfect. It's the same lesson we apply in the data and AI platform for a group of pharmacies: before letting a system recommend purchases or send real orders to a distributor, every piece of data going in has to be validated, not assumed.
How we fixed it
The fix wasn't adding more alerts, it was taking away the power of missing data to decide anything on its own:
- An unknown state no longer closes anything. If it can't be read whether a piece is still alive, already-open problems stay open until something confirms otherwise.
- It compares against the real state, not the previous cycle. Before, it was enough for the state to differ from the last reading to fire an alert; now it needs to differ from what's actually happening.
- We added a test suite that didn't exist before, covering explicitly the two scenarios that were failing: "the piece stops responding" and "the piece responds again after a brief cut." So if anyone touches this code again a year from now, those two specific cases can't break without something flagging it before it reaches production.
Checklist for your own alerting system (AI or not)
If your business depends on a dashboard, an automated email, or an AI agent telling you "everything's fine" or "this is broken," check the following before you trust it:
- Does it explicitly distinguish between "broken," "fixed," and "I don't know right now," or does it only have two states?
- Does a problem close itself just because it stopped signaling, or does it need positive confirmation that it got fixed?
- Does it compare the current state against reality, or against the last reading (which can be wrong)?
- Has anyone tested what happens when the watched piece restarts or gets cut off for a few seconds?
- How many false alerts would it take before you stopped reading that alarm's emails?
If that last question makes you uncomfortable, you already have your answer about whether it's worth checking now, before the alert that actually matters arrives the one day it's real and nobody's looking at it.
Building this piece well (for infrastructure, for an ERP, or for any process where AI acts on its own) is exactly the kind of work we do at AutoBoost: systems that don't just alert, but alert about what's actually happening. If you want to review how your process monitoring is set up, or you're considering an AI that decides based on that state, check our services or get in touch and we will look at it together.
