When an Automation Breaks: Alerts, Replays and Who Fixes It

When an automation breaks, three things have to exist already: an alert that reaches a person, a way to replay what failed without doing the work twice, and a named owner who is expected to act. Zapier and Make each give you tools for the first two. Neither sets those tools up for you, and neither can decide who the owner is. This post shows what each platform offers, where silent failures hide, how to make a replay safe and what to agree before a flow goes live.

These are the vendors' own descriptions, in the versions available on or before 9 July 2026.

• Zapier. Its Help Center page on replaying runs (last updated 29 May 2026) says manual replay is available on every plan, and that on the Free plan it works only for runs with an errored status. You can replay only the errored steps, or the entire Zap, which executes “every single step in the Zap, including the trigger and all previous steps, regardless of their run status”. Replaying the entire Zap counts toward task usage even for steps that succeeded before. Autoreplay, which retries failed runs automatically, is available on the Professional, Team and Enterprise plans. Account admins can turn it on for the whole account, and each Zap owner can override it with “Use account setting”, “Always replay” or “Never replay”.
• Make. An error handler is attached to a module through an error handling route, and Make offers five: Ignore, Resume, Commit, Rollback and Break (Help Center page updated 11 May 2026). The route can be as small as one module that sends a Slack message. One detail matters: if no module in the error handling route outputs an error, Make ignores the error, which means a scenario whose only handler is a notification keeps running as if nothing failed. Separately, incomplete executions are disabled by default. When you enable “Store incomplete executions” in the scenario settings, Make keeps the unfinished run in the Incomplete executions tab, where you can let Make retry it automatically for the supported error types, use the Break error handler, resolve it manually or delete it (Help Center page updated 9 June 2026).

Notice the pattern. Both platforms let you keep a failed run and act on it. Neither knows which person should hear about it, or on which channel. That part is configuration, and it is the part that gets skipped.

The loud failure, a red error, is the easy case. The costly ones make no noise.

• A flow that succeeds with wrong data. The run finishes green because every step technically worked, but a field was empty or a lookup matched the wrong customer. Add a check step that stops the run with an explicit error when the data fails a rule, or a filter or router that sends bad data to a review path.
• A flow that stopped running. Nothing failed, because nothing started: a connection expired, a trigger was switched off, a form moved. Count the runs you expect per day or per week, and alert when the count is zero.
• A retry that does the work twice. Replaying the entire Zap repeats the trigger and every step, including steps that already worked. Replaying only the errored steps does not. Before you press replay on a flow that creates invoices, sends messages or charges cards, check which kind of replay you are about to do, or the customer gets two of everything.
• A handler that swallows the error. In Make, a handler route that only sends a notification can end the error without marking the run as failed. Make sure someone reads the notification, and decide whether the run should still end in an error.
• A flow nobody opens. If the only place a failure shows is a dashboard no one visits, it is invisible. Send failures where your team already looks: the shared email inbox, a chat channel, or a WhatsApp message to the owner.

Design the flow so that running a step twice does the same as running it once. Three habits do most of the work:

1. Look before you create. Before a step creates an invoice, a CRM record or an order, search for one with the same reference. If it exists, update it or skip.
2. Carry one unique reference through the whole flow, such as the order number, and store it on everything the flow creates. Without one, duplicates cannot be detected.
3. Record what was done. One row per run in a log sheet or table: the reference, the time and the result. When someone asks “did this go out?”, the log answers.

For flows that move money or send documents to customers, also write down whether a whole-run replay is ever allowed.

1. An alert path. Every flow that matters has an error handler that notifies a named person on a channel they read daily.
2. A replay rule. For each flow, whether replaying the whole run is safe or only the failed steps, and who may press the button.
3. A named owner and a response time. Not “the team”. One person, and what they commit to: the same working day, within an hour, or next week. Israeli business hours run Sunday to Thursday, so say what happens on a Friday.
4. A copy of the flow. Keep the flow definition and a screenshot of each scenario somewhere other than the platform account, so the logic survives a locked account or a person who leaves.
5. A short note on what the flow does. Five lines: what starts it, what it changes, what to check when it fails.

You can own it yourselves, if someone on your team will check alerts and is comfortable editing flows. You can have us own it. Our optional monthly care plan, ₪450 a month for a first automation plus VAT as required by law, covers monitoring, a monthly tuning pass and quality control, so a failed run reaches us and not only a dashboard. Either answer works. A missing answer is the one that fails. The platform decision is covered in what automation platforms really cost, and choosing the first process comes before all of it. The owner you name here should be part of those decisions.

See the automation and integrations service for what a build includes, or book a free intro call and bring one flow you already run. We will tell you where it would fail quietly.

• Replay Zap runs, Zapier Help Center, page updated 29 May 2026.
• Overview of error handling, Make Help Center, page updated 11 May 2026, as captured by Common Crawl on 12 May 2026.
• Incomplete executions, Make Help Center, page updated 9 June 2026, as captured by Common Crawl on 10 June 2026.