PulseProbe

Automation monitoring guides

Make.com guide

How to Get Alerted When a Make.com Scenario Stops Running

Make scenarios can run on schedules, from instant triggers, or on demand. Built-in history and error handling are useful, but an external heartbeat catches the business symptom: the scenario did not finish when expected.

Short answer

For a Make.com scenario that should run on a schedule, add an HTTP request near the final successful path. If PulseProbe does not receive that check-in on time, it marks the scenario as missed and sends an alert.

Last reviewed: June 10, 2026PulseProbe is not an official Make.com integration or partner. It receives a standard HTTP check-in from scenarios that can make outbound HTTP requests.

Why Make scenarios can appear silent

A scheduled scenario may be inactive, delayed, blocked by an error, waiting on an incomplete execution, or not seeing new trigger data. The business owner usually notices the outcome: a report did not send, a lead did not route, or a sync did not finish.

Make errors vs missed expected runs

Make error handling is useful when a module outputs an error and you want to recover, retry, skip, or route around it. Heartbeat monitoring is useful when the expected final completion signal does not arrive.

Step-by-step setup

  1. 1Create a PulseProbe probe for the Make scenario.
  2. 2Match the expected interval to the scenario schedule, with enough grace time for queueing and retries.
  3. 3Copy the heartbeat URL from PulseProbe.
  4. 4Add an HTTP module or HTTP request step near the end of the scenario.
  5. 5Call the heartbeat URL only after the important modules complete successfully.
  6. 6Run the scenario once and confirm PulseProbe records a recent check-in.

Recommended grace windows

  • For a scenario scheduled every 15 minutes, start with a grace window that allows for normal platform delay and run duration.
  • For hourly or daily scenarios, use a wider grace window if upstream apps are sometimes slow.
  • If the scenario has retries or incomplete execution handling, account for that before alerting.

Common mistakes

  • Putting the heartbeat before routers, filters, or modules that can still fail.
  • Monitoring a polling check run that found no new data when you actually care about completed business work.
  • Using one probe for scenarios with different schedules.
  • Setting the expected interval to the fastest possible run instead of the real schedule.

How to test the setup

  1. 1Run the scenario once and confirm the HTTP request succeeds.
  2. 2Verify a fresh check-in in PulseProbe.
  3. 3Temporarily disable or stop the scenario only when it is safe.
  4. 4Wait for the interval and grace window, then confirm the missed alert.
  5. 5Re-enable the scenario and confirm PulseProbe records recovery after the next check-in.

When not to use PulseProbe

  • Do not use heartbeat monitoring as the only control for safety-critical, medical, emergency, financial trading, or regulated systems.
  • Do not send secrets, customer records, prompt text, API keys, or private payloads to the heartbeat URL.
  • Heartbeat monitoring proves a check-in arrived. It does not inspect the quality of the workflow output.

FAQ

Can Make error handlers replace heartbeat monitoring?

No. Error handlers help when a module errors during a run. Heartbeat monitoring helps when the final expected completion check-in does not arrive.

Should the heartbeat run on every route?

Only on routes that represent successful completion of the work you care about. Separate routes may need separate probes.

Can I send scenario data to PulseProbe?

Use the heartbeat URL as a completion signal. Avoid sending customer data, secrets, or private payloads.