Why automations break silently and nobody notices

Nobody broke your automation. Something around it moved.

The automation is doing exactly what it did on day one. Everything else moved. Someone renamed the Phone column to Mobile, so the step that looked for it now finds an empty field. Someone tidied up the shared drive and nested the folder one level deeper, so the path is gone. A permission granted once expired after sixty or ninety days. The vendor released a new API version and turned the old one off.

One cause wins by a mile and almost nobody sees it coming: the automation runs under one person's account. When that person leaves, resets a password, or gets pulled off a shared folder during offboarding, everything hanging off that login goes with them. If your tool allows it, connect it with a company account instead of somebody's personal one.

Six months of clean runs is not proof that it's solid. It's proof that for six months nobody touched anything nearby.

The failure is cheap. The silence is what costs you.

There are two ways to fail. The loud way: the tool turns red, emails you, stops. That one barely hurts, because you find out the same day. The quiet way is the expensive one: the job starts, finishes, reports success, and did nothing.

The filter that used to return thirty rows now returns zero, and processing zero rows is a technically perfect run. The automated email still goes out with an empty name field, that "Hi ," nobody on your team ever sees because nobody on your team receives it. The weekly summary rebuilds itself using the last exchange rate the source actually returned. None of that turns anything red.

The cost piles up quietly: quotes that never went out, follow-ups nobody made, leads that never reached the system meant to hold them. By the time someone notices, it's been three weeks and the cleanup is manual.

Alert on nothing happening, not on errors

Most alerts are built backwards: they fire when something errors out. You need the opposite, an alert on absence. Have every automation report a number when it finishes: "processed 14 leads," "copied 7 rows." That message goes to an inbox or a channel, once a day or once a week, depending on how often it runs.

That gets you two signals for the price of one. If the message doesn't arrive, it's dead. If it arrives with a zero, or a number far outside the usual, it's running but starving for data. Write down the normal range in advance: if it's usually between ten and forty, both zero and two hundred are worth a look.

And send the alert to a person by name, not to a shared inbox. An alert with no owner gets seen by everyone and handled by no one. Put the next step inside the message itself: where to look, who to tell, and what not to touch until someone checks it.

Fifteen minutes a month, an hour a quarter

Once a month, open the run history and look at two things: when the last run happened and what numbers it has been reporting. Then push one real record end to end — submit a test lead and follow it all the way through. That's the only way to catch a hollow success, because the dashboard will keep telling you everything is fine.

Once a quarter, do the longer pass: which keys and permissions expire in the next ninety days, which account each connection runs under, and whether the vendor sent notice of changes. Those "we're updating our API" emails arrive months before the shutdown and get archived unread.

And one house rule that prevents half of these incidents: renaming a column, a folder, or a field is a production change, and whoever does it says so first. Maintenance minutes are real minutes. Budget them the way you budget the build, because somebody pays for them either way.