Who is told when an automation fails? What each tool really does, and how to test it

The question to ask about every automation

For each automation that matters, ask three things. Who is told if it fails? How soon? And would they act? The answers are often found to be nobody, eventually and no. Alerts were set up once, often by default, by someone who has since left or whose mailbox is full. Nothing is wrong with the tool; the alert is simply not designed. The way to find out is to read the settings and then to test by causing a failure.

What each tool documents

The four tools differ. In Airtable the failure email goes to the person who last turned the automation on, and to workspace owners if that person has left; extra subscribers can be added but need Creator permission or higher on the base. In Zapier, when Autoreplay is on, error emails and Zapier Manager triggers wait for the final autoreplay attempt, which is about ten and a half hours after the first error; a custom error handler stops the usual error emails, turns that Zap's autoreplay off, and must send its own alert. In n8n, the documented route to an alert is an error workflow, which starts with the Error Trigger node and is selected in the failing workflow's settings. In Make, the documentation's own example adds a message module, such as Slack, on the scenario's error route. Make also says that an error route does not need a handler and that if no module outputs an error in the route, it skips the error, so a route that only sends a message ends with the error skipped.

• Airtable: last person to enable it, else workspace owners; extra subscribers must be Creator-or-higher collaborators.
• Zapier: delayed by Autoreplay when it is on; standard emails stopped, and autoreplay turned off, by a custom handler.
• n8n: an error workflow that you set up and select.
• Make: a message module on the error route, followed by a directive, or the error is skipped.

Delays and suppressions

Three effects deserve attention because they hide failures or change them. A delay means someone is told hours after the failure, which may be too late for a time-sensitive process. A suppression means a feature you switched on for one reason silently turned off another: a Zapier custom handler stops the standard email and turns that Zap's autoreplay off, so a failure inside the handler is itself silent and failed steps are no longer retried automatically. And a change of behaviour means the alert you added altered what a failure does: in Make, by its own wording an alert-only route skips the error, so a scenario that used to stop and be deactivated now drops the bundle and carries on, and Make says a skip marks the run as successful. Write down, for each automation, what is delayed, what is suppressed and what the failure now does. If a particular failure must be seen within minutes, check that the tool can deliver that, rather than assuming.

A shared place and two named people

An alert addressed to one person is a single point of failure. Send alerts to a shared mailbox or channel that at least two named people read, and agree who acts and who covers. Make the alert name the automation and say where to find the failed run, so that the reader does not have to hunt. Keep the shared place out of anyone's personal rules and filters, and review who reads it when the team changes. Check what each tool lets you address: Airtable only accepts collaborators with Creator permission or higher as subscribers, so a shared mailbox works there only if that address is itself such a collaborator; otherwise add the two named people directly.

• One shared mailbox or channel for all automation alerts.
• A named owner and a named backup, both confirmed.
• The automation's name and a link to the run in the message.

Test by breaking a copy

The only reliable test is a deliberate failure. Make a copy of the automation, point it at a disposable destination and a disposable source, and cause an error in a controlled way, for example by sending a record that lacks a required field. Check who receives what, and when, and whether the message is clear. In Make, also check the run status and whether the scenario still stops or is deactivated as it did before. Do the test on a copy so that no live record or customer is involved. Repeat after any change to the alert route, the plan or the team.

What alerts do not catch

An error alert needs an error. An automation that never triggers, because its trigger was turned off or its connection lapsed quietly, may produce no failure at all. An automation that runs and succeeds with wrong data produces no alert either. Cover those with a different check, such as an expected-by time for a regular output. The paid outcome sets up and proves failure alerts for up to five named automations on one platform, and records what each failure does to the run before and after; it does not detect silent non-triggering, and it makes no response-time promise.