Silent failure is the real enemy

Everyone building their first automation worries about it breaking. Almost nobody worries about it not breaking, which is the failure that actually costs you.

Here is the shape of it, in a story assembled from how these things actually go: call her a freelancer with an invoice chaser. Overdue invoice appears in the sheet, a polite reminder goes out, repeat weekly. It works beautifully for two months, at which point she changes her email password, and the connection the automation used quietly stops being valid. Nothing turns red, because nothing errored: the trigger simply stopped firing. She notices six weeks later, not through any dashboard but through the bank balance, and the expensive part is not even the late cash. It is three clients who went six weeks unreminded and the apology round that follows. An automation that had crashed loudly on day one would have cost her nothing.

How things fail silently

The trigger stops firing. An integration's auth expires. Nothing errors. Nothing simply happens. This is the most common failure and the hardest to notice, because the absence of output has no colour: your inbox looks exactly as it would if there were genuinely nothing to do.

A field changes. Someone renames a column. Your automation writes to a field that no longer exists, or writes empty values, happily. Spreadsheets are the load-bearing walls of small automations, and they get renovated by people with no idea anything is resting on them.

The AI step drifts. It starts returning a slightly different format. Downstream steps mostly cope, until they don't. "Mostly cope" is the trap: the failure arrives gradually, record by record, so there is no single day on which anything visibly broke.

A filter silently matches nothing. It runs perfectly, processes zero records, reports success. A date format changes upstream, the filter that used to catch "overdue" now catches nothing, and everything stays green because running and doing are different things.

Every one of these looks like success in the dashboard, and that is the thread worth pulling: a dashboard reports that the machinery executed, not that the work happened. The gap between those two sentences is where all four failures live.

Build in a heartbeat

The fix is simple and almost nobody does it: make it report even when there's nothing to report.

Weekly summary: processed 14 records, 0 errors, 2 routed for review.

Now "zero records" is visible. Without it, no message means either nothing to do or completely broken, and you cannot tell which, so you assume the harmless one. For weeks.

Every tool can do this, and it costs one step at the end of the workflow: count what was processed and send the count somewhere you already look. Somewhere you already look, not a new dashboard: the Monday email, the team channel, the note to self. A heartbeat nobody sees is the original problem wearing a new hat.

Alert on absence, not just on error

Set an alert if the automation hasn't run in 48 hours.

Absence is the failure signal that error alerting will never catch, because there is no error. There's nothing. Error alerts answer "did something go wrong?"; the absence alert answers "did anything happen at all?", and the second question is the one the invoice chaser needed asked.

Log what it did

Keep a record. A spreadsheet row per run is entirely adequate: timestamp, records in, records out, anything routed to a human.

When something's wrong three weeks later, this is how you find when it started. Without it, you're guessing, and the guess is usually wrong in the expensive direction: you assume the failure is recent, re-check the last few days, and miss the five quiet weeks before that. The log turns "how long has this been happening?" from an estimate you will get wrong into a lookup.

Check it deliberately

Put a recurring fifteen-minute review in the calendar. Monthly is enough for most things. Look at the log, spot-check three outputs against what they should be, confirm the counts look sane.

Fifteen minutes a month is the entire maintenance cost of a reliable automation. It's also the thing that separates people whose automations still work a year later from people who quietly stopped trusting them and went back to doing it by hand.

The pre-flight

Before you turn anything on, five questions:

1. Steps × expected runs, what does that cost?
2. Is the spend cap set?
3. Can this trigger itself?
4. What state is the world in if it stops halfway?
5. How would I know within 24 hours if it broke?

Two minutes. They prevent almost every expensive automation story you've heard.

And if five questions feel like overkill for the thing you are about to switch on, that is information too: it means the automation is small enough to fail safely, which is exactly the size your first one should be.