Monitoring Make.com scenarios for errors and missed runs

Make (formerly Integromat) has more error-handling machinery than most automation tools: five error handlers, incomplete executions, and a consecutive-error limit that switches a scenario off. Those tools are good at dealing with errors. They are not designed to tell you when a scenario quietly stopped running. This guide explains how Make behaves when something goes wrong, then shows how to add an external heartbeat so you're alerted in both cases.

How Make handles a failing module

When a module outputs an error and there's no error handler on it, Make's default is the Rollback behaviour. The run stops, changes in transaction-capable modules (the ones labelled "ACID", such as Data Store or MySQL) are reverted, and the run ends with an Error status. Actions with no transactions, like sending an email, are not undone.

You can attach one of five error handlers to a module (right-click → Add error handler):

Note the status column. Skip and Resume end with a Success status even though something failed. That's their job, but it also means nothing in the scenario history looks wrong.

An error-handling route doesn't need a handler at all. You can put a single Slack → Create a message module on the route to get a notification. Make's docs say that if no module on the route outputs an error, the original error is skipped.

Incomplete executions and auto-deactivation

Store incomplete executions is off by default (Scenario settings, the gear icon). When it's on, a failed run is saved in the Incomplete executions tab so you can fix and resume it, and scenario errors turn into warnings. Make can retry some error types automatically. Two things to know:

• With Process data in order enabled, Make won't start new runs until the incomplete executions are resolved. One stuck run can pause the whole scenario.
• If the incomplete-executions storage is full and data loss isn't allowed, Make disables the scenario.

The Number of consecutive errors setting (default 3) controls when Make switches off a scheduled scenario that keeps erroring. There are exceptions. A scenario that starts with an instant trigger (a webhook) is deactivated on the first error. Errors such as AccountValidationError, OperationsLimitExceededError and DataSizeLimitExceededError disable scheduling immediately. Warnings never count.

By default Make emails you when an error stops a run and when it deactivates a scenario (Profile → Email preferences, per organization; warning emails are opt-in). Keep those on. But a deactivated scenario runs nothing from then on, and nothing about "no runs" generates a new error. If the one email went to a shared inbox or spam, nothing else will remind you.

The gap: runs that never happen

None of the above fires when:

• the scenario was switched off (by Make or by a teammate) and nobody noticed the email,
• the schedule was changed while editing,
• the trigger has no new data because the upstream app stopped sending webhooks or the connection to it broke,
• the organization ran out of operations or credits,
• a Skip or Resume handler hid the failure, so every run "succeeds" without doing the work.

A heartbeat closes the gap. You add a final HTTP module that pings an external monitor after the work is done. If the ping doesn't arrive on time, something upstream didn't happen.

Step 1: create the monitor

In Flowhush, click New monitor:

• Name: e.g. Make: Shopify → Sheets orders
• Expected every (seconds): the scenario's schedule interval, e.g. 900 for every 15 minutes
• Grace period (seconds): how late a run may be, e.g. 600

Copy the ping URL: https://flowhush.com/p/YOUR-MONITOR-UUID.

Step 2: add the heartbeat module

At the end of the success path, add HTTP → Make a request:

Authentication type: No authentication
URL: https://flowhush.com/p/YOUR-MONITOR-UUID
Method: GET
Parse response: No

That's a plain heartbeat. To have Flowhush check the data the scenario produced (Pro plan: non-empty, valid JSON, required keys), POST it instead:

URL: https://flowhush.com/p/YOUR-MONITOR-UUID
Method: POST
Body content type: application/JSON
Body input method: JSON string
Body content: {"orders_synced": {{length(2.array)}}, "last_id": "{{2.id}}"}

Replace the mapped values with fields from your own modules. If you use the Data structure input method instead, Make escapes reserved JSON characters for you, which avoids accidentally invalid JSON.

Watch out for iterators. The HTTP module runs once per bundle that reaches it. If it sits after an Iterator, you'll send one ping per item. That's harmless for a heartbeat but noisy in the ping history. Put it after an aggregator, or on a route that receives a single bundle.

Step 3: report errors with /fail

Right-click the module most likely to fail (usually the external API call) and choose Add error handler. On the error route, add another HTTP → Make a request:

URL: https://flowhush.com/p/YOUR-MONITOR-UUID/fail
Method: POST
Body content type: application/JSON
Body input method: JSON string
Body content: {"error": "{{error.message}}", "module": "Create spreadsheet row"}

Map the error text from the error bundle in the mapping panel (shown above as {{error.message}}). The first module on an error route receives the error details. Then decide how the run should end. You can follow it with a Commit or Rollback handler, or leave the route as is, in which case Make skips the error. If the message might contain quotes, use the Data structure input method so the JSON stays valid.

A /fail ping marks the monitor down immediately and sends one alert. The first 1 KB of the body is kept with the ping, so you can see error.message in Flowhush without opening Make. The next successful heartbeat sends a recovery alert.

Step 4: test it

From a terminal:

# success
curl -fsS -m 10 https://flowhush.com/p/YOUR-MONITOR-UUID
# explicit failure with a message
curl -fsS -m 10 -X POST -H 'Content-Type: application/json' \
  -d '{"error":"test failure"}' https://flowhush.com/p/YOUR-MONITOR-UUID/fail

Then run the scenario once with Run once and confirm the ping shows up under the monitor's Recent pings. Use Send test alert on the monitor page to check that your alert channel works.

Choosing the interval for webhook-triggered scenarios

Scheduled scenarios are easy: period = schedule interval. Instant (webhook) scenarios run when data arrives, so set the period to the longest normal quiet time. If orders arrive at least every hour during the day but not at night, a 12-hour period with a 2-hour grace catches a dead webhook by the next morning without paging you every night. Flowhush periods run from the last successful ping, not from a cron schedule, so pick the longest gap you consider normal.

The same setup in n8n

Many teams run Make and n8n side by side. One Flowhush account can monitor both, and the pattern is the same. In n8n, the equivalent of the final HTTP → Make a request module is an HTTP Request node at the end of the workflow:

Method: POST
URL: https://flowhush.com/p/YOUR-MONITOR-UUID
Send Body: on
Body Content Type: JSON
Specify Body: Using JSON
JSON: {{ JSON.stringify($json) }}
Settings → Execute Once: on
Settings → Retry On Fail: on
Settings → On Error: Continue

Use GET with no body if the monitor has no output checks. Point an error workflow's HTTP Request node at the same URL with /fail appended. See the n8n guide for the full setup.

Summary

• Keep Make's own tools: error handlers for recovery, incomplete executions for important data, and error emails.
• Add a final HTTP ping so a scenario that stops running is detected by its silence.
• Add a /fail ping on the error route for immediate, specific alerts.
• POST the result to have empty or malformed output flagged (Pro and Team).

You can start on the Free plan: 5 monitors, alerts by email, Slack, Discord or Telegram, with no card required.