How to Monitor Make.com Scenarios
Make deactivates a scenario after a set number of consecutive errors. Whether that setting protects you or blindsides you depends on one checkbox.
Monitoring a Make scenario means watching for three things Make handles differently: a run that errors, a scenario that gets deactivated, and a scenario that is active but has stopped being triggered.
Make is better than most platforms at the first and worse than most at the third.
The deactivation rule, and the checkbox that changes it
By default, when a module errors with no error handler attached, Make performs a rollback and marks the execution as an error. After the number of consecutive errors configured in scenario settings, Make deactivates the scenario entirely.
That behaviour flips depending on the Allow storing incomplete executions setting. With it enabled, failed runs go to the Incomplete executions folder and Make retries them at increasing intervals rather than counting toward deactivation in the same way.
Make also auto-retries the two most common transient errors, ConnectionError and RateLimitError, with exponential backoff, and you do not need an error handler to get that. You do need incomplete executions enabled.
| Scenario setting | On module error | Deactivation risk |
|---|---|---|
| Incomplete executions off, no handler | Rollback, execution marked error | High: deactivated after N consecutive errors |
| Incomplete executions on | Run stored, retried at increasing intervals | Lower, but runs pile up unresolved |
| Break error handler attached | Bundle removed, rest of flow continues | Low |
| Commit error handler attached | Execution stops, marked success | None, and that is the danger |
The last row is worth staring at. A Commit directive marks the execution as a success even though the work did not complete. Anything counting successful runs will count that one.
Adding the heartbeat
Use the HTTP module, set to Make a request, as the final module in the scenario. Because Make stops processing subsequent modules on an unhandled error, a ping in the last position only fires on a clean run.
Turn off Evaluate all states as errors on this module specifically. If your monitoring endpoint has a blip, you do not want that blip to be the thing that trips your consecutive-error counter and deactivates a working scenario.
Reporting failures explicitly
Attach an error handler route to the module most likely to fail, ending in a second HTTP module that posts a failure. Use the Resume directive if you want the scenario to continue afterwards, or Break if you want the run parked for manual resolution.
This turns a rollback that would otherwise be one tick toward deactivation into an immediate, attributed alert.
The scenario that is active but never runs
This is the case Make gives you nothing for. A scenario whose trigger stopped firing, because a connection expired, a watched folder was renamed, or an upstream webhook was deleted, sits in the dashboard showing as active with a clean history.
There are no errors to count, no incomplete executions to review, and no notification. The heartbeat interval is the only thing that catches it, which is the reason to add one even to scenarios that have never failed.
For scheduled scenarios, match the monitor interval to the schedule. For instant scenarios driven by a webhook, use your longest normal quiet gap and check it against the History tab rather than estimating.
Watch the connections too
Most Make deactivations that surprise people trace back to an expired OAuth connection rather than a logic error. The connection expires, every run using it fails, the consecutive counter fills up, and the scenario goes off.
Connection expiry is a date, not an event, which means it belongs in an expiry inventory rather than in run monitoring. See credential expiry monitoring for the treatment.
Related guides
Compare with Zapier automations and n8n workflows.