Why automations break, and the ones nobody notices

Everybody who is nervous about automation is nervous about the same thing: that it will break. Which it will. Everything that depends on somebody else’s software eventually does.

The part worth getting straight is which break. Because the one people picture, where an automation stops and sends an angry email about it, is the cheap one. The expensive break does not look like a break at all. It keeps running, it keeps reporting success, and it quietly does the wrong thing for a month.

The two kinds

Every failure a live automation can have falls into one of two groups, and almost everything about how you should handle it follows from which group it is in.

It stops. A connection expired, an app was busy, an address was rejected, an endpoint moved. Something threw an error, the run ended, and nothing happened. You get an email, or a red row on a dashboard, or in the worst case you find it a week later when you go looking.

It carries on. Nothing errors. Every run is marked successful. And the thing it is doing has stopped being the thing you asked for, because a field changed meaning, or a list came back shorter than it should have, or the process moved on and the software did not.

The second group is smaller and it is where essentially all of the real damage lives.

Why the loud kind is fine

This sounds glib and it is not. A break that errors is safe for a specific reason: nothing happened. The email did not go, the record was not updated, the report was not sent. You are looking at a delay, and delays are recoverable. Somebody chases the quote a day late.

Most of these are also temporary. An app returning “too many requests” at eleven in the morning will accept the same request at eleven fifteen. Any automation tool worth using retries these automatically, backing off a little further each time, and you never learn they happened. That is correct behaviour and it is the bulk of all failures by volume.

The ones that do not resolve on their own are usually structural: a field that no longer exists, a permission somebody revoked, an app that deprecated the thing you were calling. Those need a person, but they announce themselves, and the announcement is the valuable part.

So when someone asks how often automations break, the honest answer is that they break constantly and almost none of it matters.

Six breaks that make no noise

These are the ones to build against. Each one has the same shape: the software is working exactly as instructed, and the instructions have stopped describing reality.

1. The trigger that can never match

This is the worst failure an automation can have, and it is the quietest thing in this article.

An automation that never fires does not fail. It never starts. So there is no failed run, no error, no log entry, nothing on any dashboard. What you see is an automation switched on, marked healthy, with no activity. Which is exactly what a genuinely quiet fortnight looks like.

The most common cause is worth knowing in detail, because it catches careful people. Take a rule that should fire when a deal reaches the stage “Proposal Sent”. In the CRM interface, that is what the stage is called. In the CRM’s actual data, the stage is stored as an identifier, something like 3557570040, and “Proposal Sent” is only the label somebody typed into a settings screen years ago.

A rule written against the words is comparing a stored number to a sentence. It is valid. It refers to a field that genuinely exists. It passes every check a builder is likely to make, switches on cleanly, and then matches nothing for the rest of its life. Nobody finds out until a client asks why they never heard back about a quote.

The same failure arrives by a second route: somebody renames a stage, or adds a new one before the one you were watching, and a rule that had been firing correctly for eight months goes quiet. Nothing errors, because nothing is wrong. There is simply nothing to do any more.

2. The field that goes blank instead of missing

You would expect a field that no longer exists to produce an error, and sometimes it does. Often it does not. Many systems answer a request for a field they do not have with an empty value rather than a complaint, which is a reasonable thing for an API to do and a terrible thing for an automation to receive.

What that looks like in practice is an email that opens “Hi ,”. Or a report where a column is present, is correctly formatted, and is entirely zeroes. Or a task assigned to nobody. The automation succeeded. It sent the thing. The thing was wrong.

This is also the mechanism behind the most common failure in AI-generated automations specifically. A model that has not looked at your actual account will use the field name that is most common across everybody’s account, which is usually right and is occasionally not, and the occasion looks like this rather than like an error.

3. The list that quietly became its first page

Anything that searches or lists gets its results in pages. If something changes about how those pages are requested, and the change is not handled, the automation stops collecting the rest and carries on with whatever came back first.

The result is an automation that used to process every overdue invoice and now processes the first twenty. A weekly report that used to cover the month and now covers a week of it. Nothing errors, the output is well formed, the total is simply smaller than it should be. Unless somebody knows what the number normally is, there is nothing to notice.

This is the argument for writing down what normal looks like before you need it, which comes up again at the end.

4. The process changed and the software did not

Nothing technical breaks here at all, which is why it is the most common of the six and the least often described as a break.

An agency adds a review stage between “Proposal Sent” and “Won”. Or decides that clients on retainer should not get the chasing email. Or moves onboarding from email to a shared document. The automation carries on doing precisely what it was asked to do in March, and the business stopped working that way in June.

Automations are quite good at making a process invisible, which is the point of them, and the side effect is that the process stops being discussed. Nobody thinks to mention a change to the software that is handling the old version of it, because nobody has thought about that software in months.

The practical defence is a calendar reminder. Once a quarter, read what each automation is supposed to do and ask whether that is still what happens.

5. The automation that fires on its own work

An automation updates a record. That update is a change to the record. If something is watching that record for changes, it now has one.

Sometimes that is a loop, in which case you find out immediately and expensively. The quieter version is two automations that were built months apart by different people, where the first one’s write satisfies the second one’s condition, and a client gets a welcome pack every time anybody touches their record.

Everything involved is working. The two automations are individually correct. What is wrong is a relationship nobody drew, because nobody was looking at both at once.

6. The send that may or may not have happened

This one is a genuine dilemma rather than an oversight, and it is worth understanding because it decides how a tool should behave on the worst day.

An automation sends an email and the connection times out. The tool now knows one thing: it did not get an answer. It does not know whether the message was sent and the confirmation was lost, or whether nothing happened at all.

Retrying risks sending a client the same follow-up twice. Not retrying risks never sending it. There is no correct automatic answer, and any tool that always picks one is picking it for you. The right behaviour for anything that reaches a client is to stop and tell a person, because a duplicate email to somebody’s client cannot be taken back, and an alert to you can be ignored in four seconds.

Reading a tool’s retry behaviour is a good way to find out how much thought went into it.

What to do when one breaks

In order, and the order matters more than any individual step.

• Turn it off first, diagnose second. The instinct is to understand it before touching it. Every minute you spend understanding it, it is still running. Switching off is free and reversible and it stops the problem growing.
• Find out what it did, not what it failed at. The failed runs are the safe ones. The dangerous question is what happened on the runs that succeeded, and which records were touched while it was wrong. Get the list of those before you change anything.
• Work out which kind of break it is. Errors mean something rejected a request, so look at connections, permissions and field names. Silence means the trigger stopped matching, so look at what changed in the process. They have almost no causes in common and checking the wrong list wastes the afternoon.
• Check the last thing anybody changed. Not the automation, the systems around it. Somebody edited a dropdown, added a required field, changed a pipeline, or reset a password. Automations break on Tuesdays because somebody tidied something on Monday.
• Fix the data before you switch it back on. An automation that was wrong for three weeks has left three weeks of consequences, and turning it back on does not undo them. Deal with the records first, then the software.

How to build so the breaks are loud

You cannot stop the systems underneath you changing. What you can do is make sure that when they do, you find out from your own software rather than from a client. Four things, none of which depend on which tool you use.

Write down what a normal week is. The number of times each automation should run, in a note, when you build it. Silent failures have exactly one symptom, which is a count that goes to zero or halves, and you cannot see either without a number to compare against. This costs thirty seconds and catches the worst failure in this article.

Prefer a tool that refuses over one that guesses. When something is ambiguous, an automation can stop and ask, or it can pick the likeliest answer and carry on. The second is more pleasant right up until the moment it is wrong, and then it is wrong invisibly. Refusing is the behaviour you want on anything that reaches a client.

Never let the automation be the only record that it ran. If the only evidence a follow-up went out is the automation’s own log, then an automation that has quietly stopped looks identical to a month with no follow-ups due. Have it write to something you would look at anyway: a note on the record, a line in a channel, a column in the sheet you already read on Mondays.

Put a person in the copy of a sample. Blind copy yourself on one in ten of anything that goes to a client for the first month. It is the fastest way to catch “Hi ,”, and the only one that does not depend on remembering to check.

And when you are choosing what to hand over in the first place, start with something recoverable. The first automation you build is really a test of whether the process was understood, and a job where getting one wrong is survivable is a much better test than one where it is not.

Where we come into it

Everything above is true whichever tool you use. This part is about ours and it is the only part that is.

Nrth Star is built around the second group rather than the first. Before an automation is switched on it is checked against your real account, so a rule comparing a stage label against a stored identifier is refused at that point rather than arming cleanly and matching nothing. Then it is replayed over your last 30 days with every send and write switched off, and you read what it would have done, client by client. An automation that would never have fired shows up there as a page with nothing on it, which is a great deal easier to notice in a review than in month three.

While it is running, we watch the systems it depends on for the changes that cause the six failures above, including the ones that do not error. When one needs a decision, the automation pauses rather than running half-working, and you get told what stopped, what it was doing, and what would fix it. It never repairs itself quietly, because an automation that fixed itself wrong does not fail. It succeeds at doing the wrong thing to real clients.

What we do not claim is that nothing will ever break. Everything on this page will keep happening, to us and to everybody else, because the systems underneath belong to somebody else. The difference worth paying for is not fewer breaks. It is finding out from your software instead of from the client who never got their quote.