Cloudflare Workers cron (UTC) or a Sume schedule with a timezone?

Use a Sume schedule when the clock is yours to define in local time, and a Worker cron trigger when other logic must run first. Cloudflare's docs say Cron Triggers execute on UTC and that adding, updating or deleting one can take up to 15 minutes to propagate. A Sume schedule takes a 5-field cron expression with an IANA timezone, so local time is built in.

Side by side

When the Worker owns the clock

Choose this when something must happen before Sume runs, such as checking inventory, and a plain cron schedule cannot express it. Create the Sume schedule with the API trigger, since its trigger type is fixed when you create it, and enable api_trigger_enabled. Your key needs actions:read and actions:write. The Worker then calls:

Remember the other fixed choice. A Sume schedule's trigger, cron or API, is set when it is created, and create and edit are dashboard-only, so decide up front which clock owns the run. A schedule meant for a Worker is best created as an API-trigger schedule. A cron schedule can also enable api_trigger_enabled, but its trigger type stays cron.

curl -sS -X POST "https://api.sume.com/v1/actions/$ACTION_ID/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"on_active_run":"reject"}'

Pick the overlap rule on purpose

Cloudflare's page does not say what happens when a run is still going at the next tick, so a Worker needs its own guard. Sume gives you one: skip returns 200 with status skipped and skip_reason of previous_run_active, and records a run row, while reject returns 409 action_run_in_progress and records none. Use reject when a dropped trigger should look like an error in the Worker's logs, and skip when overlap is harmless.

Because Worker triggers can lag behind a change by up to 15 minutes, do not use a freshly edited cron string to test a deadline. Run the API call by hand first, and check the receipt's status_url until next_action is no longer poll_status.

A note on defaults

A scheduled run has a $1.00 default ceiling, and a request can only lower it. Sending a value is therefore a safe way to tighten a single run, never to loosen it. Keep the key in a Worker secret, and rotate it if a log ever captures the header.