“Scenario has been stopped”: Why Make.com Disables Your Scenario After 3 Errors, and How to Actually Find Out
You opened Make.com and the scenario is off. The leads stopped syncing days ago, and your client noticed before you did. Here’s exactly why Make.com switched it off, why the email it sent isn’t a safety net, and how an external heartbeat catches it the moment it happens.
What you’ll learn
- Why Make.com automatically disables a scenario, and which errors switch it off instantly
- Why the one deactivation email is the weakest link in your monitoring
- The failures Make.com never emails you about at all
- How to add an external Dead Man’s Switch with multi-channel alerts
First: what “Scenario has been stopped” actually means
Make.com doesn’t kill scenarios at random. There’s a defined mechanism, and it’s worth understanding before you blame yourself (or your code):
- Consecutive errors. By default, when a scenario errors out on several runs in a row (commonly three), Make.com deactivates it to stop it from burning operations on something that’s clearly broken. The threshold is configurable in the scenario settings.
- Instant deactivation. Some errors don’t wait for a third strike. An invalid or expired connection, a failed account validation, or hitting a hard limit can switch the scenario off on the spot.
- One notification email. When this happens, Make.com sends an email to the organization’s notification address telling you the scenario was deactivated.
So far, so reasonable. The problem isn’t the mechanism, it’s that the mechanism is the only thing standing between a dead automation and an angry client.
Why that email isn’t a safety net
A single email to a single address is exactly how a Silent Failure slips through. In the real world, that email:
- lands in a shared inbox nobody actively watches;
- gets caught by a filter, or buried under fifty other notifications;
- goes to the org owner, who isn’t you, the freelancer who built the scenario;
- arrives while the one person who reads it is on vacation.
One channel, one recipient, no escalation. For something a client is paying you to keep running, that’s not monitoring, it’s a coin flip.
The worse problem: the failures Make.com never emails about
The deactivation email only fires when a scenario errors and gets switched off. It says nothing about the quieter ways an automation stops doing its job:
- The scenario was turned off manually (by you, a teammate, or the client) and never turned back on.
- The schedule is misconfigured, set to a window that never triggers, or left inactive after an edit.
- The trigger simply never fires because the upstream app changed, paused, or stopped sending data.
- The scenario “succeeds” every run but processes 0 records, green status, zero work done.
None of these throw an error. None of them send you anything. This is the core lesson: don’t rely on the platform to tell you the platform stopped.
The fix: an external Dead Man’s Switch
Heartbeat Monitoring (Healthchecks) flips the dependency. Instead of waiting for Make.com to report a problem, your scenario sends a small heartbeat every time it runs successfully. An independent service expects that heartbeat on a schedule. If it doesn’t arrive in time, the absence is the alert. That’s a Dead Man’s Switch.
Because the monitor lives outside Make.com, it catches all of it:
- Overdue detection: deactivated, paused, mis-scheduled, or never-triggered. If the heartbeat is late, you know.
- Grace Period: a buffer for retries and queue delays, so you don’t get paged for a one-minute blip.
- Payload Inspection: send records_synced with each ping and alert when it’s suspiciously low, catching the “ran, but did nothing” case.
- Multi-channel alerts: Slack, Microsoft Teams, webhook, or email, not one inbox you hope someone is watching.
Setting it up in Make.com (2 minutes)
Drop watchflow’s native Make.com module at the end of your scenario so it fires a heartbeat on every successful run. No webhook glue to build, add the module, pick your monitor key, set the interval.
Prefer the raw call? Any HTTP module works too:
The first ping creates the monitor automatically, the unique key defines it, so there’s no setup wizard. Full reference: /api/heartbeat/.
Track the run, not just the status
Send a small payload with each heartbeat so a “successful” run that synced nothing still raises a flag (Payload Inspection):
For the explicit failure path, add watchflow to an error-handler route in Make.com and send a fail ping so you know not just that it broke, but why:
Recommended setup
- Match the interval to your scenario’s schedule (e.g. 1h for an hourly sync).
- Set a Grace Period of 10 to 30 minutes to absorb retries and cold starts.
- Route alerts to Slack or Teams, not just email.
- Send a payload metric you care about and alert on suspicious values.
If you build for clients: show them it’s alive
When you run automations for other people, the real value isn’t just getting the alert, it’s being able to prove it’s still running without screenshots or “let me check and get back to you.” With watchflow you can group every scenario by client and share a live status page that shows each one running on time. It’s the difference between the client telling you it stopped and you telling the client it never did.
Conclusion
Make.com disabling your scenario isn’t the failure, finding out late is. The built-in email covers one path through one channel to one person. An external heartbeat covers every way an automation goes quiet, and tells the right people on the channels they actually watch.
Ship the automation. We’ll watch it.
Protect your most critical scenario free, forever, 3 heartbeats, silent-failure alerts, and the native Make.com module, no credit card.