What Happens When Automation Breaks? Building Failsafes Into Your Workflows

The first automation I ever lost properly failed for eleven days before anybody noticed. A website enquiry form was posting leads into a CRM through a connection whose login token had quietly expired, and every one of those enquiries disappeared into nothing. That's the thing about automation breaking. It rarely goes bang. It goes silent.

Here's the short answer to the question in the title. When automation breaks, one of three things happens: it stops and tells you, it stops and doesn't tell you, or it keeps going and does the wrong thing. Only the first is acceptable, and none of the tools you'll buy give it to you by default. Every workflow you depend on needs three failsafes: a way to alert a human when it fails, a way to retry the temporary failures on its own, and a holding pen where the awkward cases wait for someone to look at them. Build those three and most of the horror stories in this article don't happen to you. The rest of this piece is about how to build them without a technical background, what it costs on the tools UK small businesses actually use, and where UK law now insists a person stays in the loop.

Silent Failure Is the Real Enemy

I've been building and repairing workflows for small firms for years, and I can count on one hand the number of times a failure announced itself. Usually a login expires overnight, an app changes the shape of the data it sends, or someone renames a spreadsheet column while tidying up. Nothing crashes. The automation simply stops producing results, and because it used to be reliable, nobody is checking.

The numbers on this are uncomfortable. According to Workato's State of Business Automation report, as cited in TinyCommand's guide to workflow automation challenges, 60 percent of automation failures go undetected for more than 24 hours. That's a US report about a mostly American customer base, but I've seen nothing in UK businesses to suggest the figure is any better here. Smaller firms with no technical person tend to notice later, not sooner.

The same guide calls it the midnight failure problem. A token expires at two in the morning, the refresh fails, everything downstream dies, and you find out at nine when someone asks why the morning report is empty. What matters isn't that the failure happened. It's that eight hours of orders, enquiries or bookings went somewhere you can't see. That's why the first failsafe is always visibility.

What Breaking Actually Costs a Small Firm

A broken automation feels minor next to a full IT outage, but the cost sits in the same place: lost work, lost custom and lost trust. Red Eagle Technology's analysis of IT downtime costs in the UK puts the national figure at around £3.7 billion a year, drawing on Beaming's 2023 research, and estimates that small and medium sized businesses lose somewhere between £137 and £450 per minute of outage. Twin Technology, a Watford managed IT provider, suggests UK SMEs typically suffer between 12 and 30 hours of unplanned downtime a year and lose roughly £3,000 to £5,000 for each hour.

Those numbers are for whole systems going down, so treat them as an upper bound for a single broken workflow. But an automation that quietly drops enquiries isn't really cheaper. It's just harder to measure, because you never find out which customers you lost.

The reputational side is the part I'd worry about most. A June 2026 survey by TalkTalk Business, reported by Just Technology Group's piece on the cost of downtime for small businesses, found that 70 percent of UK consumers would tolerate no more than 24 hours of disruption following a major IT failure, and 75 percent said they'd reduce or stop using a company's services after a significant incident. A customer who fills in your booking form and hears nothing back doesn't know your Zap broke. They think you ignored them.

The Three Failsafes Every Workflow Needs

I use the same model with every client, whether they're a two person plumbing firm or a fifteen person accountancy practice. It has three parts, built in this order.

The first is alerting. The workflow must send a message to a human when it fails, and that message must land somewhere someone reads daily. An inbox that gets 200 messages a day doesn't count.

The second is retrying. A large share of failures are temporary: an app's servers are briefly overloaded, a connection times out, or you hit a rate limit by sending too many requests at once. These fix themselves if you try again a few minutes later, so your workflow should do that automatically before it bothers a person.

The third is a holding pen. When a retry doesn't fix it, the failed item shouldn't vanish and it shouldn't be forced through anyway. It should go somewhere safe, a spreadsheet, a queue, a task in your project board, where a human can look at it and decide. The engineering term for this is a dead letter queue, which just means a parking bay for things that couldn't be processed. As the error handling guide from CodeWords puts it, good error handling retries transient failures, surfaces permanent ones to a human, and never silently loses data. That's the whole philosophy in one sentence.

How to Set Up Failsafes in Zapier

Zapier is where most UK small businesses start, so I'll cover it first. It's also the tool people most often assume is protecting them when it isn't.

Out of the box, a Zap that errors simply stops that run and marks it in your Zap history. According to Zapier's own troubleshooting documentation, a Zap will turn itself off automatically if 95 percent of its runs have errored over the previous seven days. That sounds sensible until you realise what it means: if your CRM connection breaks on a Friday evening, by the following weekend the Zap has switched itself off entirely, and the only thing between you and a permanent loss is whether you noticed the emails.

The first setting to change is Autoreplay. Zapier's documentation on replaying Zap runs explains that when Autoreplay is enabled, Zapier automatically replays any run with an errored status on a defined schedule, across your whole account. The catch is that Autoreplay is only available on Professional plans and above, it's an account level switch that only an owner or super admin can turn on, and it isn't on by default. I've lost count of the businesses paying for a plan that includes it who've never flipped the toggle.

The second, and more powerful, option is custom error handling. Zapier lets you add an error handler path to a step, which is a separate branch of actions that runs when that step fails. This is where you build the holding pen: on error, add a row to a Google Sheet with the details, then post a message to your alerts channel. Zapier's guide to setting up custom error handling lists some important rules. A Zap can have up to 100 steps including the handler path. Once you publish a Zap with an error handler, Autoreplay turns off for that specific Zap, and Zapier will no longer send its usual error notification emails when the handler runs. The moment you take control of errors, Zapier stops babysitting, so your handler had better include the alert.

There's a third piece most people never find. Zapier's built in Zapier Manager app can trigger a Zap when any other Zap in your account errors or gets turned off. I build one for every client: it watches the whole account and posts to a single channel whenever anything fails. It's the closest thing Zapier has to a heartbeat monitor.

On price, the ExpertSure UK review of Zapier lists the free plan at 100 tasks a month with two step Zaps only, and Professional from about £16 a month billed annually for 750 tasks. Zapier bills in US dollars, so its pound figures here are approximations. A task is one action step completing, so an error handler that logs to a sheet and posts an alert uses tasks too. Cheap insurance, but not free.

How to Set Up Failsafes in Make

Make, which many people still call Integromat, gives you far more control over what happens when a module fails, and it's my preferred tool for anything that touches money or customer records. The extra control means more decisions to make.

Make's quick reference to its error handling directives describes five handlers you can attach to any module: Break, Resume, Ignore, Commit and Rollback. In plain terms, Break pauses the failed item and stores it as an incomplete execution so it can be retried or fixed. Resume lets you supply substitute data so the workflow carries on with a fallback value. Ignore drops the failed item and continues with the rest. Commit stops the run but keeps the changes already made. Rollback stops the run and tries to undo the changes in any modules that support it.

If you take one thing from this section, take Break. It gives you a proper retry with backoff, with a configurable number of attempts and interval. The German automation consultant Till Freitag, in his guide to Make error handling and retry strategies, recommends a Break handler with three attempts at 15 minute intervals for the errors that typically resolve themselves, such as rate limits, timeouts and server errors, with storing of incomplete executions switched on. I use exactly that as a starting point.

Two scenario settings matter as much as the handlers. Turn on Allow storing of incomplete executions, because without it a failed bundle is simply lost. And check the Number of consecutive errors setting, which defaults to three. Once a scenario hits that many failures in a row, Make deactivates it. Like Zapier's 95 percent rule, that means a broken connection can quietly switch your automation off, and you need an alert that fires when it does.

One warning about Rollback, because I've watched people rely on it for something it can't do. It only reverts changes in modules that support transactions, which in practice means a handful of database style apps. It cannot unsend an email or recall an invoice. If a step has already sent something into the world, no handler will take it back, so put the irreversible action last.

Make's pricing works on operations rather than tasks, where every module that runs counts as one. Softomate Solutions' comparison of Make, Zapier and n8n for UK businesses puts the Core plan at roughly £9 a month for 10,000 operations, Standard at about £29 for 40,000 and Team at around £69 for 150,000. Make doesn't bill in pounds either, so treat those as approximations.

How to Set Up Failsafes in n8n

n8n is the option for businesses with somebody technical on the team, or an agency running it for them. It's open source and can be self hosted, which is why UK firms in regulated sectors are drawn to it: the data never leaves a server you control. Its error handling is the most complete of the three, provided you're comfortable with it.

n8n has two layers of error handling, and you want both. At the node level, each step has a Retry on Fail setting for the number of tries and the wait between them, and an On Error setting that decides whether the workflow stops or continues down a separate error output. At the workflow level, n8n's documentation on handling errors gracefully describes the Error Trigger node. You create a separate workflow that starts with an Error Trigger, then in any production workflow's settings you select it as the Error Workflow. Whenever that workflow fails, n8n runs your error workflow with the details of what broke, which node it broke on and a link to the failed execution.

That error workflow is where I put the alert and the holding pen: post the error to a channel, write the failed item to a table or sheet, and if it's a payment or a booking, send a text. A Stop And Error node lets you deliberately fail a workflow when your own business logic says something isn't right, such as an order with no email address, so it lands in the same error handling rather than being pushed through.

One gotcha from the documentation: the Error Trigger only fires when an automated run fails, so you can't test it by running the main workflow manually. Activate the workflow, deliberately break something small, and check the alert arrives.

On cost, Hand On Web's breakdown of n8n pricing for UK businesses puts n8n Cloud at roughly £16 to £95 a month depending on plan, billed in dollars, and self hosting on a small virtual server at around £5 a month plus your own setup time. Softomate's estimate for a self hosted server is higher at £15 to £25. Either way, the real expense is the person who keeps it running, and if that's you and you're not technical, I'd steer you back to Make.

Retries, Backoff and the Idempotency Problem

Retrying sounds harmless, and mostly it is. But there's a trap in it that catches almost everyone eventually.

The safe pattern is exponential backoff, which just means waiting longer between each attempt. The CodeWords guide describes the classic sequence of one second, then two, then four, then eight, capped at a maximum number of attempts. If an app is overloaded, hammering it every second makes things worse, whereas spacing attempts out gives it room to recover. Zapier's Autoreplay and Make's Break handler both space retries for you, so you rarely need the exact numbers.

The trap is duplication. A workflow creates an invoice in your accounting software and then emails the customer. The invoice step succeeds, the email times out, and your retry runs the whole thing again. Now the customer has two invoices. Elysiate's guide to error handling patterns for automations describes this as the difference between duplicate deliveries, which are normal, and unsafe side effects, which are not. The fix has a name, idempotency, which means a workflow can safely receive the same event or retry the same action without creating duplicate records, repeated emails or double charges.

For a non technical owner, idempotency comes down to two habits. First, before any step that creates something, add a search step that checks whether it already exists, and skip creation if it does. Second, put the irreversible step last. If the email is the last thing that happens, a retry of everything before it is safe.

The Holding Pen: Where Awkward Cases Go

The failsafe that most clearly separates a professional setup from an amateur one is the holding pen. Every workflow of mine has one, usually nothing more sophisticated than a Google Sheet or an Airtable table with columns for the date, the workflow name, the error message and the original data.

The point is that when a customer rings on Tuesday about the enquiry they sent on Saturday, you can find it in thirty seconds, see why it failed, and fix it by hand. Without the holding pen, that enquiry is gone, and you're apologising for something you can't explain.

The CodeWords guide also recommends fallback and degradation: if the primary destination is unavailable, write the data somewhere simpler and reconcile later. Can't reach the CRM? Put the lead in a sheet and tidy up when the CRM is back. In Make this is exactly what the Resume handler is for. In Zapier, it's an error handler path with a Google Sheets step. In n8n, it's the error output of the node feeding a spreadsheet node.

Whatever you use, someone has to own it. Elysiate's guide makes the point that error handling is really an ownership design problem. If nobody looks at the holding pen every morning, it becomes a second place where data goes to die. In a business of under ten people, that's the owner's job. It takes two minutes.

Alerts That People Actually Read

I've built alerting that was technically perfect and completely useless, because every alert went to an inbox that filled up with a hundred other things. The alert has to go where the person already looks.

For most small firms that means a dedicated Slack or Teams channel with notifications on. For anything involving payments, bookings or legal deadlines, I add a text to the owner. One text a month is fine. Ten a day is not, and that's the second failure mode: alert fatigue.

The Elysiate guide describes it well: if every hiccup pages the same people, they stop reading, and if important failures go nowhere, the workflow is unsafe. So grade your alerts. Temporary failures that retries will handle should only be logged. Only a failure that has exhausted its retries and landed in the holding pen should ping a human, and the alert should say what broke, on which workflow, for which customer, with a link to the failed run.

The one alert that must always fire is the one that says a workflow has been switched off. Zapier's 95 percent rule and Make's consecutive error limit both turn automations off for your protection, and a paused workflow generates no errors at all. It's silent by design. If you build nothing else from this article, build that alert.

Where UK Law Says a Human Has to Stay In

One category of failsafe isn't about resilience at all. It's about the law, and the rules changed this year.

On 5 February 2026, section 80 of the Data (Use and Access) Act 2025 came into force, replacing Article 22 of the UK GDPR with new Articles 22A to 22D. The old position was close to a ban on making decisions about people by purely automated means where those decisions had legal or similarly significant effects. The new position, as the ICO's summary of what the Act means for organisations explains, opens up the full range of lawful bases for that kind of automated decision making, including legitimate interests, so long as appropriate safeguards are in place. Special category data, such as health information, stays more protected.

The Information Commissioner's Office, the UK data protection regulator, published draft guidance on automated decision making and profiling on 31 March 2026, with the consultation closing on 29 May. As the law firm Stevens & Bolton notes in its summary, the ICO is clear that token human oversight won't do. To count as meaningful human involvement, the person has to have real authority, understand the basis of the automated output, and be able to challenge or override it. Rubber stamping an algorithm's recommendation doesn't meet the bar. Check the ICO's website for the final version, which was expected over the summer.

For a small business the practical question is simple. Does any of your automation make a decision about a person that significantly affects them, without a human looking? Automatically rejecting a job applicant, declining a customer for credit or cancelling someone's service would qualify. Sorting enquiries into a spreadsheet or sending a booking confirmation would not. If you have something in the first category, the failsafe you need is a human review step, a way for the person to ask for it, and a record of the logic. That review step is also exactly where a broken automation gets caught before it does harm.

The Mistakes I See Most Often

The first is the single giant workflow. Miguel Carlos Arao, who runs the Zapier partner agency Alltomate, argues in his piece on common workflow automation mistakes that anything touching more than two systems or with more than one real decision point should be split into smaller isolated workflows, because each stage can then be monitored, retried and debugged on its own. A forty step scenario that fails on step 31 leaves you guessing what already happened in the first thirty.

The second is nobody reviewing business rules. Arao suggests a quarterly review of output accuracy for high volume workflows, and a review whenever the rules inside them change. Put bluntly, the automation you set up in January encodes January's prices, team and approval limits, and it will keep applying them in November unless someone tells it otherwise.

The third is mistaking the platform's default protections for error handling. The defaults exist to stop a broken workflow burning through your task allowance, not to protect your data. They switch things off, and switching off is the opposite of what you want on the morning a customer's order fails.

The fourth is overreach. If a workflow touches money, depends on three apps and only runs a few times a week, a person doing it by hand for twenty minutes on a Friday is often safer and cheaper than the failsafes needed to make the automation trustworthy. I say that as someone who sells automation.

A Failsafe Checklist You Can Do This Week

If you already have automations running, here's what I'd do over the next few days.

Monday, list every automation you have and note what happens if each one fails silently for a week. Anything involving enquiries, orders, payments or bookings goes to the top.

Tuesday, for each of those top items, find the alert. On Zapier, check whether Autoreplay is on and build a Zapier Manager Zap that posts to a channel when anything errors or turns off. On Make, check that incomplete executions are being stored and add a Break handler with three attempts at 15 minutes. On n8n, create an error workflow and assign it to every production workflow.

Wednesday, build the holding pen. One sheet or table you'll actually open, fed by the error path of every important workflow.

Thursday, break something on purpose. Rename a column, disconnect an app, or feed in a record with a missing field. If you don't get an alert and the record doesn't land in the holding pen, you're not done.

Friday, decide who checks the holding pen and put it in their calendar. Then check whether any workflow makes decisions about people without a human, and if so, add the review step before the ICO asks you to.

None of this is glamorous, and none of it will feature in a demo of the latest AI tool. But it's the difference between automation you can trust while you're on holiday and automation that's quietly losing you customers while you sleep. Building failsafes into your workflows isn't an advanced topic for developers. It's the basic hygiene that makes the rest of automation worth doing.