Your automation did not error. It just stopped happening, which nothing is watching for.

Somebody notices in week seven. The review requests stopped going out in week two, and the intervening five weeks of customers are gone in the sense that nobody is ever asking them again.

Nothing broke. That is the part worth understanding.

Errors are the easy case

When a step genuinely fails, the tooling behaves well. Zapier sends notifications to your account email address by default, and you can set the frequency to immediately, to immediately plus an hourly summary, to an hourly summary, or to never, which its own documentation flags as not recommended.

So the loud failures are handled. The problem is that the loud failures are not the ones that cost you.

The two failures that look like success

The first is a trigger that stops firing. Somebody renames a form field, a connection quietly loses its authorisation, a filter that used to let things through now excludes everything.

Nothing errors, because nothing ran. An automation that executes zero times today has not failed in any sense the system recognises, and zero is not a number anybody gets emailed about.

The second is worse because it looks healthy. The workflow runs, every step reports success, and the data lands somewhere nobody reads. A field renamed on the destination side, a tag nobody filters on any more, a notification going to an inbox that was retired last year. Every run is green. The outcome is identical to doing nothing.

Two ways the alarm itself fails

Even the errors you would catch depend on the alert reaching a person.

Zapier sends those notifications to the Zapier account email address. That is very often the address of whoever built the thing, which is very often a consultant who finished eighteen months ago or an employee who has since left. The alerts are being generated correctly and delivered to nobody, which is one of the more expensive versions of working as intended.

The second one is genuinely counterintuitive. Zapier does not send error notification emails when an error handler runs. Build the responsible thing, the graceful path that catches a failure and carries on, and you have also switched off the message that would have told you it keeps happening. That is a reasonable design decision and it is worth knowing you have made it.

Watch for absence, not for errors

This is the whole shift, and it is not a tooling purchase.

Error monitoring asks whether anything went wrong. Absence monitoring asks whether the thing that should have happened did. For a small business the useful version is embarrassingly simple: name the two or three automations that actually carry money, write down roughly how often each should run in a normal week, and check the real number against it on a fixed day. Twelve review requests when there were fourteen jobs is a question. Zero is an emergency that nothing else in your stack will raise.

The counting matters more than the technology. A number somebody looks at every Monday beats an elaborate alerting rig that emails a dead address.

The question that settles it

Pick your most important automation and ask how you would find out if it stopped tonight.

If the honest answer is that a customer would eventually mention it, then your customers are your monitoring, and the detection time is however long it takes somebody to complain. That is the same absence of an owner that makes every other automation pitfall survive so long, and it is fixed the same way, by a name against the thing rather than a tool on top of it.

If you have automations running and no idea whether they ran this week, book a strategy call. Working out what should be counted takes about twenty minutes and it is the cheapest insurance in the stack.