Cloudflare Cron Triggers: Free Plan Limits & Pricing 2026

Q: 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.

Cloudflare Workers Cron Triggers Limits

TL;DR. Cloudflare Workers Cron Triggers are capped at 3 per Worker (5 on paid), fire no more than once per minute, and offer no retries or failure alerts. To exceed those limits, expose your Worker as a fetch() endpoint and trigger it from an external HTTP scheduler instead.

Your scheduled Worker stopped firing, or you went to add another Cron Trigger and Cloudflare refused the deploy. Both trace back to the same limits: Cron Triggers are capped at 3 per Worker on the Free plan and 5 on Workers Paid, they fire no more than once per minute, and they include no retries and no failure alerts — so a scheduled run that throws is simply lost, with nothing to tell you. Those numbers aren't going to change, but every one of them has a workaround. This guide covers what to do about each limit first, then gives you the full reference below.

Why Cron Triggers Stop Firing or Refuse a New Schedule

The symptoms people actually hit trace back to three distinct limits, and all three are properties of the Cron Triggers feature itself — not of your Worker's code:

You can't add another trigger. Cron Triggers are capped per Worker, not per account: 3 on the Free plan, 5 on Workers Paid. Deploy a Worker with a fourth (or sixth) cron expression and Cloudflare rejects it.
A scheduled run silently disappears. If a scheduled invocation throws or exceeds its CPU time, Cloudflare does not retry it and does not alert you. The run is gone until the next tick, and nothing signals that it failed.
It won't fire more than once a minute. The granularity is one minute, so * * * * * is the ceiling — there is no way to schedule a Worker every 30 seconds with Cron Triggers.

None of this is a bug. Cron Triggers exist to start your Worker on a schedule cheaply; they were never designed to make scheduled execution reliable or high-frequency. For a nightly cache purge that's a fair trade. For a billing sync or a data export where a skipped run has consequences, it isn't.

What to Do When You Hit the Cron Triggers Limits

You have three realistic options, depending on which limit is blocking you:

Split the work across multiple Workers. Each Worker gets its own 3–5 trigger allowance, so moving some schedules onto a second Worker buys you more triggers. It's free and fully native — but it multiplies the Workers you deploy and maintain, and it does nothing about the missing retries, the missing alerts, or the one-minute floor.

Keep the built-in trigger — if the job is low-stakes. For an idempotent cache warm or cleanup where an occasional missed run without an alert is acceptable, Cron Triggers as-is are the simplest possible setup and worth keeping. Reach past them only when timing accuracy, guaranteed execution, or failure alerting actually matter.

Trigger the Worker externally over HTTP. A Worker is already an HTTP endpoint — give it a fetch() handler and let an external scheduler call it on whatever schedule you want. This removes the per-Worker cap entirely, breaks the one-minute floor, and adds the retries, execution logs, and failure alerts the built-in trigger lacks. It's the same pattern we walk through in Scheduling Cloudflare Workers Beyond Cron Triggers.

That last option is what Runhooks is built for: it calls your Worker's fetch() URL on any schedule — no 3–5 cap, no one-minute floor — retries a transient failure instead of losing the run, and records every execution with a notification when one fails. Keep a Cron Trigger as a fallback if you like; the external trigger becomes your primary, reliable path. For how this compares to other managed schedulers, see our best cron job services comparison.

The Exact Limits, Pricing & Granularity (2026 Reference)

Everything below is the full specification — the caps, the one-minute floor, what each invocation costs, and what the feature does not include. The facts are unchanged; they're just no longer the lead.

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.

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

What are the Cloudflare Workers Cron Triggers free plan limits in 2026?

On the Free plan, a Worker can have up to 3 Cron Triggers, each firing no more than once per minute, with no automatic retries and no failure alerts; every scheduled run counts against your daily free request allowance. The Workers Paid plan ($5/month) raises the cap to 5 triggers per Worker. These are the current 2026 limits — always confirm against Cloudflare's official docs, as platform limits change.

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.

Are Cloudflare Workers Cron Triggers free, and what do they cost?

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.