You built a Make scenario, dropped a Schedule trigger at the top, and set it to every 5 minutes. Then you opened the Subscription page and noticed something inconvenient: the Schedule trigger counts as an operation every single time it fires, whether the scenario goes on to do real work or not. A 5-minute scenario burns roughly 8,640 ops a month before any logic runs. On the Core plan that is more than half of your monthly budget gone to "is anything new yet?" polling. Here is the pattern Make-heavy teams reach for: keep the scenario, drop the internal schedule, replace the trigger with a Custom Webhook, and let an external cron fire the webhook only when you want the scenario to run.
If you want the short version: change the first module from Schedule to Webhooks > Custom webhook, copy the webhook URL Make gives you, and point Crontap at it on whatever cadence you actually want (every 1 minute on Pro, per IANA timezone, with failure alerts wired into Slack or Discord). Make only spends ops when the scenario actually executes, and you can change the cadence from a dropdown without touching the scenario.
How Make's internal scheduling charges you
Make scenarios are billed in operations. An operation is roughly "one module successfully processing one bundle". Crucially, the Schedule trigger itself counts as one operation per fire, even when the scenario then exits because nothing changed downstream.
That sounds fine until you do the cadence math.
| Cadence | Fires per day | Fires per month | Ops per month (no real work) | |---|---|---|---| | Every 15 minutes | 96 | 2,880 | 2,880 | | Every 5 minutes | 288 | 8,640 | 8,640 | | Every 1 minute | 1,440 | 43,200 | 43,200 |
The Make plans (as of Make's pricing page) start at 10,000 ops/month on the cheapest paid tier and scale from there. A single 5-minute scenario consumes 8,640 of those just by ticking. A 1-minute scenario blows through any starter plan before lunch.
You can argue that a polling scenario is "doing work" on every tick (it is asking the upstream API "anything new?"), and that is fair. But for the very common shape of "a scheduled cron that should fire my downstream automation regardless of upstream state", the Schedule trigger is the wrong primitive. It is paying for a clock you can rent for free elsewhere.
Why webhook-first scenarios are the cleaner shape
Make has a primitive that fits this shape perfectly: the Custom Webhook trigger. When the first module is a webhook:
- Make does not consume an operation while idle. The scenario sits dormant until an HTTP request hits the webhook URL.
- The first operation is charged when Make actually starts processing the incoming bundle.
- Each downstream module charges an operation per bundle, exactly the same as before.
Compared to a Schedule trigger, the difference is one number. A 5-minute scenario that was burning 8,640 ops/month on the internal schedule burns 0 ops/month from idle. The downstream modules still cost what they cost when the scenario actually runs, which is the part you wanted to pay for anyway.
The only thing missing is the clock. That is what Crontap is for.
The Crontap + Make Webhook URL pattern
Here is the shape we recommend. It works for any scenario, on any Make plan, at any cadence the target supports.
Crontap (cron) → HTTPS POST → Make Custom Webhook URL → the rest of your scenario
Make still owns the scenario runtime. Crontap owns the clock. The contract between them is one HTTPS request per cadence.
Step 1: Replace the Schedule trigger with a Custom Webhook
Open the scenario in the Make editor, click the first module (the Schedule trigger), and either delete it or right-click and choose Replace. Pick Webhooks > Custom webhook as the new first module.
If this is a brand new scenario, just add a Custom Webhook as the first module from the start.
Step 2: Copy the webhook URL
Inside the Custom Webhook configuration:
- Click Add to create a new webhook.
- Give it a name that matches the scenario (e.g.
crontap-trigger-orders-sync). - Save.
- Make displays a URL that looks like
https://hook.eu2.make.com/<long random string>. Copy this.
Make's webhook URLs are unguessable random strings, so the URL itself is the secret in this pattern. If you want a second factor, you can add a header check inside the scenario (read Authorization from the bundle and short-circuit if it doesn't match), but for most teams the random URL is enough.
Step 3: Point Crontap at the webhook URL
Head to Crontap and create a new schedule.
- URL. Paste the Make webhook URL.
- Method.
POST(Make's webhook trigger accepts both GET and POST; POST is the default). - Headers. Optional. If you added a header check inside the scenario, add it here. Crontap stores header values encrypted.
- Body. Optional. Anything you put here lands in the scenario as a parsed bundle, so this is where you can pass per-cadence parameters ("which tenant should this run for", "what date range", etc.) without rebuilding the scenario for each variant.
- Cadence. Type plain English ("every 5 minutes") or paste a cron expression. Crontap previews the next 5 fires inline so you can sanity-check before saving.
- Timezone. Pick the IANA zone the schedule actually runs in. Make scenarios are timezone-agnostic; the scheduler decides when "every weekday at 9am" means.
- Failure alerts. Add an integration: email / webhook (Slack / Discord / Telegram). Crontap fires on 4xx and 5xx with the response body and timing in the payload, so a Slack alert lands the moment Make returns a non-2xx.
Press Perform test to fire a real request before you trust the cadence. If Make returns 200, the scenario started and you can confirm in Make's history that the run happened. If you see something else, check the webhook URL and the optional header.
Fix this in 60 seconds with Crontap. Free tier available. No credit card. Schedule your first job.
Worked example: a 5-minute scenario, costed both ways
Take a Make.com user running a multi-step scenario on a custom cadence. The scenario polls a third-party API every 5 minutes, transforms the response, and pushes the result into Google Sheets and Slack. The scenario itself is 6 modules end to end.
Old shape (Schedule trigger every 5 minutes).
- Schedule trigger fires 288 times a day, 8,640 times a month.
- On most ticks, the upstream API has nothing new and the scenario filters down to 0 bundles after the first transformation. That still consumes the Schedule trigger op (8,640 ops/month).
- On the ~10% of ticks where there is real work, all 6 modules run (so ~864 real-work fires * 6 = 5,184 ops).
- Total: 8,640 + 5,184 = 13,824 ops/month for ~864 real runs. Most of that is paid for ticking the clock.
New shape (Custom Webhook + Crontap every 5 minutes).
- Crontap fires the webhook 8,640 times a month. Make does not charge for the clock; the first operation is charged when the webhook actually receives the bundle.
- The scenario runs 8,640 times a month and processes the same bundles. Most ticks still filter to 0 bundles after the first transformation, but Make only counts the operations that actually run.
- If you want to be smarter, you can do the upstream "is there anything new" check on your own backend first and only fire the Make webhook when there genuinely is. Now you cut Make ops by another 90%.
- Total: roughly 5,184 ops/month if you keep polling all 8,640 times, or as low as ~520 ops/month if you put the "is anything new" check upstream and only fire the webhook when needed.
Either way, you stop paying Make to ask "is anything new yet?" thousands of times a month.
When to keep Make's internal Schedule trigger
External cron is a shape, not a religion. There are cases where Make's built-in Schedule trigger is exactly the right primitive:
- One-shot daily runs. A scenario that fires once a day at 9am is 30 ops/month from the Schedule trigger. You will not feel that in any plan.
- Scenarios where the trigger is doing real work. If the first module is "Search rows in Airtable where status = pending" and that genuinely is the work the scenario exists to do, the Schedule trigger is fine. Replacing it with a webhook gains nothing.
- Scenarios you want fully owned by Make. If your team's mental model is "Make is the automation platform end to end", keeping the schedule inside Make is the simplest answer. You pay slightly more in ops; you get one tab to look at.
- Scenarios using the Schedule trigger's "On demand" mode. Some teams use the Schedule trigger to gate scenarios that should only run when manually fired or on tight sub-cadences. External cron does the same job more cleanly, but the migration is not free.
For everything else, especially anything sub-hourly, the Crontap + Custom Webhook pattern is cheaper and more flexible.
What about the existing Make + Crontap how-to?
If you already have a scenario and want the click-by-click version of "wire Crontap into Make", we have a separate post with screenshots: Integrate Crontap with Make webhooks. That post is the setup walkthrough. This post is the cost-math angle: why you would do it in the first place, and how the operations bill changes.
FAQ
Does this work for scenarios that already use a webhook trigger?
Yes, and it is the easiest case. If your scenario already starts with Webhooks > Custom webhook, just point Crontap at the existing webhook URL on whatever cadence you want. No edit inside Make is needed.
Can Crontap fire a Make scenario every minute?
Yes. Crontap's minimum cadence is every 1 minute on Pro at $3.25/mo billed annually. Make's webhook trigger accepts as many requests as you send it; the rate limit you will hit first is your downstream modules, not the webhook itself.
Will the scenario run if Make is down?
If Make's webhook endpoint is unreachable, Crontap records a 5xx (or a connection timeout) and fires the failure alert via email / webhook (Slack / Discord / Telegram). The scenario doesn't run for that tick. Crontap retries based on your retry policy on the next scheduled fire.
What about scenarios with multiple Schedule triggers?
Make scenarios can only have one trigger module, so this question usually means "I have several scenarios on a Schedule trigger". The migration is one webhook trigger and one Crontap schedule per scenario. Nothing else changes about the scenario internals.
Can I pass different inputs on different cadences?
Yes. Crontap lets you set a different request body per schedule. So if you want the same scenario to run every hour for tenant A and every 15 minutes for tenant B, that is two Crontap schedules pointing at the same webhook URL with different bodies. Inside the scenario, parse the bundle and route on tenant id.
How do I keep the scenario's logs alongside the cron logs?
Make's history view shows every run with its bundle and module-level timing. Crontap's history view shows every fire with HTTP status, response body, and latency. The two are linked by timestamp. Most teams open both tabs side by side when debugging; the Crontap alert that fires on a non-2xx links straight to the failed scenario run in Make.
References
Related on Crontap
- Cron jobs for Make scenarios. The Make-specific guide to running scenarios on any external cadence without burning ops on the internal Schedule trigger.
- Integrate Crontap with Make webhooks. The click-by-click setup walkthrough with screenshots; pair it with this post for the why-and-the-how.
- The Zapier Schedule task cost math. The same operations-vs-clock argument applied to Zapier; if you run both platforms, the wedge is identical.