We run a pipeline that reads the news every morning and decides which stories are worth reacting to. It drafts outreach off the ones that survive. It ran for four days without producing a single piece of outreach. Every run finished. Every run was marked successful. The dashboard was green the entire time.
The classifier in the middle of that pipeline is a language model, and its account had run out of credit. The provider returned a payment error. Our pipeline received that error and treated it as a response. It found no usable stories inside, so it handed an empty list to the next step. Nothing downstream had any reason to complain. An empty list is a valid list.
We found it because someone asked why the outreach volume looked low that week. Not because anything alerted.
Why Status Monitoring Cannot See This
Traditional monitoring was built for software that breaks in obvious ways. A service goes down and something pages you. A process exits with a non-zero code and something pages you again. That model works because failure and silence arrive together.
Language models broke that assumption. They almost never go down in the way a database goes down. They return something. Sometimes the something is an error object wearing an HTTP 200. Sometimes it is a refusal. Sometimes it is a perfectly formed answer to a question you did not ask, because a truncated prompt reached the model and it did the reasonable thing with what it got.
At the transport layer all of these are successes. At the workflow layer they are successes too, because the node received a response and passed it on. The only layer that can tell the difference is the one nobody instruments, which is whether the run produced the thing it exists to produce.
This is the gap. We monitor whether our systems ran. We rarely monitor whether they worked.
The Failures We Found Once We Went Looking
After the four-day run I went back through everything we operate and looked specifically for this pattern. It was not a rare bug. It was a category.
A scraping service we depend on returns zero rows at random, roughly once in every several runs, with no error. The workflow completes in half the usual time and reports success. We had been treating those as quiet days.
A public data source we pull from turned out to be refusing the large majority of our requests. Not blocking us, not returning an error we could catch, just declining and returning nothing useful. Our intake numbers had been falling for weeks and we had been explaining it as a slow market.
On the infrastructure side, the database behind our automation platform grew to twenty-five gigabytes, almost all of it execution logs nobody was ever going to read. Nothing failed. Disk simply filled, slowly, until it was close enough to full to become an emergency. There was no alert for this because there was no error. Growth is not an exception.
None of these were sophisticated problems. Every one of them was invisible to a monitoring setup that asks whether the process finished.
What We Monitor Now
We changed the question. Instead of asking whether a run completed, every workflow now has to answer how many usable items it produced, and that number is checked against what it normally produces.
In practice this comes down to a few habits that cost very little to build.
Every run emits a count. Not a status, a count. Stories classified. Drafts written. That number gets written somewhere durable.
Any run that produces zero gets treated as a failure regardless of what its status says. Not always an alarm on the first occurrence, because a genuinely quiet Sunday exists, but two consecutive zeros raise something a human sees.
Model responses get validated on shape before anything downstream touches them. If a step expects a list of scored items and receives prose instead, that is a hard stop rather than an empty pass-through. The same goes for an object with an error key inside it. Most of our silent failures would have been loud if this one check had existed from the start.
Provider account state is checked on a schedule, separately from the pipelines that depend on it. Credit balance and key validity are not things you want to discover through their absence.
Cost is watched in both directions. Everyone builds alerts for spending too much. Spending suddenly less is the better early warning, because it usually means the work stopped happening.
The Discipline This Actually Requires
The part that took longest was not technical. It was accepting that a green dashboard is not evidence of anything.
There is a real pull toward believing your own instrumentation. You built it, it is showing you what you asked it to show you, and it is telling you things are fine. The failure mode of AI systems in production is that they will keep telling you things are fine while quietly doing nothing, and the gap between those two states can run for days before a human notices that some number looks wrong.
I have come to think the useful measure of an AI system is not its accuracy on a benchmark. It is how long a total failure can hide inside it. In our case that number was four days, and reducing it did not require better models or a bigger observability stack. It required deciding what each workflow was supposed to produce and refusing to call a run successful when it produced none of it.
That is not a difficult idea. It is just not the idea most teams start with, because when you are building something new you are focused on getting it to work at all, and the question of how you will know when it stops working feels like a problem for later.
