Why your automation broke three months after it was built
Nobody changed anything. That’s what everyone says when they call me, and it’s almost always true — the change came from somewhere else.
Automations almost never fail on day one. Day one is when everyone is watching. They fail in month three, on a Tuesday, when the person who relied on them is busy with something else. And they usually fail silently, which is the part that costs money.
I get called in for this a few times a year. The pattern is consistent enough to write down.
What actually breaks
Someone renamed a field. A sales manager decides “Phone” should be “Contact Number” in the CRM. Perfectly reasonable. Every automation referencing that field now writes to nothing, or errors out, or — worst case — writes an empty value over good data.
An API version was retired. The platform announced it eight months ago in a changelog nobody reads. Your integration was built against v2, v2 is gone, and the endpoint now returns a redirect your automation doesn’t follow.
The data grew past a limit. This one is sneaky. A build that worked perfectly at 200 records starts failing at 2,000 because the API paginates and the original build only ever fetched the first page. Nothing errored. It just quietly stopped seeing most of the data.
A rate limit got hit. Fine at 10 messages an hour, broken at 60. I ran into this on a JustCall build — the platform caps outbound messages per minute, and the fix was a deliberate pause between sends rather than anything clever.
Someone added a new case. A new supplier, a new product type, a new office. The automation was built for the four cases that existed, and case five falls through every branch and lands nowhere.
Why nobody notices
Here’s the thing most builds get wrong: the failure is invisible by design. Zapier and Make will email the account owner when a run errors, but that address is often the person who set up the account years ago, the emails get filtered, and a filtered run isn’t an error at all — it’s a record that quietly didn’t match a condition and stopped.
So the automation doesn’t announce anything. It just does less than it used to. You find out when a customer asks where their invoice is.
Four things that prevent it
Error handlers on every branch, not just the main path. If a build has six routes, it needs six error paths. On the accounting document pipeline I built, each supplier format runs on its own branch precisely so one failing format can’t take down the other five.
Validate before you write, not after. Check the required fields exist before pushing the record. Anything missing gets held for review rather than written in wrong. Wrong data is far more expensive than missing data, because missing data announces itself.
Send failures somewhere a human actually looks. Not the account owner’s inbox. A Slack channel, a Google Sheet, a dashboard — somewhere that a growing list of flagged records becomes visible.
Write down what it does. A one-page document naming every field the automation depends on. When someone proposes renaming “Phone”, that page is what tells them it’ll break three things. Almost nobody does this, and it’s the cheapest protection available.
If yours has already broken
Start with the run history rather than the build. Find the last successful run and the first failed one, and look at what changed between them — that window usually contains the answer. Fixing the immediate error is the easy part; the real job is working out why it took three weeks for anyone to notice, and closing that gap.
If you’d rather not do that yourself, tell me what broke and I’ll take a look.