
A note from the founder. Hitting the Cron Triggers cap or need retries and alerts Cloudflare doesn't offer? I'm looking for a small group of early users to try Runhooks and share honest feedback. Early adopters get upgraded plans for free.
If you just want the numbers for Cloudflare Workers Cron Triggers — how many you get, how often they can fire, and what they cost — this is the reference. The short version: Cron Triggers are capped per Worker, run at a one-minute minimum, and include no retries or alerting. Here are the details, and what to do when they aren't enough.
Cron Triggers Limits at a Glance
| Limit | Free plan | Workers Paid ($5/mo) |
|---|---|---|
| Cron Triggers per Worker | Up to 3 | Up to 5 |
| Minimum interval (granularity) | 1 minute | 1 minute |
| Automatic retries on failure | ❌ | ❌ |
| Built-in failure alerts | ❌ | ❌ |
| Execution cost | Counts against daily request allowance | Counts against included requests + CPU-ms |
Platform limits change over time. Treat this as a 2026 snapshot and confirm the live numbers in Cloudflare's official Workers documentation before you architect around them.
How Many Cron Triggers Per Worker?
The limit that surprises people most: Cron Triggers are capped per Worker, not per account. You get up to 3 on the Free plan and up to 5 on the Workers Paid plan. Each trigger is one cron expression in your wrangler.toml:
name = "my-worker"
main = "src/index.ts"
[triggers]
crons = ["0 * * * *", "*/15 * * * *", "0 0 * * *"] # 3 schedules — the Free cap
All triggers on a Worker invoke the same scheduled() handler, and your code branches on event.cron to decide what to do:
export default {
async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext) {
switch (event.cron) {
case "0 * * * *": await hourlySync(env); break;
case "*/15 * * * *": await pollQueue(env); break;
case "0 0 * * *": await dailyReport(env); break;
}
},
};
If you need more than 3–5 independent schedules, your options are to split work across multiple Workers (each with its own cap) or to trigger the Worker externally, which removes the cap entirely.
The 1-Minute Minimum Interval
Cron Triggers have a granularity of one minute. The most frequent schedule you can express is * * * * * (every minute) — there is no way to fire a Worker every 30 seconds with Cron Triggers. If your workload needs sub-minute cadence or precise second-level timing, Cron Triggers are the wrong tool, and an external HTTP trigger is the standard workaround.
What Cron Triggers Cost
The Cron Triggers feature carries no separate charge. What you pay for is the invocation: each scheduled run executes your scheduled() handler, and that counts against your normal Workers usage.
- Free plan: scheduled invocations draw from your daily request allowance and are subject to Free-tier CPU limits.
- Workers Paid ($5/month): invocations draw from your included monthly requests and CPU-milliseconds.
Because the exact request and CPU numbers shift as Cloudflare updates its plans, check the current figures on Cloudflare's Workers pricing page rather than trusting a number you read in a blog post — including this one.
What Cron Triggers Don't Include
This is where teams get caught. Cron Triggers start your Worker on schedule; they do not make scheduled execution reliable. Missing by design:
- No automatic retries. If a scheduled invocation throws or times out, it's gone until the next tick. There is no built-in second attempt.
- No failure alerting. Cloudflare won't tell you a scheduled run failed. You find out by checking, or by noticing the downstream effect.
- No durable execution history. You get dashboard metrics and logs, but not a persistent, per-run record of status, response, and duration out of the box.
- A hard per-Worker cap. The 3–5 trigger limit is a real ceiling on how many distinct schedules one Worker can own.
For a nightly cache purge, none of this matters. For a billing sync or a data export where a missed run has consequences, all of it does. We cover the reliability angle in depth in Scheduling Cloudflare Workers Beyond Cron Triggers.
When Cron Triggers Are Enough
Use Cron Triggers as-is when: you need 5 or fewer schedules per Worker, a one-minute floor is fine, the work is idempotent, and an occasional missed run without an alert is acceptable. That covers a lot of legitimate use cases — cache warming, cleanup, periodic recomputation — and it's the simplest possible setup.
When to Trigger the Worker Externally
Reach past Cron Triggers when you need more than 5 schedules, sub-minute or precise timing, automatic retries, execution logs, or failure alerts. The workaround is simple because a Worker is already an HTTP endpoint: give it a fetch() handler and let an external scheduler call it on whatever schedule you want.
How Runhooks Fits In
Runhooks calls your Worker's URL on a schedule and adds the reliability layer Cron Triggers lack:
- Create a job pointed at your Worker's
fetch()URL. - Set any schedule — no 3–5 cap, and timing isn't bound to a one-minute floor across jobs.
- Enable retries — a transient failure gets another attempt instead of vanishing.
- Get logs and alerts — every run recorded with status and duration, with a notification when it fails.
Keep a Cron Trigger as a fallback if you like; the external trigger becomes your primary, reliable path. For the full setup, see Scheduling Cloudflare Workers Beyond Cron Triggers, and for how this compares to other managed schedulers, our best cron job services comparison.
Get Started
Cron Triggers are a fine starting point and a poor finish line. Once you outgrow the caps or need to know when a run fails:
- Give your Worker a
fetch()endpoint. - Try Runhooks free and trigger it on any schedule with retries, logs, and alerts.
- Model your schedule first with the cron expression visualizer.
Frequently Asked Questions
How many Cron Triggers can a Cloudflare Worker have?
Cloudflare allows up to 3 Cron Triggers per Worker on the Free plan and up to 5 per Worker on the Workers Paid plan. The limit is per Worker, not per account — if you need more independent schedules, you split them across multiple Workers or trigger the Worker externally over HTTP. Always confirm the current number against Cloudflare's official docs, as platform limits change.
What is the minimum interval for Cloudflare Workers Cron Triggers?
Cron Triggers have a granularity of one minute — the most frequent schedule you can set is every minute (* * * * *). You cannot trigger a Worker more than once per minute using Cron Triggers. For sub-minute or more precise timing, you trigger the Worker's HTTP endpoint from an external scheduler instead.
Do Cloudflare Cron Triggers cost extra?
The Cron Triggers feature itself has no separate charge. Each scheduled invocation runs your Worker's scheduled() handler, which counts against your normal Workers usage — requests and CPU time. On the Free plan that's the daily request allowance; on the Workers Paid plan ($5/month) it draws from your included requests and CPU-milliseconds. Verify current quotas in Cloudflare's pricing docs.
Do Cloudflare Cron Triggers have retries or failure alerts?
No. If a scheduled invocation throws or times out, Cloudflare does not automatically retry it and does not send a failure alert — the run is simply lost until the next scheduled tick. You get basic invocation data in the dashboard and logs, but retries, execution history, and alerting are things you add yourself or get from an external scheduler like Runhooks.
How do I run a Cloudflare Worker more often or more reliably than Cron Triggers allow?
Expose the Worker as a normal fetch() HTTP endpoint and trigger it from an external scheduler. This bypasses the 3–5 trigger cap and the 1-minute floor, and adds retries, execution logs, and failure alerts that Cron Triggers don't include. Runhooks does exactly this by calling your Worker's URL on any schedule you define.
Read next: Scheduling Cloudflare Workers Beyond Cron Triggers · Vercel Hobby Cron Job Limits Explained · Best External Cron Job Services Compared