Cloudflare Workers cron jobs

How to handle Cloudflare Workers cron jobs when schedules are dynamic

Cloudflare Cron Triggers work well for fixed schedules attached to a Worker. They become awkward when your application needs one recurring workflow per customer, integration, or account setting.

Where Cloudflare cron jobs fit well

If you know the schedule at deploy time, Cloudflare Workers can be a clean place to run recurring maintenance tasks. A nightly cache refresh, a fixed cleanup routine, or one global digest job can fit that model.

The key assumption is that the schedule belongs to the deployment. You define it once, publish the Worker, and the same cadence applies until the next config change.

Why product-owned schedules are different

SaaS products usually need schedules that come from application data, not infrastructure config. A customer may choose a daily sync, a team may pause a recurring export, or your backend may need to create one job per tenant.

Each customer can choose a different delivery time.
Your app needs to pause or resume one recurring workflow without a deploy.
One endpoint should receive different payloads for different accounts.
Support needs execution history for a specific failed schedule.

The API-first pattern for Workers apps

Keep your business logic in a protected HTTP endpoint. Let your backend create the schedule through CronCoco, then let CronCoco call that endpoint on time. That turns recurring work into application data your product can manage.

// worker.ts
export default {
  async fetch(request, env) {
    if (new URL(request.url).pathname !== "/api/run-report") {
      return new Response("Not found", { status: 404 });
    }
    if (request.headers.get("x-cron-secret") !== env.CRON_SECRET) {
      return new Response("Unauthorized", { status: 401 });
    }
    const payload = await request.json().catch(() => ({}));
    await runReportForAccount(payload.accountId);
    return Response.json({ ok: true });
  }
};

Create the schedule from your backend

Once a customer enables the workflow, your app can create the recurring webhook and store the returned job id with the account record.

curl -X POST https://api.croncoco.io/jobs \
  -H "Authorization: Bearer coco_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"account-report-acme","cron_expression":"0 13 * * 1-5","webhook_url":"https://your-worker.your-subdomain.workers.dev/api/run-report","headers":{"x-cron-secret":"YOUR_SECRET"},"payload":{"accountId":"acct_123"}}'

Cloudflare Cron Triggers vs CronCoco

Fixed Worker maintenance task: Cloudflare Cron Trigger.
One schedule per customer or tenant: CronCoco.
Need custom payloads, headers, and API-managed lifecycle: CronCoco.
Need visibility into a specific recurring webhook execution: CronCoco.

Where CronCoco fits

CronCoco works well when Cloudflare stays focused on running your application code and an external scheduler handles the clock, delivery, and execution history. Your backend decides what schedules exist, and CronCoco calls the Worker endpoint when it should.

For adjacent reading, see how serverless cron jobs work, when to use a webhook scheduler API, and the Create job API docs.