Cloudflare Workers Cron Triggers vs an external scheduler

This is not a "replace Cloudflare" article. If your scheduled work reads and writes KV, D1, R2 or a Queue, a Cron Trigger is usually the best place to start it from. The question is what you need around it: other timezones, retries, a history of runs, or a message when it stops. That is where the two approaches differ.

How Cron Triggers work

You list cron expressions in the Worker's Wrangler configuration and export a scheduled handler. Cloudflare calls that handler on schedule, without an HTTP request from anyone.

[triggers]
# Every 15 minutes, and at 07:00 UTC on weekdays
crons = ["*/15 * * * *", "0 7 * * MON-FRI"]

export default {
  async scheduled(controller, env, ctx) {
    // controller.cron is the expression that fired
    ctx.waitUntil(runJob(env, controller.cron));
  },
};

To try it locally, run wrangler dev and request http://localhost:8787/cdn-cgi/local/scheduled, which runs the scheduled handler once.

The limits

From Cloudflare's Workers limits and pricing pages, October 2026:

CPU time is the time your code actually computes. Waiting for a fetch or a database does not count, which is why 10 ms is enough for a run that mostly calls other services, and not enough for one that parses a large file.

Things that catch people out

• Weekday numbers. Cloudflare counts 1 as Sunday and 7 as Saturday, so 1-5 is Sunday to Thursday. Write MON-FRI.
• UTC only. There is no timezone setting, so a local time shifts by an hour twice a year.
• Changes are not instant. A new or edited schedule can take up to 15 minutes to reach every data centre.
• One account, one pool. The 5 or 250 triggers are shared by every Worker in the account.
• Quiet failures. A run that throws shows up in Trigger Events and Workers Logs, which keep a history but do not message you. Somebody has to look.

When Cron Triggers are the right choice

• The work happens inside Cloudflare: clearing KV keys, rolling up D1 rows, sending a batch to a Queue, pruning R2.
• It is light, or you are on the Paid plan anyway.
• A run that is a little late, or occasionally fails until the next one, does no harm.
• UTC is fine for the schedule.

In that case, keep them. Adding a heartbeat, below, closes the one real gap: knowing when they stop.

When an external scheduler fits better

• The job is not in Cloudflare. If the work is an API call to your own server, a Worker in between only adds a hop. Let the scheduler call the server directly.
• The time matters to people. "Every weekday at 09:00 in Amsterdam" should stay 09:00 after the clocks change.
• Failures need a response. Retries, a record of each run's status and response, and an email or Slack message when it fails.
• You need more than 5 schedules and do not want the Paid plan for that alone.
• Other people change the schedule. In a dashboard, without a deploy and without waiting for it to propagate.

Side by side

Keep Cron Triggers, add a heartbeat

A heartbeat is a URL your job calls when it finishes. The monitoring service expects that call on your schedule and emails you when it does not arrive, or when the job reports a failure. It catches the cases nothing inside the Worker can: a trigger that was removed in a deploy, a run that ran out of CPU time, an exception nobody saw.

Create a heartbeat in CronEngine with the same schedule as the trigger, store its URL as a secret called HEARTBEAT_URL with wrangler secret put HEARTBEAT_URL, and wrap the job:

export default {
  async scheduled(controller, env, ctx) {
    ctx.waitUntil(withHeartbeat(env, () => runJob(env)));
  },
};

async function withHeartbeat(env, job) {
  // A ping that fails must never stop or fail the job itself
  const ping = (suffix = '') => fetch(env.HEARTBEAT_URL + suffix).catch(() => {});

  await ping('/start');
  try {
    await job();
  } catch (error) {
    await ping('/fail');
    throw error;
  }
  await ping();
}

The heartbeat URL looks like https://cronengine.com/ping/hb_YOUR_TOKEN. The /start call is optional, and lets the run's duration be measured. The free plan includes 2 heartbeats.

Call a Worker from outside

When you want the schedule outside Cloudflare but the code inside, give the Worker a fetch handler that checks a secret and runs the same function. Answer with an error status when the job fails, so the scheduler records it as a failure.

export default {
  async fetch(request, env) {
    // Only the scheduler knows this secret
    if (request.headers.get('Authorization') !== `Bearer ${env.CRON_SECRET}`) {
      return new Response('Unauthorized', { status: 401 });
    }

    try {
      await runJob(env);
      return new Response('ok');
    } catch (error) {
      return new Response(String(error), { status: 500 });
    }
  },
};

Then create a cron job in CronEngine for https://your-worker.your-account.workers.dev/ with Bearer authentication and the same secret. It runs in your account's timezone, keeps every response, retries failed runs on paid plans, and emails you when the job starts failing. The free plan covers 3,000 runs a month, one job every 15 minutes.

Questions