Blog / Small Business Automation

Who Fixes the Automation When It Breaks? Plan Maintenance Before You Build

By Keyona Meeks, Founder, ReRev Labs · Oct 31, 2026 · 8 min read

The short answer: An automation that nobody owns will fail quietly, and you will find out from a customer. Before you build, decide four things: a named owner, a way to be told when it fails, a log that shows what it did, and a short handover document. Add a monthly check and a plan for the day the builder is unavailable. None of this is exotic. It is the part most projects skip. We sell build work, so I have a stake here, and the checklist below applies to work anyone builds.

By the end of this post, you'll be able to:

• Explain why automations break.
• Set up an owner, an alert, a log and a handover note.
• Run a short monthly check.
• Ask a builder the right questions about support.

We sell build work, and I want that said up front. I also want to be plain about it: everything we build can break, and so can everything anyone else builds.

Why do automations break?

Not because the builder was careless. Because the world around them changes. These are the common causes, from my own experience of how this kind of work goes, not from a study:

• A login or permission changes. A password is reset, a person leaves, an approval expires.
• A field or tab is renamed. The automation looks for a column that no longer exists.
• The input changes shape. A form gets a new question. A supplier changes the format of an email.
• A limit is reached. Volume grows past a quota.
• A tool changes. A vendor changes how a feature works.

Google, for one, says its quotas can change. The quotas page says "All quotas are subject to elimination, reduction, or change at any time, without notice," per an earlier review. Check the live page. Any tool you depend on can do something similar.

Who should own it?

One named person, on the day it launches. Not a team and not "IT". The owner does not have to fix it. They have to know it exists, hear when it fails and decide who fixes it.

Write down the owner's name, and a backup. If the owner leaves, the first task is to name a new one.

A related point: whose account does it run in? Google's documentation on installable triggers says they "always run under the account of the person who created them," per an earlier review. If a freelancer set it up in their account, it runs as them. Check where your automation lives and have it in an account the company owns.

How will you know when it fails?

A good automation fails loudly. Decide in advance:

• Who is told. The owner and the backup.
• How. An email, a message in a channel, a row in a sheet that turns red. Pick the one the owner actually reads.
• What the message says. Which automation, what it was doing and when. "Something went wrong" is not enough.
• What counts as a failure. An error is one kind. A job that did not run at all is another, and it is easy to miss.

The second kind is the dangerous one. An automation that stops running sends no error. Ask for a check that notices when an expected run did not happen, for example a "last ran" date that the owner glances at each week.

What should the log hold?

A log is a record of what the automation did. It can be a tab in a sheet. Each row should have:

• The date and time.
• What triggered it.
• What it did, in plain words.
• Whether it worked.
• An identifier you can search for, such as an order number.

When something goes wrong, the first question is "what did it do?" A log answers it in a minute. Without one, someone reads code or guesses. A log can also hold personal data, so decide who can see it and how long to keep it. Ask your attorney if it holds regulated data.

What goes in the handover document?

One page, written for someone who has never seen it. Use the same plain style as the one-pager idea. It should say:

1. What it does, in three sentences.
2. Where it lives: which accounts, which files.
3. What it connects to.
4. Where the settings are and what each one means.
5. How to tell it is working.
6. What to do when it stops: first checks, who to call.
7. Who built it and how to reach them.

If the builder cannot write this, ask why. Often the answer is that it is not finished.

What does a monthly check look like?

Ten minutes. Put it on the calendar of the owner.

1. Open the log. Does it show runs in the last week?
2. Pick three entries and confirm the results are right.
3. Check the alert still reaches the right people. Send a test.
4. Check logins, permissions and any expiring access.
5. Note any quota or limit you are close to.
6. Ask the people who rely on it whether anything felt off.
7. Write the date and the result in the log.

What if the builder is not available?

Plan for it. Ask these before you sign:

• Who else can read this? If the answer is nobody, you are depending on one person.
• Is the work in our accounts? If the builder holds the keys, you cannot leave.
• Is there a support option? What does it include, and what does it cost? Get it in writing.
• How fast do they respond? Ask for a number you can hold them to.

For why automation projects fail more generally, see why AI agents fail, and for the difference between an agent and plain automation, see AI agents vs automation.

Where does an LLM fit in this?

An LLM can help with the messy part: reading a long error message or a log and suggesting what it means, or turning your notes into a first draft of the handover page. A person should check both, because an LLM can describe a cause with confidence and be wrong. The alert, the log and the monthly check are plain rules, and they do the same thing every time. My stance: AI writes the code, plain automation runs it, and an LLM shows up only where the input is messy and a person checks the result.

Where this has limits

• This is my checklist. It comes from how I think about this work, not from research or a standard.
• The causes of failure are from my own experience. I have no statistics on how often each happens.
• The Google lines are from an earlier review. Check the live pages.
• Regulated data needs more. Ask your attorney or other professional what you must keep and protect.
• We sell build work. Read this with that in mind.
• No ReRev prices and no promises about results.

If you want help building something with an owner, an alert, a log and a handover note included, tell us what you need. Do not send passwords or login details.

Frequently asked questions

Why do automations stop working?

Usually because something around them changed: a login, a field name, an input format, a limit or a tool.

Who should own an automation?

One named person, plus a backup.

How do I know when an automation fails?

Set up an alert that names the automation and the problem, and a check that notices when an expected run did not happen.

What is a handover document?

A one-page description of what the automation does, where it lives, how to tell it works and what to do when it stops.

How often should I check an automation?

I suggest a ten-minute check each month. Adjust it to how important the work is.

What if the builder leaves?

If the work lives in your accounts and the handover note is current, someone else can pick it up.

Read next: Questions to ask before you hire automation help includes the maintenance question this post says to ask first.