How to watch automations across several client accounts

Why did nobody get an email?

Coming back to a client account after six weeks and finding that nothing has run since the 3rd is a specific kind of bad. Not because the repair is hard - usually it is a reconnected account and ten minutes - but because six weeks of orders, leads or invoices went somewhere else, and nobody can say exactly where.

The question that follows is always the same: why was there no alert?

The answer is the same on Zapier, Make and n8n, and it is structural. This is not a setting somebody forgot. Every notification these platforms can send is produced by a run. An error is something a run makes. Silence is the absence of runs. There is nothing there to generate a message.

Hold one account and you notice anyway, because you are looking at it. Hold twelve and the accounts that quietly stopped look exactly like the accounts that had nothing to do that week.

What does each platform do when a workflow keeps failing?

It switches the workflow off. That is worth sitting with, because it means the platform's own response to a loud failure is to convert it into a quiet one.

Zapier states the threshold plainly:

Zapier will automatically turn off your Zap if it: Errors 95% of the time it runs. Has run more than 20 times in the past 7 days.

• Zap is not running, Zapier Help Center, updated 29 May 2026

Read the wording closely, because the whole article is in it. The threshold is defined relative to runs: 95% of the time it runs, more than 20 times in seven days. A Zap that stopped being triggered never runs, so it never errors, so it never approaches the threshold. It stays switched on, looking healthy, doing nothing, indefinitely.

Make counts differently and, for webhooks, does not count at all:

The default number of consecutive errors is 3.

Make disables instantly triggered scenario immediately if an error happens.

• Overview of error handling, Make Help Center

Three named error types skip the counter entirely and disable scheduling on the spot: AccountValidationError, OperationsLimitExceededError and DataSizeLimitExceededError. The first of those is the everyday one - an expired connection. A client changes a password or a token ages out, and the scenario is off within one run.

n8n does not deactivate anything, but its alerting has the same shape. The error workflow is described in one sentence:

It runs if an execution fails.

• Handle errors gracefully, n8n Docs

No execution, nothing to fail, no error workflow.

Why does better engineering make failures quieter?

Because error handling is, by design, the removal of errors - and notifications are attached to errors.

Zapier puts it in a limitations block, in one line:

Zapier will not send any error notification emails when an error handler runs.

• Manage notifications when errors occur in Zap workflows, Zapier Help Center, updated 29 May 2026

Make arrives at the same place from a different direction. Turning on incomplete executions - the setting that exists so failed runs do not lose their data - changes the status of everything that goes wrong:

With incomplete executions enabled, Make stores the scenario state when the error happened as an incomplete execution. You can then check the scenario run, investigate why the error happened, and fix it to finish the scenario run successfully. In addition, all scenario errors turn into warnings.

• Overview of error handling, Make Help Center

And warnings, by the same page, are outside the deactivation logic entirely:

When you get a warning. If a scenario finishes with a warning, Make will keep scheduling subsequent scenario runs.

• Overview of error handling, Make Help Center

So the two things a competent builder does - add error handlers, switch on incomplete executions - both move failures out of the category that shouts and into the category that does not. This is not a flaw in either product. Both behaviours are correct: you asked for the run to survive the error, and it did. It is just that "survived" and "did the job" are different claims, and only one of them is being reported.

The same mechanism has its own article's worth of consequences on Make, where a timeout arrives as a warning and repeats every night without ever counting toward deactivation.

Whose inbox does the alert land in?

The account owner's, which in agency work is frequently not you.

When errors occur in your Zap workflows, Zapier will send notifications to your Zapier account email address by default.

• Manage notifications when errors occur in Zap workflows, Zapier Help Center, updated 29 May 2026

For the deactivation warning specifically, Zapier says the mail goes to the account owner and that a grace period applies on the higher plans:

If your account is on a Team or Enterprise plan, Zapier will send you an email notification to the account owner and provide a grace period before turning off your Zap. Enterprise plan accounts have a 72-hour grace period and Team plan accounts have a 24-hour grace period.

• Zap is not running, Zapier Help Center, updated 29 May 2026

Worth noting as a dated observation, and not as a claim about current pricing: Zapier's own product update note describes the same grace periods, same 72 and 24 hours, but names the plans "Team or Company" instead of "Team or Enterprise". Two pages of the same help centre, read on 17 August 2026, disagreeing on the plan names. If the grace period is load-bearing in how you work, check it against the account in front of you, and treat both pages as second-hand.

Three practical consequences for anyone holding several accounts:

1. If the client owns the account, the client gets the mail. They are the least equipped person to interpret it and the most likely to file it.
2. The grace period is documented only for the higher plans. Zapier describes it for Team and Enterprise accounts. For the lower tiers nothing is stated either way, so plan for the Zap switching off at the threshold and check the account in front of you rather than assuming.
3. Admin reach is a plan feature. Zapier notes that "Super Admins and Owners in Team and Enterprise accounts can set up custom notifications for any Zap in their account" (Manage notifications when errors occur in Zap workflows, updated 29 May 2026) - useful when it applies, and unavailable when the client is on a cheaper plan.

So what should you actually watch?

Expected runs, not errors. One number per automation: did this run as often as it was supposed to, in the last period?

That single change flips the problem the right way up. Errors are reported by the account, which means you only learn about failures the account is willing and able to describe. Expected runs are counted by you, from outside, which means absence becomes a measurement in its own right.

A workable definition of the check, per automation:

1. The expected cadence. Hourly, daily, weekdays at 08:00, or "at least once a week" for the irregular ones.
2. The tolerance. How long may it be quiet before that is abnormal? For a daily sync, 36 hours. For an order webhook on a shop that gets 40 orders a day, four hours. For a monthly invoice run, five weeks.
3. The proof of life. One timestamp written somewhere you control at the end of a successful run.
4. The owner. Which of your clients this belongs to, so an alert tells you whose business is affected without opening anything.

Note what is not on the list: the reason it stopped. Diagnosis comes after detection, and mixing them is a reliable way to stall: it is easy to start building something that explains the failure, lose interest, and ship nothing.

How do you build the proof of life without new tools?

Add one step to the end of each automation that writes a row: account name, automation name, timestamp. One shared sheet or one table in a database, across all clients. Every platform here can append a row, and on Make the call itself is cheap - scenarios called through the Scenarios app do not consume credits, so a shared heartbeat subscenario costs nothing per run.

Then one scheduled job, living in your account, reads that table once an hour and compares each row's timestamp against its tolerance. Anything overdue goes into one message.

The properties that matter, and they are all consequences of the argument above:

• It lives outside the client accounts. A watcher inside an account that has gone dark goes dark with it.
• It reports absence, not failure. Nothing has to error for it to speak up.
• It has one output. A single overdue list. Twelve notification streams are the problem it exists to replace.
• It survives deactivation. When Zapier switches a Zap off or Make disables a scenario, the row simply stops being updated - which is exactly the condition being watched.

The last row of the table is also the answer to the client question "how long has this been broken?", which otherwise costs an hour of reading run histories with retention limits you cannot control.

One warning about the digest, because it has a specific way of failing: put a number in it that is supposed to move. A daily message saying "all clear" reads identically whether the automation processed 200 orders or zero, so a quiet all-clear can sail through for a week while nothing at all is happening. "Order sync: 214" is a health check. "Order sync: OK" is a green light wired to nothing.

Can you check a whole account in one call?

On Make, yes, and it is the cheapest thing in this article. The API lists every scenario in an account, and the list itself carries the two fields you want. From the API reference for scenarios:

Set this parameter to true to get only active scenarios in the response.

• Scenarios, Make API reference, isActive

That sentence documents one direction only, and the distinction matters before you write the call. A few fields down, isinvalid spells out both - "or false to return only valid ones" - while isActive describes nothing but true. Passing isActive=false may well return the switched-off scenarios, but it is not a documented contract, and an undocumented filter is a poor foundation for a check whose whole job is to notice silence.

The dependable version costs the same one request: list the scenarios and filter on the isActive field the response already carries. That enumerates every scenario currently switched off - including the ones Make disabled itself after three errors or after the first webhook failure - which is the entire "something went quiet and nobody said" category, without opening a single dashboard.

The same response carries dlqCount, the number of stored incomplete executions, and scheduling with the interval - as a string, not an object. The reference is explicit about it ("To save resources, the scheduling details are sent as a string, not as an object"), and code that expects to read a field off it breaks on the first account. So one call per account gives you what is off, what is silently queueing up failed runs, and how often each thing was meant to run - the inventory from the previous section, generated for you instead of typed by you, with one string to parse.

What counts as "expected" for a webhook?

This is the hard part, and pretending otherwise is how a heartbeat setup ends up switched off a few weeks later.

A scheduled job has an obvious expectation: it runs every hour, so silence for three hours is wrong. A webhook-triggered automation only runs when the outside world does something, and the outside world is allowed to be quiet. A shop that takes no orders on Sunday is not broken.

Three approaches that hold up, in increasing order of effort:

1. Set the tolerance from the quietest real period. Averages hide the gap that matters. Look at the run history, find the longest genuine gap in the last quarter, and set the threshold above it. Noisy at first, then stable.
2. Watch the upstream count instead. For a shop, compare orders in the platform against runs in the automation. Divergence is the signal, and it also catches the nastier failure where the automation runs but processes nothing.
3. Give the automation a synthetic pulse. A scheduled job fires one test record through the same path once an hour. This is the only method that distinguishes "nothing happened" from "something happened and was dropped" - and it is also the one that requires the path to be safe to run with test data. That is a design change, and it belongs in a different conversation.

Whichever you pick, write the tolerance down next to the automation. A threshold nobody can explain gets muted the first time it fires at a weekend.

There is one case none of the three methods covers, and it deserves its own check: the automation that has never run at all. Every approach above compares against a baseline, and something switched on last Tuesday that has not fired once has no baseline to be measured against. It looks new, and new looks fine. "Zero runs since it was turned on" is a different alarm from "quiet for longer than usual", and on a handover of somebody else's build it is the more common one.

Why was the alert ignored when it did arrive?

Because it was one of many, and it did not say what it cost.

Zapier's default notification frequency is immediate: an email per error as it happens. On an automation failing every fifteen minutes, that is a mailbox nobody can read, and the standard human response is a filter rule. The filter rule then swallows the one message that mattered three weeks later.

Two changes fix most of this without any new software:

• Deduplicate before you notify. One message per automation per day, however many times it failed, with a count. Volume is a property of the failure, not information about it.
• Put the consequence in the subject line. "Client X, order sync, quiet for 19 hours, roughly 25 orders unprocessed" is read. "Zap error" is not. The estimate does not need to be exact to change what happens next.

Is this worth buying instead of building?

Sometimes, and it is worth being honest about where the line falls.

Buying makes sense when you need per-client dashboards and access, an audit trail you can show, or on-call rotation and escalation. Those are real products with real work in them, and rebuilding them badly is a poor use of a weekend.

Building the heartbeat yourself makes sense when the requirement is what most small operations actually need: a single list of what has gone quiet, and a timestamp per automation. That is a table, a scheduled job and a tolerance column. It stays cheap because it does not try to explain anything.

The failure mode worth avoiding is the middle: a monitoring product bought, connected to three of the twelve accounts, and never finished - which produces a dashboard that is green because it is not looking, and that is worse than nothing because it is trusted.

Where to start if several accounts are already unwatched

1. Inventory before instrumentation. One row per automation across every account: client, platform, what it does, how often it should run. Most people discover here that they cannot list them all, and that is the actual finding.
2. Check the switched-off ones first. In each account, sort by status. A Zap that Zapier turned off, or a Make scenario that was disabled after three errors, is already broken and already silent right now.
3. Look at last-run timestamps against the inventory. Anything whose last run is older than its cadence is a live incident, today.
4. Add the heartbeat row to the automations that touch money first. Orders, invoices, payouts, anything customer-facing. The rest can wait a week.
5. Only then build the watcher. It is one scheduled job, and it is worth nothing until the inventory exists.

If a specific automation has already gone quiet and you are trying to work out why, the diagnosis splits differently depending on the trigger - for the webhook case, the question is whether the trigger was ever asked to run.

When this is a job to hand over

Doing this yourself is reasonable when you know what the automations are, the accounts are yours to configure, and nothing has been quietly failing long enough to have created a mess in the data.

It stops being reasonable in two situations. The first is when the inventory step does not converge - nobody can say what runs where, the accounts were built by different people, and half the connections are under logins that have moved on. The second is when something has already been silent for weeks and the question is no longer detection but reconstruction: what was missed, what has to be replayed, and in which order, without double-charging anyone.

Both are scoped, finite jobs with a known shape and a known price, which is what Fix M and L are for.

Sources

• Zap is not running - Zapier Help Center, updated 29 May 2026. The 95% / 20 runs / 7 days deactivation threshold, the grace period by plan, and the error ratio override.
• Manage notifications when errors occur in Zap workflows - Zapier Help Center, updated 29 May 2026. Default routing to the account email, immediate frequency, and the limitation that error handlers suppress notification mail.
• More time to fix Zap workflows that error - Zapier Help Center, updated 29 May 2026. The same grace periods under different plan names.
• Overview of error handling - Make Help Center. Default of 3 consecutive errors, immediate deactivation for instant triggers and for three named error types, warnings keeping the schedule, and errors becoming warnings under incomplete executions.
• Scenario settings - Make Help Center. Errors before deactivation, and the instant-trigger exception.
• Scenarios - Make API reference. Listing scenarios by isActive, the meaning of isinvalid, and the dlqCount and scheduling fields in the response.
• Handle errors gracefully - n8n Docs. Error workflows run if an execution fails.
• Error Trigger - n8n Docs. What the error workflow receives, and the fields missing when the trigger node is the thing that failed.