Why Your Automation Stopped Working

Start by establishing whether it ran at all, because a trigger that stopped firing and a task that nobody performed look identical.

That distinction splits the whole diagnosis in two, and getting it wrong sends people to check credentials for a problem that was a renamed form field.

Open the run history first. Everything below depends on what you find there.

---

Step 1 — Did it run?

Three findings, each pointing somewhere different.

No runs at all since a date. The trigger stopped receiving events. Go to step 2.

Runs, marked failed. The trigger fired and the action did not complete. Go to step 3.

Runs, marked successful, no result. The hardest case and more common than it sounds. Go to step 6.

If your platform's history does not go back far enough to answer this, that is itself a finding — note it, and fix the retention or add external logging once this is resolved. A month-old problem is undiagnosable on a seven-day log.

---

Step 2 — The trigger stopped firing

Six causes, in the order worth checking.

1. Something upstream was renamed or removed. A form field, a tag, a list, a status, a folder. The most common cause by a distance, and usually done by somebody who did not know it fed an automation.

2. A credential expired or was revoked. Some platforms surface this loudly and many do not. Check the connection's status directly rather than assuming an alert would have arrived.

3. The account that authorised it was deleted. Connections authorised by a personal account die with the account, so an employee leaving can stop order fulfilment weeks later. How to avoid it.

4. A webhook was removed at the source. Reinstalling or reconfiguring the source app frequently drops registered webhooks without mentioning it.

5. A filter condition became unreachable. The automation runs only when a field equals a value that no longer exists. Nothing errors — nothing matches.

6. The automation was turned off. During troubleshooting, during a migration, or by somebody tidying. Check this early; it is embarrassing and it happens.

---

Step 3 — Runs are failing

Read the actual error before theorising. Four patterns cover most of it.

Authentication or permission errors. Reconnect, and check the scopes — a permission may have been narrowed rather than revoked entirely.

Validation errors. The destination is rejecting the record. A required field was added, a dropdown option was removed, or a format changed. The error usually names the field.

Rate limit errors. Too many calls in a window. These cluster on busy days, which is why the failure appears intermittent and unreproducible.

Timeouts. The destination was slow or unavailable. A handful is normal; a persistent pattern is a capacity problem at the other end.

---

Step 4 — The intermittent case

Intermittent failures are the most misdiagnosed, because the automation works when you test it.

Four causes:

Rate limits, hit only at volume. Testing one record never reproduces it.

A race condition. The automation runs before the data it needs exists. A purchase event firing before the order record has been written is the classic, and it explains cart emails arriving after somebody bought. The consequences when it reaches customers.

Only certain records fail. Look at what the failures share — a character in a name, a missing field, a longer value, a different country format. The pattern is usually in the data, not the automation.

Queue lag. Everything works and arrives hours late, so time-sensitive steps land in the wrong order.

---

Step 5 — It works and the result is wrong

The automation is fine and the configuration is wrong.

• Mapped to the wrong field, so data lands somewhere nobody looks
• A condition inverted, so it fires for exactly the wrong group
• A stale value overwriting a correct one, which is what two-way syncs do when they resolve conflicts by most-recent-update
• Duplicate records, because the deduplication key matches on something that is not unique

Check the destination record, not the run log. The log tells you what was sent, and this class of problem is about what arrived.

---

Step 6 — Successful runs, nothing happening

The most frustrating case and usually one of three things.

It is going somewhere you are not looking. A different list, a different pipeline stage, a test environment, a field not shown on the default view.

A downstream automation is undoing it. Two automations disagreeing, one overwriting the other. Check what else triggers on the same event.

The action succeeded and the effect was suppressed. The record was created and an email was not sent because the contact is on a suppression list, unsubscribed, or previously bounced. This one looks like an integration failure and is not — it is the email platform correctly refusing to send. Why suppression matters.

---

After you fix it

Four things, and the second is the one that prevents a repeat.

Check what was lost. How long was it broken, how many records did not arrive, and can they be replayed? Many platforms can re-run a date range — do this before the log ages out.

Set an absence alert. Not an error alert. A message when this automation has not run in longer than it should. The failure you just spent an hour on produced no error, and an error alert would not have caught it. Why absence is the signal.

Write it in the register. What broke, what caused it, what you changed. The same thing breaks again in eighteen months and nobody remembers.

Check whether anything customer-facing went wrong while it was down — orders unfulfilled, enquiries unanswered, emails unsent. The technical fix is usually the smaller half.

---

Frequently asked questions

Why did my automation stop working on its own?
Most often something upstream was renamed or removed — a form field, a tag, a list, a status — by somebody who did not know it fed an automation. Credential expiry, a deleted authorising account, and a webhook dropped during a reinstall are the next most common.

Why does my automation show successful runs but nothing happens?
Three usual causes: the result is going somewhere you are not looking, a second automation triggering on the same event is undoing it, or the action succeeded and the effect was suppressed — an email not sent because the contact is unsubscribed or previously bounced.

Why does my automation only fail sometimes?
Rate limits hit at volume but never during a single-record test; a race condition where the automation runs before the data it needs exists; a shared characteristic among the failing records; or queue lag putting steps in the wrong order. Compare what the failures have in common.

Can an employee leaving break our automations?
Yes, and it is a common cause. Connections authorised by a personal account are revoked when that account is deleted, so automations can stop weeks after somebody leaves, with no obvious link between the two events.

How do I get alerted when an automation breaks?
Set an alert on absence rather than only on error. The most common failure is a trigger that stops firing, which produces no error at all — just idleness that looks identical to a quiet period. If the platform cannot do this, use an external check.

What should I do after fixing a broken automation?
Establish how long it was broken and whether the missed records can be replayed before the log ages out, set an absence alert, record the cause in your register, and check what went wrong customer-side while it was down — unfulfilled orders, unanswered enquiries, unsent emails.