My marketing runs itself. I have written about that with some pride, because it took real work to build and it does something I genuinely could not keep doing by hand.
Then it skipped a day.
Not dramatically. No error, no alert, no red screen. It simply did not run, and the day passed like any other, and I found out afterwards by reading a folder of logs and noticing one was missing.
The failure nobody designs for
When people talk about automation failing, they picture something breaking loudly. A crash. A wrong output. A bad post going out with a mistake in it. Those are the failures you plan for, because they announce themselves.
The failure that actually gets you is quieter. The thing does not run at all. There is no output to be wrong, no error to catch, no alert to fire, because nothing happened. Silence looks exactly the same as success from the outside.
That is the gap between a schedule and a system. A schedule says "do this at seven". A system knows whether seven happened.
What I had actually built
I had built the doing part very carefully. Rules about what may never be published. Checks that refuse to ship a number without a source. Fallbacks so that if one channel fails, the other still goes out. I had written about how I use AI agents to run my own marketing and I meant every word of it.
What I had not built was the part that watches. Everything I designed assumed the run started. Every safety mechanism lived inside the run. When the run itself never began, the entire apparatus of care I had constructed simply was not present, because it only existed once the thing was already going.
That is a design mistake and it is mine, not the system's. I put all the intelligence inside the process and none of it outside, looking in.
The uncomfortable comparison
Here is what made it sting. This is exactly the failure I describe to clients.
A business puts an automation in and then stops watching the thing it replaced. Six weeks later something has been quietly not happening, and nobody noticed because the whole point of automating it was to stop thinking about it. The relief of not having to check is the same thing as the absence of checking.
I have said versions of that sentence in meetings and then built a system with the same hole in it. Knowing a pattern and being immune to it are different states, and I keep having to learn that. It is the same lesson as the SEO bugs that hid our own site while I was busy building for everyone else.
What actually fixed it
Two things, both small.
A heartbeat. Every run now writes one line saying it happened, whether it succeeded or failed. The line is not for reading. It is for its absence to be visible. A missing line is louder than a written one, which is the whole trick.
A catch-up path. When a run does start, its first job is to look back and ask what did not happen. It reconciles what should exist against what does, and it fills the gap rather than starting fresh from today. Which is how the missed day got published, a day late, instead of quietly never existing.
Neither of those is clever. Both of them are the difference between something that usually works and something you can actually rely on.
The rule I took from it
Every automation needs three parts, and I had only built one.
The first is the work itself. The second is the guardrails, the rules about what it may and may not do. Almost everyone who builds automation gets these two right, because they are the interesting parts.
The third is the watcher: something outside the process whose only job is to notice when the process did not run. It is the boring part, it produces nothing on a good day, and it is the only part that catches the failure mode that has no output.
Automation does not remove the need to check. It changes what you check from the work to the watching. If nobody is watching, you have not automated the task. You have just stopped doing it and agreed not to look.
The wider version of that argument, with the South African numbers behind it, is over on the business blog: why AI projects fail in South Africa. Different scale, same hole.
Frequently Asked Questions
What actually went wrong? A scheduled run did not start. There was no error and no bad output, because nothing ran. It surfaced only when I read back through the run logs and noticed a date was missing from the sequence.
Why did none of your safety checks catch it? Because every one of them lived inside the run. They validate what gets published, so they only exist once publishing has begun. A run that never starts passes through all of them by not reaching any of them.
What is a heartbeat and why does it help? One line written by every run recording that it happened. Nobody reads it on a good day. Its value is that a gap in the sequence is immediately visible, which turns silent non-execution into something you can actually see.
What would you tell someone automating part of their business? Build the watcher at the same time as the work, not after something goes missing. If the only way you would find out that an automation stopped is by noticing its output was absent, you will find out late.
More of the build, and the mistakes, at heinoux.nexbdm.co.za.