Automation stopped working? Set up error alerts first

The worst automation failure is the one nobody hears about. A lead form stops reaching your CRM, a follow-up email stops going out, or a nightly sync quits after a password change. Nothing crashes on your screen. You find out weeks later when a client asks why nobody called back.

This guide is for owners and operations leads who run a few automations in n8n, Zapier or Make and want to know the moment one breaks. We read n8n's error handling docs, Zapier's help page on error notifications and its Zapier Manager troubleshooting page, and Make's scenario settings on October 26, 2026. What we say about each tool comes from those pages.

Most of the failures we get asked about fall into a few groups:

1. 1A login expired or changed. Someone resets a password or a connected app revokes access, and every run after that fails.
2. 2An app changed what it sends. A form tool renames a field, and the step that reads it gets nothing.
3. 3The trigger stopped firing. The workflow is fine, but nothing starts it, so there are no errors to report at all.
4. 4The tool turned the workflow off. Make lets you set how many errors in a row it accepts before it deactivates a scenario. If the scenario starts with an instant trigger, such as a webhook, Make ignores that setting and deactivates it after the first error.
5. 5The alert went to the wrong person. On Zapier Team and Enterprise plans, error notifications go to the user who created the Zap that failed. If that person left, the alerts go to an inbox nobody reads.

Groups 1, 2 and 4 produce errors, so the fix is making sure the right person sees them fast. Group 3 produces nothing, so it needs a different check, which we cover below.

n8n lets each workflow name an error workflow in its settings. When a run fails, n8n starts that error workflow and hands it the details. The error workflow has to begin with the Error Trigger node, and one error workflow can serve many workflows. That means you build the alert once and point every important workflow at it.

The details n8n passes include the execution id and a link to it, the error message, the last node that ran, and the workflow name. That is enough for an alert that names the broken workflow and the failed step, with a link to the run. If the failure happens in the trigger node itself, n8n sends a slightly different set of details, so test both cases.

n8n also has a Stop And Error node. You add it where a run should count as a failure even though no step broke, for example when a lead search returns zero results on a day it never should. That turns a quiet run into one that sets off your alert.

Zapier emails your account address when a Zap errors, and the default is to send each error right away. In the notification settings you can switch to an hourly summary or turn alerts off. Zapier labels "Never" as not recommended, and we agree. You can also set a different rule for chosen Zaps or folders, which helps when one Zap matters far more than the rest.

If you want errors to land in Slack or a shared channel, Zapier Manager has triggers for a new Zap error and for a Zap being turned off. Two details from Zapier's troubleshooting page are worth knowing. These triggers only run after all autoreplay attempts are done, so alerts can arrive late if autoreplay is on. And they do not fire if your default notification frequency is set to Never.

Make has two settings that change how a failure looks. "Errors before deactivation" decides how many failures in a row turn a scenario off. "Store incomplete executions" keeps a failed run in a folder so you can fix the problem and continue it later. Make's page also notes that if that folder fills up and "Discard data if storage is full" is on, failed data is dropped and cannot be recovered. If losing a lead or an order is not acceptable, check those two settings on every scenario that handles one.

Error alerts only fire when something errors. A workflow whose trigger has stopped, or that runs every day but finds nothing, will never send one. The check for this is simple. Once a day, count what each important workflow did, such as leads added, emails sent or records synced. If a number is zero on a day it should not be, send an alert. A person reading one short daily message notices a zero much faster than they notice an absence.

These are the setups we would build for a small business with a handful of automations:

• One shared error alert. Every workflow that touches customers points to a single error workflow or Zapier Manager Zap. It posts to one channel your team reads, such as Slack, Teams, email or WhatsApp, with the workflow name, the error and a link to the failed run.
• A daily count message. One short message each morning with yesterday's numbers per workflow. Zeros get flagged.
• A named owner per workflow. Each important automation has one person who gets its alerts. When that person leaves, reassigning alerts is part of their offboarding.
• A forced test. After setup, break each workflow on purpose, for example with a bad value, and confirm the alert arrives where you expect.
• A login list. A short list of every connected account, who owns it, and when its access needs renewing.

If you also run AI agents, the same idea applies, plus checks on what the agent produced. Our guide to testing AI agents before production covers that side.

• Too many alerts. If one broken workflow sends fifty emails an hour, people mute the channel. Use a summary setting or group repeat errors.
• Customer data in alerts. Error messages can include parts of the record that failed. Send alerts to a private channel, and keep personal or health data out of the message text.
• Retries that hide problems. Automatic retries are useful, but they delay alerts. Make sure a run that fails every retry still alerts someone.
• Turning off logs. Make's "keep data confidential" setting stops it storing run data. That protects sensitive data, but Make warns it leaves very limited options for fixing errors. Decide per workflow.

If an automation is low stakes, like a weekly report you open anyway, a broken run shows itself. Building alerts for it adds noise. The same goes for something you run by hand once a month. Spend the effort on workflows where a quiet failure costs you a client, a payment or a deadline.

If you have more than a few critical workflows and nobody has time to watch alerts, that is a maintenance question more than a setup question. Our post on what automation maintenance really costs walks through those options.

List every automation you have, who owns it, and what would happen if it stopped for a week without anyone noticing. Pick the three where that answer is worst, and set up error alerts and a daily count for those first. Then break each one on purpose and confirm the alert reaches a person.

If you want help, our free automation audit reviews the automations you already run and tells you which ones could fail quietly and what we would set up to catch it. You can also see what our workflow automation and systems integration work includes.