Monitor Cron Jobs and Scheduled Make.com Scenarios with CronPeek

Make.com (formerly Integromat) lets you build powerful automated workflows that run on a schedule. But when a scenario fails silently at 3 AM—an expired API token, a rate limit hit, or a scenario accidentally toggled off—how do you know? Make.com's built-in error handling catches errors that happen. It cannot detect scenarios that never ran in the first place. This guide shows you how to add dead man's switch monitoring to Make.com scenarios, Zapier Zaps, and IFTTT applets so you find out immediately when any no-code automation stops working.

Why Make.com Scenarios Fail Silently

Make.com is a visual automation platform. You connect modules into a scenario, set a schedule, and let it run. It works well—until it does not. Here are the failure modes that catch automation builders off guard:

• API rate limits. Your scenario hits a third-party API rate limit at 2 AM. The HTTP module returns a 429 status. Depending on your error handling configuration, Make.com may retry, skip, or stop the scenario entirely. If you do not have error notifications configured, this failure is invisible.
• Expired authentication tokens. OAuth tokens expire. API keys get rotated. A connected app revokes access. The scenario fails on the first module and Make.com logs the error, but unless you check the execution history regularly, you will not notice for days or weeks.
• Scenario disabled accidentally. Someone on your team opens the scenario editor, makes a change, and forgets to re-enable scheduling. Or Make.com disables the scenario automatically after consecutive failures. The scenario is off. No error is thrown because nothing executes.
• Operation limit reached. Make.com plans have monthly operation limits. Once you hit the cap, scenarios stop executing until the billing cycle resets. No error is raised for individual scenarios—they simply do not run.
• Upstream service outage. The external service your scenario depends on goes down for maintenance. The scenario runs, the HTTP request times out, and Make.com records a failed execution. If you have not set up error notifications, the data that was supposed to sync at midnight is missing when your team arrives in the morning.
• Webhook trigger misfire. If your scenario uses a webhook trigger instead of a schedule, the source system may stop sending webhooks without any indication. A deployment on the source side, a firewall change, or a URL rotation breaks the integration silently.

Make.com does have built-in email notifications for scenario errors, but these only fire when a scenario runs and fails. They do not fire when a scenario does not run at all—which is often the more dangerous failure mode.

How the Dead Man's Switch Works

The concept is borrowed from railroad engineering. A dead man's switch is a mechanism that triggers when the operator stops actively pressing it. Applied to automation monitoring, it works like this:

1. You create a CronPeek monitor with an expected interval (e.g., every 24 hours) and a grace period (e.g., 15 minutes).
2. At the end of your Make.com scenario—after all the real work is done—you add an HTTP module that sends a ping to CronPeek.
3. CronPeek expects that ping at the interval you configured. As long as the ping arrives within the window, everything is green.
4. If the ping stops arriving—for any reason—CronPeek sends you an alert via email or webhook.

This approach catches every failure mode listed above. API rate limits, expired tokens, disabled scenarios, operation limits, upstream outages—all of them result in the ping not arriving, which triggers the alert. You do not need to anticipate every failure. You just need to detect the absence of success.

Step 1: Create a CronPeek Monitor

First, create a monitor for your Make.com scenario using the CronPeek API. Set the interval to match your scenario's schedule and the grace_period to account for execution time variability.

curl -X POST https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Make.com Daily Invoice Sync",
    "interval": 86400,
    "grace_period": 900
  }'

The response gives you a ping_url:

{
  "id": "mon_m7x3k9p2w5",
  "name": "Make.com Daily Invoice Sync",
  "ping_url": "https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/ping/mon_m7x3k9p2w5",
  "status": "waiting",
  "interval": 86400,
  "grace_period": 900
}

Save the ping_url. You will use it in the HTTP module inside your Make.com scenario. Set interval to your expected run frequency in seconds (86400 = daily, 3600 = hourly). Set grace_period to how long after the deadline CronPeek should wait before alerting.

Step 2: Build the Make.com Scenario (Node by Node)

Let us walk through a complete Make.com scenario for a daily invoice sync, with CronPeek monitoring wired in. The scenario pulls new invoices from Stripe, syncs them to QuickBooks, and pings CronPeek on success.

Node 1: Schedule Trigger

Every Make.com scenario starts with a trigger. For scheduled workflows, use the Scheduling trigger module.

• Set the interval to Once a day.
• Set the time to 08:00 AM UTC (or whenever your business day starts).
• Make sure the scenario is set to On in the scheduling section at the bottom of the editor.

Node 2: Stripe — List Invoices

Add a Stripe > List Invoices module. Configure it to pull invoices created since the last run. Use Make.com's built-in date functions to filter by created[gte] set to {{formatDate(addDays(now; -1); "X")}}, which gives you all invoices from the last 24 hours as a Unix timestamp.

Node 3: Iterator

Add an Iterator module to loop over the array of invoices returned by Stripe. Each invoice is processed individually in the subsequent modules.

Node 4: QuickBooks — Create Invoice

Add a QuickBooks Online > Create Invoice module. Map the Stripe invoice fields (customer name, line items, amount, currency) to the corresponding QuickBooks fields. Make.com's visual mapper makes this straightforward—drag fields from the Stripe output into the QuickBooks input.

Node 5: Router (Optional)

If you want to add a Slack notification or email confirmation for each synced invoice, add a Router module after the QuickBooks module. One route continues to the aggregator; the other sends a notification. Routers let you branch your scenario without duplicating modules.

Node 6: Aggregator

After the iterator finishes, add a Numeric Aggregator or Array Aggregator to collect the results. This gives you a count of how many invoices were synced, which is useful for the CronPeek status message.

Node 7: HTTP — Ping CronPeek (Success)

This is the critical module. Add an HTTP > Make a request module at the very end of your scenario.

URL:    https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/ping/mon_m7x3k9p2w5
Method: GET
Headers: (none needed)
Query String:
  status = success
  msg    = {{length}} invoices synced

Placement matters. This module must be the last module in the success path. If any prior module fails—Stripe returns an error, QuickBooks rejects an invoice, the iterator encounters bad data—Make.com stops execution before reaching the HTTP ping module. The ping never arrives. CronPeek alerts you after the grace period. That is exactly the behavior you want.

Step 3: Add Error Routing for Immediate Failure Alerts

The dead man's switch catches scenarios that do not run. But what about scenarios that run and fail? By default, you will wait until the next expected run window plus the grace period before CronPeek alerts you. For critical workflows, that delay is too long.

Make.com has a built-in error routing feature. Right-click any module and select Add error handler. This creates a parallel error route that executes when that module throws an error.

Setting up the error route

1. Right-click the module most likely to fail (e.g., the Stripe or QuickBooks module).
2. Select Add error handler.
3. On the error route, add an HTTP > Make a request module.
4. Configure it to ping CronPeek with a failure status:

URL:    https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/ping/mon_m7x3k9p2w5
Method: GET
Query String:
  status = failure
  msg    = {{error.message}}

Now you get two layers of protection. If the scenario runs and an individual module fails, the error route fires and CronPeek receives an immediate failure ping. If the scenario does not run at all, the dead man's switch kicks in after the grace period. Both failure modes are covered.

Add a Resume directive

After the error handler's HTTP module, add a Resume directive module. This tells Make.com to continue executing the remaining modules in the main route (if possible) after handling the error. Without a Resume directive, the error route terminates the scenario execution at that point. Whether you want Resume or Break depends on your use case—for invoice syncing, you typically want to continue processing the remaining invoices even if one fails.

Example Scenarios to Monitor

Here are common Make.com automation patterns and the CronPeek monitor configuration that matches each one.

The grace period should account for the longest realistic execution time of your scenario plus some buffer. A scenario that normally takes 2 minutes to run should have at least a 10-minute grace period to handle occasional slowness from upstream APIs.

Monitoring Zapier Zaps with CronPeek

The same dead man's switch pattern works with Zapier. Zapier Zaps that run on a schedule (using the Schedule by Zapier trigger) or that are triggered by polling (most Zapier triggers poll every 1 to 15 minutes) can silently stop working when connections expire, the Zap is paused, or your Zapier plan hits its task limit.

Adding a CronPeek ping to a Zapier Zap

1. Open your Zap in the Zapier editor.
2. Add a new action step at the very end of the Zap.
3. Choose Webhooks by Zapier as the app.
4. Select Custom Request as the action event.
5. Configure the request:
   • Method: GET
   • URL: https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/ping/YOUR_TOKEN?status=success
   • Headers: Leave empty.
   • Body: Leave empty.
6. Test the step—you should see a 200 OK response from CronPeek.
7. Turn on the Zap.

If any step in the Zap fails before reaching the webhook step, the ping never fires and CronPeek alerts you. If the Zap gets paused or Zapier stops polling the trigger, the ping stops arriving on schedule and CronPeek alerts you.

Monitoring IFTTT Applets with CronPeek

IFTTT (If This Then That) applets are simpler than Make.com scenarios or Zapier Zaps, but they are equally prone to silent failures. IFTTT connections expire, services get disconnected, and applets get disabled after repeated failures. IFTTT Pro users can use the Webhooks service to ping CronPeek.

Adding a CronPeek ping to an IFTTT Applet

1. Create a new applet or edit an existing one.
2. For the Then That action, choose Webhooks > Make a web request.
3. Configure:
   • URL: https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/ping/YOUR_TOKEN?status=success
   • Method: GET
   • Content Type: text/plain
   • Body: Leave empty.
4. Save and enable the applet.

IFTTT's limitation is that most applets only have one action (unless you use IFTTT Pro's multi-action feature). If your applet already has an action (e.g., "send an email"), you need IFTTT Pro to add the CronPeek webhook as a second action. Alternatively, use a Filter code step (IFTTT Pro) to make the HTTP request within a JavaScript filter before the main action.

Advanced: Monitoring Webhook-Triggered Scenarios

Not all Make.com scenarios run on a fixed schedule. Many are triggered by incoming webhooks from services like Stripe, Shopify, or GitHub. These are harder to monitor because there is no fixed interval—the scenario runs whenever the external service sends a webhook.

For webhook-triggered scenarios, use a different CronPeek strategy:

• Set a maximum expected gap. If your Shopify store normally receives at least one order per hour, create a CronPeek monitor with a 2-hour interval. If two hours pass with no ping, something is wrong—either the webhook stopped firing or the scenario is broken.
• Use a separate heartbeat scenario. Create a simple Make.com scenario that runs every hour and pings CronPeek. This monitors that Make.com itself is operational and your account is active. It does not monitor individual webhook scenarios, but it catches account-level issues like operation limits or billing problems.
• Combine with error routing. Even without a fixed schedule, you can add error routes to webhook-triggered scenarios that ping CronPeek with status=failure on errors. This gives you immediate failure alerts without relying on the dead man's switch interval.

Step-by-Step: Quick Start in 5 Minutes

Here is the fastest path from zero to monitored Make.com scenario:

# 1. Create a monitor matching your scenario schedule
curl -X POST https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "make-daily-invoice-sync", "interval": 86400, "grace_period": 1800}'

# Response: {"ping_url": ".../ping/mon_YOUR_TOKEN", ...}

# 2. Set up an email alert for when pings stop
curl -X POST https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/alerts \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "email", "address": "team@yourcompany.com"}'

# 3. In Make.com: add an HTTP module at the END of your scenario
#    URL: https://us-central1-todd-agent-prod.cloudfunctions.net/cronpeekApi/ping/mon_YOUR_TOKEN
#    Method: GET
#    Query: status=success

# 4. Run the scenario manually once to verify the ping registers

# Done. Your Make.com scenario is now monitored.

Start with your most critical scenario—usually the one that handles money (invoice syncing, payment processing, subscription billing). Once you verify the monitoring works, add CronPeek pings to the rest of your scheduled scenarios. See our simple cron monitoring guide for more on getting started, and our dead man's switch deep dive for the theory behind the pattern.

Pricing: CronPeek for No-Code Teams

A typical Make.com workspace has 10 to 30 active scenarios running on schedules. Here is what monitoring all of them costs with CronPeek versus alternatives.

CronPeek's free tier covers your 5 most critical scenarios. The Starter plan at $9/mo covers up to 50 monitors—enough for even large Make.com workspaces. The Pro plan at $29/mo removes the limit entirely, which makes sense if you are monitoring scenarios across Make.com, Zapier, IFTTT, and traditional cron jobs from a single dashboard.