Be notified when a scenario simply doesn’t run when it should: expired connection, changed webhook, trigger app quietly stopped sending. Not errors, those already notify me. Silence.
What is the problem & what have you tried?
Error notifications in Make work fine. But when a scenario just stops running with no error, nothing tells me, and I notice days later. I’ve looked at the built-in notification settings and at checking the execution history manually. Does anyone monitor for missed runs, maybe via the API scenario logs, or is checking history by hand the only way?
If you know that the scenario runs at least once a day. Then you can have a second scenario check the execution history of the first one at the end of the day. Then if there were no runs logged, send a notification.
Stoyan’s daily history check works when you know the scenario should fire at least once a day. For webhooks / “should run every hour” cases I use a heartbeat instead, because history alone does not tell you the trigger went quiet mid-day.
Pattern that has worked for me:
At the end of the production scenario, write/update a Data Store record: scenario name + last_run_at (now).
Second watchdog scenario on a schedule (e.g. every 30–60 min) reads that record.
If last_run_at is older than your SLA (say 3 hours for an hourly webhook), send Slack/email with the scenario name and the stale timestamp.
Also alert if the Data Store write itself fails (connection expired on the watchdog).
That catches “no error, just silence” without waiting until end of day. Pair it with normal error notifications; they cover different failure modes.
Yes, same core pattern. The extra piece I was calling out is the heartbeat write inside the production scenario, so the watchdog also catches a stale or failed health write, not just a missed schedule. That helps with webhook scenarios that may be quiet for part of the day.
If you check history, “success” will mean that the scenario completed. It doesn’t actually tell you if the trigger step actually fired the logic you care about. This means a module that skips silently can still show up as a clean run in the history.
You should try a Data Store approach. You put the Data Store write after the specific step that matters not at the end. If there is nothing written it means that step didn’t happen, even if the scenario technically “ran”. You are checking for business logic not just execution status.
This also matters for API based monitoring. Polling execution history per scenario means dealing with pagination and rate limits for every scenario that you watch. A single Data Store read becomes much cheaper if you are monitoring a lot of scenarios.
Main benefit vs history alone: write the heartbeat after the step you care about, so a silent skip or quiet webhook still goes stale, and a failed Data Store write itself is an alert. History success can still mean the important step never fired. Anthony covered the business-logic angle well above.
Important modules don’t magically skip silently, what the hell are you guys talking about? Please show me a scenario built in such a way where this is an actual issue and I will show you an extremely poorly designed scenario?
The watcher-scenario approach works well. A couple of things that made it more reliable for me:
Store the expected run gap per scenario (e.g. hourly, daily, or “only on new leads”). A single “no runs in 24h” rule will cry wolf on scenarios that are quiet by nature.
Check the last successful trigger timestamp instead of just counting runs. That catches the case where runs happen but the trigger has silently stopped matching new data.
Run the watcher on a schedule outside the monitored scenario, so if the whole Make account has an issue, you still get an alert.
If you want to avoid building it per scenario, a webhook proxy or heartbeat service in front of the trigger can also alert on missing calls, which covers the “trigger app quietly stopped sending” case from the original post.
I’m researching the work involved in detecting automations that stop delivering their expected result. Did the history-check or heartbeat approach suggested in this thread solve your missed-run problem?
If it did, roughly how much work was needed to configure and maintain it? If it did not, what recent task was missed, how did you discover it, and what manual work followed?
I am not offering a finished monitoring product. A description without logs, credentials or customer data would be enough; I’m trying to understand when existing tools are already sufficient.
Make has no built-in notifier for a scenario that silently stops, so the reliable pattern is a watchdog scenario: schedule one every 15 minutes to call the Make API and check each critical scenario’s scheduling status and last run time. If a scenario that should run every X minutes hasn’t run in 2X — or its scheduling got flipped off (expired connections auto-disable scenarios) — the watchdog alerts you via email or Slack. The Make API also exposes connection health, so you can flag connections nearing expiry before they break. Key point: never rely on a scenario to report its own death — only an external check catches ‘it just stopped.’
What is your goal?
What is the problem & what have you tried?