How to tell when a Make scenario stops running

When a scheduled scenario finishes with an error enough times in a row, Make disables its scheduling. The threshold is configurable per scenario, under the consecutive-errors setting, and some failures do not wait for it at all: certain fatal errors disable scheduling on the first occurrence.

Crucially, a scenario deactivated this way stays deactivated. It does not recover on its own when the upstream API comes back; reactivating it is a manual step, or something you build yourself against the Make API.

Read that sequence as a timeline and the shape of the problem is clear. You get a burst of error notifications, which look like the same transient failure you have seen before. Then they stop. The stopping feels like the problem resolving itself. It is actually Make switching the scenario off, and the absence of further email is the strongest possible signal that nothing is running at all.

Error notifications cover executions that ran and failed. They are the burst described above. They are silent for the entire period after deactivation, which is the period you actually need to hear about.

The scenario's history is an accurate record of executions and, like any log, only answers questions you go and ask. A scenario that stopped eleven days ago looks identical to one that stopped eleven minutes ago until you open it and read the timestamp.

Error handlers on individual modules are the right fix for the underlying flakiness, and using them is how you avoid tripping the consecutive-error threshold in the first place. They are a way of preventing deactivation, not a way of being told it happened.

A second scenario that watches the first runs on the same Make account under the same scheduling and the same error policy. It can be deactivated by exactly the mechanism it exists to detect, and if it is, nothing tells you that either.

Have the scenario report in at the end of every successful run, and keep the expectation of those reports outside Make. A timer somewhere else is reset by each report; if the timer expires, the report never came, and that is the alert.

This works for Make's deactivation behaviour specifically because it does not care about the reason. Deactivated after consecutive errors, switched off by a colleague, stalled on a queue, out of operations for the month: all four produce silence, and silence is the thing being measured.

Add an HTTP module as the last module of the scenario, using the “Make a request” action, and place it after the last module you consider the real end of the work. Set the method to GET and the URL to the ping URL for that monitor:

The monitor holds an expected interval and a grace period, and the deadline is the last ping plus both. Grace defaults to twice the interval, on the basis that a scenario running a few minutes late is normal and a tool that alerts on normal gets ignored.

Once the deadline passes you get one email for the outage. One, not one per check: the checker runs every minute, and the alert is recorded the first time so subsequent runs stay quiet. When pings resume you get a single all-clear, and only then can the monitor alert again. Two emails per outage, start and end.

For a scenario scheduled at a fixed time of day rather than on an interval, the deadline is a wall-clock time in your account's timezone, so it means the same hour to you year-round.