How Do I Keep My Automations From Breaking?

How do you keep your automations from breaking? You accept that they will break, then design so that breakage is loud, small, and fixable in ten minutes. Every automation you own needs four things: a clear owner, an error notification that reaches a human, a retry or error path for the failures that are just bad luck, and a monthly review that catches the slow rot (expired logins, changed field names, plans that ran out of capacity). Automations do not fail because automation is unreliable. They fail because nobody was watching, and by the time someone noticed, three weeks of leads had gone into a hole.

This is the maintenance post. It covers why things break, how to be told first, what to build into every workflow, what is different about AI steps, and the monthly routine that keeps a small stack healthy.

Why Do Automations Break in the First Place?

Almost never because the logic was wrong. They break because something outside the automation changed: a password, a permission, a field name, a plan limit, or a person. The logic you tested is usually still fine, which is why the failures feel so unfair.

The realistic failure list, roughly in order of frequency:

• Expired or revoked connections. Someone changed a password, turned on two-factor authentication, or an app's token expired on its own. This is the single most common cause, and it is silent.
• The person left. The automation was connected under an employee's account. Their login was deactivated, and with it went every workflow they authorized.
• A field changed. Someone renamed a spreadsheet column, added a required field to a form, or reordered a CRM dropdown. The automation looks for a name that no longer exists.
• Capacity ran out. Task or credit limits, an email sending cap, an API rate limit, or a free plan that hit its ceiling mid-month. Make, for example, counts each module action in a scenario as one credit against your monthly allowance, so a busy season quietly costs more than a slow one.
• The vendor changed something. An API version was retired, a webhook format changed, or a login flow moved.
• Bad input. A customer typed their phone number with letters in it, uploaded a 40 megabyte photo, or submitted the form twice.
• Duplicates and loops. Two automations watching the same trigger, or one that updates a record and then fires on its own update.

There is a bigger point underneath this. When MIT studied generative AI adoption in 2025, the failure cause was not model quality but the integration and learning gap, as Fortune reported in August 2025. The same is true one level down: the thing that decides whether your automation delivers value is not how clever it is, it is whether the connection to your real business survives contact with a normal month.

How Do I Find Out Before My Customers Do?

Turn on error notifications, send them somewhere a human actually looks, and add a heartbeat check for the automations that are supposed to run on a schedule. Most platforms will email you on failure, but the default settings assume you read that inbox.

Error Alerts

1. Turn on the platform's own error emails, and point them at a shared address such as alerts@yourbusiness.com that at least two people see. An alert sent to one person on vacation is not an alert.
2. Route critical failures to text or a chat channel. Anything touching money, bookings, or lead capture deserves an interruption. Everything else can wait for the daily digest.
3. Give every automation a name that tells you what broke. "Website form to CRM plus text to owner" beats "Zap 14." When five alerts arrive at once, the names are what let you triage.

The Heartbeat Check

Scheduled automations have a nastier failure mode than triggered ones: they can stop running entirely, and silence looks exactly like success. The fix is a heartbeat. Have the automation write a timestamp to a spreadsheet or send a one-line message every time it completes, then create a second, dead-simple automation that checks daily whether that timestamp is fresh and alerts you if it is not. It takes fifteen minutes to build and it is the difference between finding out today and finding out at month end.

What Should Every Automation Have Built In?

Six things, and they take about twenty extra minutes per workflow. That twenty minutes is the cheapest insurance in your business.

1. An owner and a one-paragraph description. Written in the automation's own notes field or a shared document: what it does, what triggers it, which accounts it uses, and what to do if it stops. Name a person.
2. An error path, not just a hope. In Zapier, use the advanced error settings to decide how a Zap should behave when a step fails, and turn on Autoreplay where it is available. Zapier's documentation describes Autoreplay retrying a failed step up to five times with an increasing back-off (five minutes, thirty minutes, one hour, three hours, then six hours), which quietly resolves most temporary outages before you ever see them. In Make, attach an error handler route to the module that can fail and tell the scenario explicitly what to do next, whether that is retrying later, continuing with a substitute value, or stopping cleanly.
3. A fallback that reaches a human. If the automation cannot complete, someone should still get the information. A failed CRM write should still send the lead's name and number to a text message. Losing the automation is annoying. Losing the customer is not acceptable.
4. Duplicate protection. Filter on a unique value (email address, booking number, invoice ID) and check whether the record already exists before creating another. Double submissions are normal human behavior, not an edge case.
5. Input validation early. Add a filter step near the top that stops the run when required fields are empty or malformed. Failing at step two with a clear reason is much easier to diagnose than failing at step nine.
6. A log you can read. Append one row to a spreadsheet per run: timestamp, what came in, what happened, success or failure. Platform histories are limited by plan and get pruned. Your own log costs nothing and answers the question "did this actually run on the fourteenth."

If you are still deciding which platform to build on, our comparison of Zapier, Make, and n8n for small businesses covers how each handles errors, history, and pricing, which matters more for maintenance than the feature lists suggest.

What Breaks Specifically With AI Steps?

AI steps fail differently: they rarely error out, they just return something you did not expect and the automation happily carries it downstream. A broken connection is loud. A confidently wrong AI step is silent, which makes it more dangerous.

The specific failure modes and what to do about them:

• Format drift. You asked for JSON, and one day you get JSON wrapped in a friendly sentence. Fix: demand a strict output format in the prompt, use the platform's structured output option if it has one, and add a step that validates the shape before anything writes to a real system.
• Invented details. The summarizer adds a price nobody quoted or a date nobody agreed to. Fix: instruct it to use only supplied information and to write "not provided" when a field is missing, then never let AI output reach a customer without a human read on anything involving money, dates, or commitments.
• Length and truncation. A long email thread exceeds the limit and the step silently processes only part of it. Fix: cap the input, and check the length before sending.
• Model deprecation. The specific model version in your step gets retired. Fix: note which model each automation uses in your inventory, and retest that workflow when you change models, because the same prompt does not always behave the same way.
• Rate limits and cost spikes. A busy week or a loop can multiply calls fast. Fix: set usage alerts on the account, and check your first full month of spend against your estimate.
• Prompt edits nobody recorded. Someone tweaks the prompt to fix one output and breaks four others. Fix: keep prompts in a document with dates, change one thing at a time, and run five known examples after every edit.

The NIST AI Risk Management Framework calls this ongoing work the manage function, the part that comes after deployment and never ends. For a small business the honest version is a recurring calendar entry and five test cases you keep in a spreadsheet.

What Does a Monthly Maintenance Routine Look Like?

Thirty minutes, same day every month, one checklist. If you have more than a handful of automations, this is not optional.

1. Open the error history on every platform and read every failure from the past month, including the ones that resolved themselves. Repeat failures are a design problem, not bad luck.
2. Check every connection. Most platforms show a warning icon for expiring or broken authorizations. Reconnect anything flagged, and confirm each one uses the business operations account.
3. Check usage against your plan. Tasks, credits, operations, emails, and API spend. Note whether the busy season will push you over.
4. Run one live end-to-end test per critical workflow. Submit a real test lead. Book a test appointment and then cancel it. Do not trust the history view; trust the text message that arrives on your phone.
5. Verify the heartbeats. Confirm every scheduled automation actually reported in this month.
6. Review the inventory. One row per automation: name, what it does, owner, accounts used, last tested date. Delete anything nobody uses, because a dormant automation is still a live connection to your data.
7. Check the humans. Anyone who left keeps an account somewhere. Remove them, and reassign anything they owned.

What Does This Look Like for a Business Here?

Picture a vacation rental host in Fontana with four properties, a cleaning crew, and eleven automations built over two years: booking to cleaning schedule, booking to a welcome email sequence, a door-code generator, a mid-stay check-in text, a review request, an owner statement summary, and a few smaller ones.

In July, three things went wrong in the same week. The door-code automation stopped because the lock vendor changed an API version. The review requests kept sending to guests who had already left a review, because a duplicate filter was never added. And the cleaning schedule failed silently on Saturdays, because the calendar connection had been authorized under a former assistant's account and was deactivated with her.

The repair took an afternoon and looked like this:

• Every integration was reconnected under one operations account owned by the host.
• Each of the eleven automations got a plain-English name, a one-paragraph description, and a named owner.
• Failure alerts were routed to a shared address, with texts for anything touching bookings, codes, or payments.
• The cleaning-schedule automation writes a timestamp after each run, and a small daily check texts the host if the timestamp is more than 26 hours old.
• The review request now checks for an existing review and stops if it finds one, and every automation writes a log row to a single spreadsheet.
• A recurring 30 minute maintenance block sits on the calendar for the first Monday of every month.

Nothing about that list is clever. It is bookkeeping for robots, and it is the reason the next vendor change will cost twenty minutes instead of a week of guest complaints. If the connections themselves are your sticking point, our guide on connecting tools that do not talk to each other covers the options before you build.

Do This This Week

1. Make a list of every automation you have, in every tool, including the ones you forgot about. This inventory is the whole foundation.
2. Create a shared operations account for the business and start moving integrations onto it, highest-value workflow first.
3. Turn on error notifications everywhere and point them at an address at least two people read.
4. Add texts or chat alerts for the failures that touch money, bookings, or leads.
5. Add a duplicate filter and a human fallback to your single most important automation.
6. Build one heartbeat check for a scheduled automation you would not notice going quiet.
7. Run a live end-to-end test of your lead capture path, from the public form to the message on your phone.
8. Put a recurring 30 minute monthly maintenance block on the calendar and hold it like a client meeting.

Where to Go From Here

The goal is not automations that never break. It is a system where breakage is visible within a day, contained to one workflow, and repairable by someone other than the person who built it. Owner, alert, error path, fallback, log, and a monthly half hour. That is the entire discipline, and it is what separates a stack you trust from a pile of clever things you are quietly afraid of.

If your automations were built by different people at different times and nobody can say what is running anymore, that is the normal starting point, not a confession. Our AI automation work for Lake Geneva small businesses begins by mapping and documenting what already exists before touching anything, and the free Local Visibility Audit on our homepage is a good first step if what is actually broken is that customers are not finding you at all.

Sources and Further Reading

1. Replay failed Zap runs. Zapier, 2026.
2. Decide how your Zap handles errors with advanced settings. Zapier, 2026.
3. How to troubleshoot errors in Zap workflows. Zapier, 2026.
4. Error handling | Custom Apps Documentation. Make Developer Hub, 2026.
5. Pricing & Subscription Packages | Make. Make, August 2026.
6. AI Risk Management Framework. National Institute of Standards and Technology, 2026.
7. MIT report: 95% of generative AI pilots at companies are failing. Fortune, August 2025.