Automation should fail loudly
The dangerous automations aren't the ones that break. They're the ones that break politely and say nothing.
By Danny · 2 May 2026 · Updated 8 August 2026 · 5 min
A broken automation announces itself about as often as a broken smoke alarm. Everything looks normal until the day you need it, and then you find out it stopped working in March.
The pattern is nearly always the same. A field gets renamed, or an API changes a response, or someone revokes a login when a member of staff leaves. The automation doesn't crash. It quietly does nothing, and doing nothing looks identical to having nothing to do.
What we do instead
- -Every automation reports that it ran, not just that it failed
- -A heartbeat: if it hasn't run in the window it should have, someone hears about it
- -Failures arrive in plain English, in the place people already look, not in a log nobody opens
- -One named human owns each one, even if that human is us
If you can't tell the difference between working and stopped without logging in, it isn't finished.
The counter-argument is alert fatigue, and it's fair. The fix isn't fewer alerts, it's alerts that mean something. Nobody ignores the one message a month that says a hundred and forty invoices didn't send.
If this is a bit close to home, you might recognise some of the things we've built or the tools we tend to reach for.