Why was my Make (Integromat) scenario deactivated?

Make deactivates a scenario when it errors repeatedly — by default, consecutive failed executions trip the breaker and the scenario is switched off until a human intervenes (exact thresholds depend on settings and plan; error handlers change the behavior). It's sensible protection against burning operations on a broken flow, and it means a transient API outage in one connected app can permanently stop your automation at 2 AM Saturday. Detection is the heartbeat pattern: a final HTTP module pings a unique URL on each successful run, and silence past the expected cadence raises the alert.

Where should the heartbeat step go in a workflow?

Last, and only on the success path. The ping asserts 'this run completed its real work' — so it belongs after the final action, positioned so an upstream error prevents it from executing. Don't put it in a parallel branch (it would ping even when the main branch fails) and don't put it first (it would ping before anything happened). In Zapier that's the final action step; in Make, the last module in the main route; in n8n, an HTTP Request node after the last real node, with the workflow's error handling configured to stop before reaching it on failure.

What interval and grace period should automation heartbeats use?

Match the expected cadence, then add generous grace. Scheduled workflows are easy: a daily 6 AM sync expects one ping per day with an hour or two of grace. Event-driven workflows (new order, new lead) need the cadence of the business event, not the workflow: if you expect at least one order every 4 hours during business hours, an 8-hour heartbeat catches 'orders stopped flowing through the automation' without false alarms on quiet nights. For very bursty flows, monitor a scheduled canary run instead — a test record pushed through the flow every morning proves the pipeline end to end.

How to Monitor n8n, Zapier, and Make Workflows

Q: Why did my Zapier Zap stop running?

The usual causes: Zapier turned the Zap off after repeated errors (an expired app connection is the classic trigger), the connected account's OAuth token was revoked when someone changed a password or left the company, you hit your plan's task limit mid-month, or the trigger app changed its API and the trigger silently stopped matching. Zapier emails about some of these — to the Zap's owner, who may be an ex-employee or a shared inbox nobody reads. A heartbeat step at the end of the Zap converts every variant into the same detectable signal: the pings stop, and your team gets an alert on a channel it actually watches.

Q: How do I monitor self-hosted n8n?

Three layers. First, the instance: n8n exposes /healthz — point an HTTP monitor at it to catch the container being down, the reverse proxy misrouting, or the database connection failing. Second, each critical workflow: an HTTP Request node as the final step pings a heartbeat URL, so a workflow that errors, a schedule trigger that stops firing, or a worker that died mid-queue all show up as missing pings. Third, n8n's own error workflow feature: attach a global error workflow that calls a webhook, giving you immediate loud failures to complement the heartbeat's silence detection.

Automation platforms occupy a strange blind spot. The workflows running on n8n, Zapier, and Make are load-bearing business logic — they move leads into the CRM, invoices into accounting, orders into fulfillment — but because they aren't "real infrastructure," nobody monitors them like infrastructure. Meanwhile the platforms themselves are designed to stop silently: Zapier turns off Zaps that keep erroring, Make deactivates scenarios after consecutive failures, and a self-hosted n8n dies with its container — and in every case the notification, if any, is an email to whoever created the automation two years ago.

The result is a failure mode every ops team knows: the automation died on the 3rd, and you found out on the 14th when someone asked why the CRM was empty. This guide fixes that with the same heartbeat pattern we use for cron jobs — one extra step per workflow, and a dead automation becomes an alert within hours instead of a forensic discovery within weeks.

Why automations die silently — by design

Error-triggered shutoff. Zapier pauses/turns off Zaps that error repeatedly; Make's breaker deactivates scenarios after consecutive failed executions (thresholds vary by settings and error handlers — as of 2026). Reasonable protection, silent outcome: one flaky API weekend and the automation is off until a human notices.
Expired connections. OAuth tokens die when passwords change, employees leave, or apps rotate credentials. The workflow doesn't error interestingly — it just stops working, sometimes by triggering zero runs.
Plan limits. Task/operation quotas exhaust mid-month; runs stop or queue. The platform knows; your team doesn't.
Trigger drift. The trigger app renames a field, a webhook subscription lapses, a polling trigger's filter stops matching — the workflow is "on" and simply never fires again.
Self-hosted mortality (n8n). The container OOMs, the VPS reboots without a restart policy, the Postgres backing store fills its disk, the queue-mode worker dies while the main process looks fine. Standard self-hosted failure modes, applied to the tool that runs everything else.
Notification dead ends. Every platform's failure email goes to the workflow's owner — the intern who built it, the founder's old address, the agency that offboarded. The notification system's failure mode is the org chart.

The common thread, as with GitHub Actions schedules and systemd timers: the work stops, and no human finds out. Silence-based detection is the only pattern that catches every variant.

The heartbeat step: one module, total coverage

Add a final step to each critical workflow that makes a GET request to a unique CronAlert heartbeat URL. Tell CronAlert the expected cadence and a grace period. Every failure above — shutoff, expired token, quota, dead trigger, dead container — now produces the same observable: the pings stop, and you get an alert in Slack, email, PagerDuty, or wherever your team actually looks.

Zapier: add a final Webhooks by Zapier action (GET, the heartbeat URL). It runs only when the preceding steps succeeded, which is exactly the semantics you want. (Webhooks is a premium-plan app as of 2026 — on lower plans, a final step in any app that can call a URL works.)
Make: a final HTTP module on the main route. Combine with Make's error handlers deliberately: if a handler swallows errors to keep the scenario active, ensure the flow still bypasses the heartbeat on failure — a heartbeat that pings on handled-but-failed runs is worse than none.
n8n: a final HTTP Request node. Set continueOnFail appropriately upstream so error paths never reach it, and use a separate error workflow for loud failures.

Placement rules: last step, success path only, never in a parallel branch. The ping asserts "the run finished its real work" — anything that lets it fire earlier or on failure quietly redefines that claim.

Cadence: scheduled vs event-driven workflows

Scheduled workflows map directly: daily sync → expect one ping per ~24h, grace of an hour or two. Event-driven workflows need a subtler contract — the heartbeat cadence should reflect the business event's expected frequency, not the workflow's. "At least one new-order run every 8 business hours" catches both the workflow dying and orders not flowing, which is usually a feature: either way, someone should look. For genuinely bursty flows where any silence window would false-alarm, run a scheduled canary instead: a morning test record pushed through the full pipeline (then filtered before side effects), pinging on completion. The canary proves the trigger, the connections, and the actions end to end, every day, regardless of real traffic — the same pattern as our webhook receiver guide.

Self-hosted n8n: monitor the instance too

Workflow heartbeats assume the platform under them is running; when you self-host, that's yours to verify:

/healthz. n8n ships a health endpoint — an HTTP monitor on it catches the dead container, the misrouted reverse proxy, and the lost database connection. Add a keyword assertion on the response body so a proxy's generic 200 can't impersonate it.
The editor URL and webhook URL. If external services deliver webhooks into n8n, monitor the webhook base path specifically — a TLS or proxy misconfiguration can kill inbound triggers while the editor works fine.
A global error workflow. n8n can attach an error workflow that fires on any workflow failure — point it at a webhook or Slack. That's your loud, immediate channel; heartbeats remain the safety net for the failures that don't error (queue-mode workers dying, schedule triggers not firing after a restart, the instance itself down — an error workflow can't report the death of the thing that runs it).

That last parenthesis is the whole argument for external monitoring in one line: the error workflow can't report the death of the thing that runs it. Loud failure hooks and silence-based heartbeats are complements, not alternatives — the same pairing as OnFailure= plus ExecStartPost in our systemd guide.

Set it up in ten minutes

Create a CronAlert account — heartbeat monitors are on every paid plan, from $5/mo Pro; the n8n /healthz HTTP check fits on the free plan.
Inventory the automations whose silent death costs money — the lead router, the invoice sync, the fulfillment flow. Skip the trivia.
One heartbeat monitor per critical workflow; add the final webhook/HTTP step; set cadence + grace per the section above.
Self-hosting n8n: add the /healthz monitor and a global error workflow.
Test the failure path: disable a workflow, confirm the alert arrives after the grace period, re-enable.
Route alerts to the team channel — not to whoever built the Zap in 2024.

Frequently asked questions

Why did my Zapier Zap stop running?

Error-triggered shutoff, an expired app connection, task limits, or trigger drift — all silent beyond an easily-missed email. A final heartbeat step converts every variant into an alert.

Why was my Make scenario deactivated?

Make's breaker switches scenarios off after consecutive failed executions. A heartbeat's silence tells you within hours; otherwise you find out from the missing data.

How do I monitor self-hosted n8n?

HTTP monitor on /healthz (instance), heartbeat per critical workflow (flows), global error workflow to a webhook (loud failures). All three layers, because they fail independently.

Where does the heartbeat step go?

Last, success path only, never parallel. It must be unreachable when the real work failed.

What cadence for event-driven workflows?

The business event's expected frequency with generous grace — or a daily scheduled canary through the full pipeline when real traffic is too bursty to promise a cadence.

Your automations run the business — watch them like it

Every platform in this post will eventually switch something off, expire something, or die quietly under something — their own notification systems say so. One heartbeat step per workflow turns the whole genre of "the automation's been dead for a week" into a same-day alert. Create a free CronAlert account, add the webhook step to your most valuable workflow, and test-fail it before lunch — Pro is $5/mo when you're ready for more than the free instance checks.