Comparison
Crontap vs Cloudflare Workers Cron
Cloudflare Cron Triggers are a strong native way to invoke a Worker's scheduled handler. You can manage them in the dashboard or, for Wrangler-managed Workers, in configuration. They run in UTC, allow 5 triggers on Free and 250 on Paid, and show the 100 most recent events. Crontap is the external HTTP alternative with cross-platform monitoring and routing.
At a glance
Cloudflare Workers Cron vs Crontap, side by side.
| Dimension | Cloudflare Workers Cron | Crontap |
|---|---|---|
| Schedule declared per Worker | Dashboard or Wrangler configuration | No (one dashboard, all Workers) |
| Per-IANA timezone per schedule | No (UTC only) | Yes |
| Cadence change without deploy | Yes in dashboard; Wrangler-managed triggers use config | Yes (dashboard save) |
| 1-minute cadence | Yes (1-min minimum) | Yes (Pro) |
| Trigger limits | 5 Free / 250 Paid per account | Plan combined-item cap |
| Cross-platform cron (non-Worker targets) | No | Yes (any HTTP endpoint) |
| Recent cron history | 100 most recent invocations; Workers Logs can retain more | 100 / 1,000 / 10,000 schedule runs by tier |
| Starting paid | Bundled with Workers plan | from $2.99/mo |
| Free tier | 5 Cron Triggers per account | Starter: 2 combined items; schedules hourly+, 1 uptime monitor daily, and 1 heartbeat hourly |
| Human Notifications | No standard Cron Trigger chat-alert product | All plans: email, test sends, product defaults, per-item default/custom/off routing, and delivery history. Pro, Ultra, and legacy Pro add Slack, Discord, and Telegram |
| Machine webhook Integrations | Build callbacks in Worker code or use Cloudflare APIs | Separate machine webhook Integrations with per-event success, failure, missed, and recovered levers where applicable |
| Schedule failure batching | Not compared; Crontap schedule-specific alert setting | Schedule alerts: unsaved default Starter 24h / 3 failures, paid 10m / 3; configurable floor Starter 1 day, paid 1 minute |
| Heartbeat / dead-man monitoring | No native dead-man monitor | Native: period + grace, /fail, missed/recovered/explicit-failure alerts, ping URL, and 90-day history |
| Uptime monitoring | No native uptime-monitor product in Cron Triggers | Native HTTP uptime: down/recovered alerts, history, 90-day rollups, and integration controls |
| Retries and customization | No standard Cron Trigger retry policy | Default on: 3 retries with 2× exponential backoff and jitter. Pro, Ultra, and legacy Pro: 1–5 retries plus delay and retry outcomes; alert after exhaustion |
| AI response processing | No response transform-and-forward workflow | AI response transforms: transform, summarize, normalize, extract, or triage, then forward. Pro: daily, 1 per schedule. Ultra: hourly, unlimited; test-run UX |
How they work
The two approaches in one paragraph each.
Cloudflare Workers Cron
Cron Triggers invoke a Worker's scheduled handler in UTC. Dashboard-managed Workers can add or remove triggers in the dashboard; Wrangler-managed Workers should keep triggers in configuration. Changes can take up to 15 minutes to propagate. Cloudflare stores 100 recent Cron Events and provides deeper logs separately.
Crontap
Crontap calls your Worker's `fetch` route on the cron schedule. The Worker keeps its `fetch` handler; the `scheduled` handler is gone. You get one dashboard across every Worker in every zone, plus every non-Worker target (Lambda Function URL, Cloud Run service, Vercel API route) you also happen to schedule. Cadence changes are dashboard saves.
Where each side wins
Honest broker, both columns.
Cloudflare Workers Cron wins on
- Free and native if you have only one Worker, with no external dependency.
- Schedules ship in the same git commit as the code; no drift between repo and dashboard.
- Runs inside the same isolate as the Worker, so cold-start cost is the Worker's normal cold start.
- Good fit when the Worker exists primarily to run on a cron.
Crontap wins on
- One list across Workers and non-Cloudflare HTTP targets.
- Per-IANA timezone per schedule, with no DST math, twice-a-year cron edit, or UTC-to-Berlin mental arithmetic.
- Default-on HTTP retries with paid count, delay, and outcome controls.
- Human Notifications, separate machine Integrations, uptime, and heartbeats are built in.
- The same dashboard fires non-Worker targets too: an AWS Lambda Function URL, a Cloud Run service, a Vercel API route.
The math
Cadence and pricing, worked out.
- Cron Triggers are bundled with Workers: Free allows 5 triggers per account and Paid allows 250. Worker request and CPU limits still apply.
- Crontap Pro starts at $2.99/mo and scales as you grow at 1-minute cadence (covering Workers and non-Workers targets in the same bill).
- If your only schedules are inside one Workers account and you have free-plan headroom, Cron Triggers cost nothing. The pricing wedge is the dashboard, not the dollar.
Moving from Cloudflare Workers Cron
The migration, in 6 steps.
- For each Worker with a `scheduled` handler: refactor the body into a function you can call from `fetch` too.
- Add a `fetch` route (e.g. `/__crontap/run`) that checks a bearer header and calls the refactored function.
- Create a Crontap schedule against `https://<worker>.<account>.workers.dev/__crontap/run` using the same cron expression. Add the IANA timezone you actually want.
- Verify the Crontap run log matches the Cron Trigger log for one cycle (Workers Trace Events vs the Crontap dashboard).
- Remove the `[triggers]` block and the `scheduled` handler. Deploy.
- Repeat for every Worker with a Cron Trigger. The Crontap dashboard now lists every schedule in one place.
Decision
Which one fits.
Pick Cloudflare Workers Cron if
You have one Worker, the schedule is its primary purpose, you're happy with UTC, and cadence changes ride along with your normal deploy cadence.
Pick Crontap if
You have several Workers across zones, you need per-IANA timezones, you want to retune cadence without a deploy, or you also schedule non-Worker targets.
Pair both if
Use Cron Triggers for the rare Worker whose entire purpose is one schedule. Use Crontap for everything else, including the cross-platform jobs that Cron Triggers can't reach.
FAQ
Crontap vs Cloudflare Workers Cron, in detail.
- Can Crontap call a Worker on a `workers.dev` URL?
- Yes. Workers expose `fetch` natively; Crontap calls that URL on the cron schedule with a bearer header. The Worker runs in the same isolate as any normal request. The `[triggers]` block in `wrangler.toml` becomes irrelevant.
- Will I lose anything by dropping the `scheduled` handler?
- The `scheduled` event has a slightly different invocation context than `fetch`: no `Request` object and a longer wall-clock budget. For most cron-style work that doesn't matter. If you specifically depend on the scheduled event's properties, keep the Cron Trigger and add Crontap only for the cross-Worker dashboard view.
- What about Workers in multiple zones or accounts?
- That's the main reason teams move. Cron Triggers live in the zone where the Worker is deployed; there's no cross-zone dashboard. Crontap shows every schedule across every zone in one list, sorted by next-fire time.
- Does this work with Durable Objects or KV bindings?
- Yes. The Worker's runtime (Durable Objects, KV, R2 bindings, secrets) is unchanged. Only the trigger layer moved from `scheduled` to `fetch`. Inside the handler you still have access to `env` and the same bindings the Worker had before.
Sources
Ready to fix it?
Point Crontap at any URL. Pick any cron. Done.
WordPress, Shopify, Railway, Cloud Run, Vercel, HubSpot, Ghost, your own box. If it answers HTTP, Crontap can drive it on a clock you can read, in the timezone that actually matters, and page you when something breaks.
Free forever tier ・ No credit card required
/wp-cron.php?doing_wp_cron=1
Schedule
"every 5 minutes"
Next
in 23s