DEV Community: Ronen Cypis

Cron Job Monitoring Tools Compared: From DIY to Fully Managed

Ronen Cypis — Tue, 09 Jun 2026 12:20:00 +0000

Cron's biggest problem isn't scheduling — it's silence. A cron job can fail every night for a month, and unless you're manually checking logs on the server, you won't know. No alert, no dashboard, no audit trail. Just a backup that doesn't exist when you need it, or a data sync that quietly stopped three weeks ago.

Monitoring fixes this. But "cron job monitoring" means different things depending on the tool. Some watch for missing heartbeats. Some track full execution history. Some just page you when something breaks. This article compares six approaches — from writing your own monitoring scripts to using a fully managed scheduler with built-in observability — so you can pick the right one for your workload.

Heartbeat Monitoring vs. Execution Monitoring

Before comparing tools, understand the two fundamentally different approaches.

Heartbeat monitoring (dead man's switch) is passive. Your cron job pings a monitoring URL after each run. If the ping doesn't arrive on schedule, you get an alert. This tells you whether a job ran — but not what happened. If the job runs but returns bad data, the ping still fires and the monitor stays green.

Execution monitoring is active. The scheduler fires the job, captures the response, records the outcome, and alerts on failure. You get the full picture: status code, response body, duration, retry count, and a timeline of every execution.

When to use each: Heartbeat monitoring makes sense when you're stuck with system cron. Execution monitoring makes sense when you're choosing a scheduler — you get monitoring, retries, and logging as part of the platform.

Comparison at a Glance

Tool	Type	Alerts	Execution Logs	Retries	Free Tier
DIY scripts	Custom	⚠️ Whatever you build	⚠️ Whatever you build	⚠️ Whatever you build	✅ Free (your time)
Healthchecks.io	Heartbeat	✅ Email, Slack, webhooks	❌ No	❌ No	✅ 20 checks
Cronitor	Heartbeat + telemetry	✅ Email, Slack, PagerDuty	⚠️ Basic (duration, exit code)	❌ No	⚠️ 5 monitors
Better Stack	Uptime + heartbeat	✅ Email, Slack, PagerDuty	⚠️ Basic (heartbeat log)	❌ No	⚠️ 5 monitors
PagerDuty / Opsgenie	Incident mgmt	✅ Full escalation	❌ Requires integration	❌ No	⚠️ Limited
Runhooks	Execution (scheduler)	✅ Email, webhook	✅ Full (status, body, duration)	✅ Exponential backoff	✅ 3 jobs

DIY Monitoring

The simplest approach: wrap each cron job in a script that checks exit codes and sends alerts.

#!/bin/bash
/scripts/nightly-backup.sh >> /var/log/backup.log 2>&1
if [ $? -ne 0 ]; then
  curl -X POST https://hooks.slack.com/services/T00/B00/xxx \
    -d '{"text": "Backup job failed on prod-1"}'
fi

Pricing: Free in dollars, expensive in time.

Limitations: You're building monitoring for every job. No dashboard, no execution history, no retries unless you write them. When the server dies, the monitoring dies with it.

Best for: Solo developers with a handful of non-critical jobs.

Healthchecks.io

A dedicated heartbeat monitoring service. Create a check, get a ping URL, append it to your cron job. If the ping doesn't arrive on schedule, you get an alert. Supports start/success/fail signals so you can detect jobs that start but never finish.

Pricing: Free tier includes 20 checks with unlimited alert integrations. Paid plans start at $20/month.

Limitations: Doesn't execute your jobs — only watches for pings. No execution logs, no retries, no scheduling. If the job runs but produces bad results, the heartbeat still fires and the monitor stays green.

Best for: Teams using system cron or platform-native schedulers who need basic "is it running?" monitoring without changing their scheduler.

Cronitor

Heartbeat monitoring with added telemetry. Integrate via ping URLs or install the Cronitor CLI to automatically capture duration, exit code, and output size from your crontab entries.

Pricing: Free tier includes 5 monitors. Paid from $12.50/month.

Limitations: A monitoring layer, not a scheduler. Doesn't capture HTTP response bodies or provide retries. The CLI agent requires server installation — if the server dies, the agent dies with it.

Best for: Teams that want duration trends and exit code tracking beyond raw heartbeat pings.

Better Stack (formerly Better Uptime)

Primarily an uptime monitoring and incident management platform that includes heartbeat monitoring as a secondary feature. Your job pings a URL, Better Stack alerts if the ping is late — routed through on-call schedules and escalation policies.

Pricing: Free tier includes 5 monitors. Paid plans start at $24/month per user.

Limitations: Designed around uptime monitoring, not cron. No execution logs, retries, or scheduling. If you're only using it for cron monitoring, you're paying for functionality you don't need.

Best for: Teams already using Better Stack for uptime monitoring who want to add heartbeat checks without another tool.

PagerDuty / Opsgenie

Enterprise incident management platforms that don't monitor cron jobs directly — they're where cron alerts end up. Your monitoring tool fires an event on failure, and PagerDuty/Opsgenie handles routing, escalation, and acknowledgment.

Pricing: PagerDuty free tier covers 5 users. Paid from $21/user/month. Opsgenie starts at $9.45/user/month.

Limitations: These are alert destinations, not monitoring sources. You still need something to detect the failure. Adding PagerDuty is justified for enterprise on-call workflows but overkill for most cron monitoring needs.

Best for: Organizations with established on-call rotations that need cron alerts routed through existing incident management.

Runhooks Built-In Monitoring

Runhooks combines scheduling and monitoring into a single layer. The scheduler fires the HTTP request, inspects the response, logs the result, retries on failure, and alerts when retries are exhausted. There's no separate ping step — the scheduler is the monitor.

Every execution is recorded: HTTP status code, response body (up to 64 KB), duration in milliseconds, attempt number, and error details. Failed jobs enter a dead-letter state and trigger alerts via email or webhook.

Pricing: Free plan includes 5 jobs with retries and alerts. Paid plans add more jobs, longer log retention (up to 30 days), and higher retry limits. See full pricing.

Limitations: HTTP-only — if your job isn't callable via HTTP, you'd need to wrap it in an endpoint first. Natural fit for web services and serverless functions, less suited for legacy shell scripts.

Best for: Teams who want scheduling, retries, logging, and alerting in one tool without stitching together a monitoring stack.

Choosing the Right Approach

Locked into system cron? Add heartbeat monitoring. Healthchecks.io is the strongest option — generous free tier, simple integration, wide alert support.

Already use an observability platform? Check if it supports heartbeat checks (Better Stack, Datadog). No need for another tool.

Need to know why a job failed? You need execution-level monitoring — either extensive logging in every script (fragile) or a scheduler that captures execution details natively.

Scheduling HTTP endpoints? A managed HTTP scheduler like Runhooks gives you scheduling, retries, logs, and alerts in one layer. No heartbeat URLs, no wrapper scripts, no separate monitoring tool.

The monitoring gap in most cron setups isn't technical — it's organizational. Pick the approach that requires the least ongoing effort.

Get Started

If you're running scheduled HTTP jobs and want monitoring that's built into the scheduler rather than bolted on:

Create a Runhooks account — the free plan includes 5 jobs with retries and alerts
Test your cron expressions with the cron expression visualizer
Compare plans when you're ready to scale

Frequently Asked Questions

How do I know if my cron job stopped running?

You need external monitoring. Cron has no built-in failure detection. The two main approaches are heartbeat monitoring (your job pings a URL after each run — if the ping stops, you get an alert) and execution monitoring (the scheduler itself tracks every run and alerts on failures). Heartbeat tools like Healthchecks.io catch missing runs. Execution-aware schedulers like Runhooks catch missing runs, HTTP errors, timeouts, and retry exhaustion.

What is the difference between heartbeat monitoring and execution monitoring?

Heartbeat monitoring is passive — your cron job pings a URL when it completes, and the monitor alerts you if the ping is late or missing. Execution monitoring is active — the scheduler fires the job, inspects the response, and logs the outcome. Heartbeat monitoring tells you a job didn't run. Execution monitoring tells you why it failed, how long it took, and what the response was.

What is the best free cron job monitoring tool?

Healthchecks.io offers a generous free tier with 20 checks, and it handles basic heartbeat monitoring well. For execution-level monitoring with logs and retries, Runhooks includes a free plan with 5 jobs, automatic retries, and failure alerts. The best choice depends on whether you need passive heartbeat checks or active execution tracking.

Do I need cron monitoring if I already have uptime monitoring?

Yes. Uptime monitoring checks that your server responds to HTTP requests. Cron monitoring checks that scheduled tasks actually execute on time and succeed. A server can have 100% uptime while every cron job on it is silently failing — wrong permissions, expired credentials, full disk, or a killed cron daemon. These are different failure modes that require different monitoring.

Disclosure: I'm the founder of Runhooks, one of the tools compared in this article.

Best External Cron Job Services Compared (2026)

Ronen Cypis — Tue, 09 Jun 2026 12:10:00 +0000

You have an API endpoint that needs to run on a schedule. Maybe it syncs data from a third party, sends a digest email, or cleans up expired records. You don't want to manage a cron server. You want something external to call your endpoint on time, retry if it fails, and tell you when something goes wrong.

That's what external cron job services do. But the options range from free community tools to enterprise cloud products, and they make very different tradeoffs. This article compares six of them honestly — what they're good at, where they fall short, and who should use each one.

Quick Comparison

Service	Pricing	Retries	Execution Logs	Failure Alerts	Vendor Lock-in
Cron-job.org	Free	⚠️ Limited	⚠️ 1 day history	⚠️ Email only	✅ None
EasyCron	From $12/mo	✅ Yes	✅ Yes	✅ Email, webhook	✅ None
Cronhooks	Free + paid	✅ Yes	✅ Yes	⚠️ Email only	✅ None
Google Cloud Scheduler	$0.10/job/mo	✅ Via Pub/Sub	⚠️ Cloud Logging	⚠️ Cloud Monitoring	❌ GCP
AWS EventBridge	$1/M invocations	⚠️ Via destinations	⚠️ CloudWatch	⚠️ CloudWatch	❌ AWS
Runhooks	Free + paid	✅ Exponential backoff	✅ Full response	✅ Email, webhook	✅ None

Cron-job.org

What it does: A free, community-run service that sends HTTP requests to URLs on cron schedules. One of the most well-known options for basic cron pinging.

Pricing: Completely free. Funded by donations.

Key features: Unlimited cron jobs, standard cron expressions, basic execution history (last 24 hours), email notifications on failure, timezone support.

Limitations: No SLA or uptime guarantees — it's a community project. Retry behavior is basic with no exponential backoff. No webhook alerting, no API for programmatic management, no response body capture.

Best for: Hobby projects and non-critical tasks where a missed execution won't cause business impact.

EasyCron

What it does: One of the longest-running paid cron job services. HTTP-based scheduling with more features and reliability than free alternatives.

Pricing: From $12/month. Scales by job count, minimum interval, and execution timeout. No free tier.

Key features: Configurable retries, execution logging with response details, email and webhook notifications, REST API, custom headers and bodies, IP whitelisting, cron expression builder.

Limitations: No free tier. The interface is dated. Pricing can escalate for teams with many jobs or short intervals.

Best for: Teams that need a proven, reliable paid service. EasyCron's long track record matters if you've been burned by free tools disappearing.

Cronhooks

What it does: HTTP-based cron scheduling focused on webhooks. Supports both recurring and one-time scheduled requests.

Pricing: Free tier with limited jobs, plus paid plans for higher volume.

Key features: Recurring and one-time scheduled HTTP requests, retry on failure, execution history, email notifications, REST API, timezone support.

Limitations: Smaller user base than EasyCron or cloud providers. Documentation is limited. Webhook alerting and configurable retry strategies are less mature.

Best for: Developers who need a straightforward HTTP scheduler with a free tier. A reasonable middle ground between Cron-job.org and enterprise solutions.

Google Cloud Scheduler

What it does: Google's fully managed cron service within GCP. Triggers HTTP endpoints, Pub/Sub topics, and App Engine routes on cron schedules.

Pricing: $0.10/job/month (first three free). Downstream costs (Cloud Functions, Pub/Sub, Cloud Run) add up depending on what jobs trigger.

Key features: Tight GCP integration (Pub/Sub, Cloud Functions, Cloud Run), configurable retry policies with exponential backoff, IAM-based auth, logs via Cloud Logging, alerting via Cloud Monitoring, enterprise SLA (99.5%+).

Limitations: Requires a GCP project and billing account even for basic HTTP scheduling. IAM roles, service accounts, and Pub/Sub topics add configuration overhead. Vendor lock-in. Overkill if you're not already on GCP.

Best for: Teams already on GCP who want scheduling integrated with their IAM, logging, and monitoring stack. If your backend is Cloud Run or Cloud Functions, this is the natural choice.

AWS EventBridge Scheduler

What it does: AWS's managed scheduling service. Invokes over 270 AWS services on a schedule, including Lambda, Step Functions, SQS, and HTTP endpoints (via API Destinations).

Pricing: $1/million invocations (first 14 million/month free). Extremely cheap at scale.

Key features: Deep AWS integration, one-time and recurring schedules, cron and rate expressions, retry policies with dead-letter queues, IAM security, massive scale (millions of schedules per account).

Limitations: External HTTP endpoints require API Destinations setup (connection resources, IAM roles, OAuth). The AWS console is complex for simple HTTP scheduling. Monitoring is split across CloudWatch and EventBridge consoles — no unified execution dashboard. Full vendor lock-in.

Best for: Teams already on AWS who need to trigger Lambda, Step Functions, or other AWS services. For simple "hit this URL every hour" outside AWS, the setup overhead isn't worth it.

Runhooks

What it does: Runhooks is a managed HTTP job scheduler built specifically for developers who need to fire HTTP requests on cron schedules. It focuses on the core workflow: define a URL, set a schedule, get retries and alerts.

Pricing: Free tier available, with paid plans for more jobs and longer log retention. See pricing for current details.

Key features:

HTTP-first design — every job is a URL + method + headers + body + cron expression
Automatic retries with exponential backoff (configurable attempts)
Full execution logging: HTTP status, response body, duration in milliseconds, attempt number
Failure alerts via email and webhook when retries are exhausted
Timezone support with visual cron expression preview
Clean, developer-focused dashboard
No cloud vendor coupling — works with any endpoint, anywhere

Limitations:

HTTP-only — no native integration with AWS Lambda invocations, GCP Pub/Sub, or database-level triggers
Newer service compared to EasyCron or the cloud schedulers
Feature set is focused on HTTP scheduling — if you need to orchestrate multi-step workflows or fan-out to queues, a cloud-native tool may be a better fit

Best for: Developers and small teams who need a straightforward HTTP scheduler without cloud provider complexity. If your scheduled tasks are API endpoints, Runhooks does exactly what you need with less configuration overhead than cloud-native alternatives.

Get Started

If you're evaluating cron job services, here's the fastest way to test Runhooks:

Create an account — free tier available, no credit card required
Add a job with your endpoint URL and cron expression
Watch the execution log to verify it works

Test your cron expressions with the cron expression visualizer before creating jobs, and check the pricing page when you need to scale.

Frequently Asked Questions

What is an external cron job service?

An external cron job service sends HTTP requests to your API endpoints on a schedule you define — typically using cron expressions. Instead of managing your own cron server, the service handles scheduling, retries, and monitoring. Your application logic stays in your backend as regular HTTP endpoints.

Is cron-job.org reliable enough for production?

Cron-job.org is community-run and free, which makes it suitable for hobby projects and non-critical tasks. However, it offers no SLA, limited retry logic, and minimal execution history. For production workloads where missed executions have business impact, a paid service with retries, alerting, and guaranteed uptime is a safer choice.

What is the best EasyCron alternative?

It depends on your priorities. If you want a developer-focused HTTP scheduler with automatic retries, execution logs, and failure alerts, Runhooks is the closest alternative. If you need deep cloud integration, Google Cloud Scheduler or AWS EventBridge Scheduler fit better. If you need free, Cron-job.org is the main option.

Do I need a cron job service if I use AWS or GCP?

AWS EventBridge Scheduler and Google Cloud Scheduler are solid options if your infrastructure is already on those platforms. However, they require cloud-specific configuration (IAM roles, service accounts, Pub/Sub topics) that adds complexity. A standalone cron job service is simpler if you just need to hit an HTTP endpoint on a schedule without cloud vendor coupling.

Disclosure: I'm the founder of Runhooks, one of the services compared in this article.

Scheduling Cloudflare Workers Beyond Cron Triggers

Ronen Cypis — Tue, 09 Jun 2026 12:00:00 +0000

Cloudflare Workers Cron Triggers let you run code on a schedule without managing infrastructure. You define a cron expression in wrangler.toml, write a scheduled event handler, deploy, and Cloudflare runs it. For simple, low-frequency tasks inside a single worker, this works well.

Then your project grows. You need a sixth scheduled task, or your nightly data sync fails silently and nobody notices for three days, or you want to schedule calls across multiple workers. That's where Cron Triggers start hitting walls.

How Cloudflare Cron Triggers Work

Cron Triggers are configured in your wrangler.toml file and handled by a scheduled event in your worker code:

# wrangler.toml
name = "my-worker"
main = "src/index.ts"
compatibility_date = "2024-01-01"

[triggers]
crons = ["0 */6 * * *", "0 0 * * MON"]

// src/index.ts
export default {
  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext) {
    switch (event.cron) {
      case '0 */6 * * *':
        await syncExternalData(env);
        break;
      case '0 0 * * MON':
        await generateWeeklyReport(env);
        break;
    }
  },
} satisfies ExportedHandler<Env>;

Cloudflare evaluates the cron expressions and invokes your worker's scheduled handler at the specified times. You can use the event.cron property to differentiate between triggers when a single worker has multiple schedules.

This is straightforward for one or two tasks. The problems surface as you add more.

The Limitations of Cron Triggers

Trigger limits per worker

The free plan allows 3 cron triggers per worker. The paid Workers plan ($5/month) increases this to 5 cron triggers per worker. If your project needs 8 scheduled tasks, you must split them across multiple workers — each with its own wrangler.toml, deployment, and codebase. This adds operational overhead for what should be a scheduling concern, not an architecture concern.

No retries on failure

If your scheduled handler throws an error, exceeds the CPU time limit, or fails for any reason, Cloudflare does not retry the execution. The failed run is gone. The next attempt happens at the next scheduled tick — which could be hours or days away depending on the cron expression.

For a task that cleans up temporary files, a missed run is tolerable. For a task that reconciles billing data or sends time-sensitive notifications, a silent failure can have real consequences.

Limited execution visibility

Cron Triggers provide basic invocation metrics through Workers Analytics — you can see that a trigger fired and whether the worker returned successfully. But there's no structured log of what happened inside the execution: how many records were processed, what the response payload was, or how long individual operations took. Getting that level of detail requires wiring up a separate logging pipeline to a service like Logpush or a third-party provider.

No failure alerts

When a cron trigger fails, Cloudflare doesn't send you an email or a webhook. You find out when you check the dashboard, or when a downstream system breaks because the scheduled task stopped running. There's no built-in way to get notified when a scheduled handler starts failing consistently.

CPU time constraints

CPU time limits vary by plan:

Free plan: 10ms CPU time per execution
Bundled (paid): 50ms CPU time per execution
Standard/Unbound (paid): 30 seconds CPU time per execution

On the free plan, 10ms of CPU time is tight for anything beyond trivial operations. Even on the paid Bundled plan, 50ms limits what you can do in a single scheduled execution. The Standard usage model gives 30 seconds, which covers most workloads, but you need to be on the paid plan to access it.

When Cron Triggers Are Enough

Cron Triggers work well when:

You have 5 or fewer scheduled tasks within a single worker
Tasks are simple and fast — cache purges, KV store updates, lightweight API calls
Missed runs are tolerable — the next scheduled tick will catch up
You don't need per-execution logs or failure notifications
Your workload fits within the CPU time limits of your plan

If your scheduled tasks check these boxes, Cron Triggers are the simplest solution. No external dependencies, no extra services, no additional cost.

When You Need More

The moment you need any of the following, Cron Triggers become insufficient:

More than 5 scheduled tasks without splitting across workers
Automatic retries when a scheduled handler fails
Execution logs with HTTP status, response body, and duration
Failure alerts via email or webhook
Scheduling across multiple workers or mixing Workers with other services (APIs on Railway, Cloud Functions, Vercel routes)
Complex scheduling with timezone awareness and DST handling

The External Scheduler Approach

Every Cloudflare Worker with a fetch handler is an HTTP endpoint. Instead of relying on the scheduled handler, you can expose your task logic through fetch and trigger it externally:

// src/index.ts
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    // Verify the request is from your scheduler
    const authHeader = request.headers.get('Authorization');
    if (authHeader !== `Bearer ${env.CRON_SECRET}`) {
      return Response.json({ error: 'Unauthorized' }, { status: 401 });
    }

    const url = new URL(request.url);

    if (url.pathname === '/tasks/sync') {
      const result = await syncExternalData(env);
      return Response.json({ task: 'sync', ...result });
    }

    if (url.pathname === '/tasks/report') {
      const result = await generateWeeklyReport(env);
      return Response.json({ task: 'report', ...result });
    }

    return Response.json({ error: 'Not found' }, { status: 404 });
  },
} satisfies ExportedHandler<Env>;

This changes the architecture: your worker becomes an HTTP API with multiple task endpoints, and an external scheduler handles the timing. You get separate URLs for separate tasks, structured JSON responses, and standard HTTP status codes that an external system can act on.

Adding authorization

Protect your worker from unauthorized requests using a secret stored in Workers secrets:

npx wrangler secret put CRON_SECRET

The fetch handler checks the Authorization header against this secret (shown above). Configure the same Bearer <token> header in your external scheduler. For additional security, restrict requests by IP using Cloudflare Access or validate a signed HMAC.

Step-by-Step Setup With Runhooks

Runhooks is a scheduled HTTP execution service. It calls your endpoints on a schedule with retries, logging, and failure alerts. Here's how to schedule a Cloudflare Worker:

1. Deploy your worker with a fetch handler

Use the fetch handler pattern shown above. Each task gets its own path (/tasks/sync, /tasks/report, etc.). Deploy with npx wrangler deploy.

2. Set a secret for authorization

npx wrangler secret put CRON_SECRET
# Enter a strong random string when prompted

3. Create a job in Runhooks

Name: "Sync external data"
URL: https://my-worker.your-subdomain.workers.dev/tasks/sync
Method: GET or POST
Headers: Authorization: Bearer <your-cron-secret>
Schedule: 0 */6 * * * (every 6 hours)
Retries: 3 attempts with exponential backoff

4. Create a second job for the weekly report

Name: "Weekly report"
URL: https://my-worker.your-subdomain.workers.dev/tasks/report
Schedule: 0 0 * * MON (every Monday at midnight)
Timezone: your preferred timezone
Retries: 3 attempts

Each job runs independently with its own schedule, retry policy, and alerting. No cron trigger limits. No splitting tasks across multiple workers.

What you gain over Cron Triggers

No trigger limits — schedule 20 tasks against one worker, or spread them across 10 workers. Each is a separate HTTP job.
Automatic retries — if a cold start, network blip, or transient error causes a failure, the next attempt fires within seconds instead of waiting for the next cron tick.
Execution logs — every invocation is recorded with HTTP status code, response body, and duration in milliseconds. When your sync processed 2,400 records in 1.8 seconds, you see it.
Failure alerts — email or webhook notifications when a job starts failing. You find out in minutes, not days.
Timezone-aware scheduling — set a job to run at 9 AM America/New_York and it stays at 9 AM through DST transitions.
Cross-service scheduling — schedule a Cloudflare Worker, a Vercel API route, and a Railway endpoint from the same dashboard. Cron Triggers only work within Cloudflare.

Keeping the Scheduled Handler as a Fallback

You don't have to remove your scheduled handler when switching to external scheduling. A worker can have both — the external scheduler handles the primary schedule with retries and logging, while a cron trigger fires as a lower-frequency fallback (say, once daily) to catch anything missed:

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    // External scheduler entry point
    const authHeader = request.headers.get('Authorization');
    if (authHeader !== `Bearer ${env.CRON_SECRET}`) {
      return Response.json({ error: 'Unauthorized' }, { status: 401 });
    }
    const result = await syncExternalData(env);
    return Response.json(result);
  },

  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext) {
    // Fallback: runs even if the external scheduler is down
    await syncExternalData(env);
  },
} satisfies ExportedHandler<Env>;

Your task logic lives in a shared function, so there's no code duplication.

Get Started

Cloudflare Workers are fast and cheap to run — the cron trigger limitations are the main constraint for scheduled workloads, and they're straightforward to work around:

Expose your task logic through a fetch handler with authorization
Try Runhooks and schedule your workers at any frequency
Get retries, execution logs, and failure alerts that Cron Triggers don't provide

Preview your cron expressions with the cron expression visualizer, and compare plans when you need more jobs or longer log retention.

Frequently Asked Questions

How many cron triggers can a Cloudflare Worker have?

On the free plan, each Cloudflare Worker can have up to 3 cron triggers. On the paid Workers plan ($5/month), the limit increases to 5 cron triggers per worker. If you need more scheduled tasks, you must split them across multiple workers or use an external scheduler to trigger your workers via HTTP.

Do Cloudflare Cron Triggers have built-in retries?

No. If a scheduled handler throws an error or times out, Cloudflare does not retry the execution. The failed run is lost and the next attempt happens at the next scheduled tick. For tasks where missed runs are costly — data syncs, billing reconciliation, alert checks — you need an external scheduler that retries on failure.

Can I trigger a Cloudflare Worker on a cron schedule without using Cron Triggers?

Yes. Every Cloudflare Worker with a fetch handler is a standard HTTP endpoint. You can use an external HTTP scheduler like Runhooks to send a request to your Worker's URL on any cron schedule. This bypasses the cron trigger limit entirely and adds retries, logging, and failure alerts.

What are the CPU time limits for Cloudflare Workers Cron Triggers?

On the free plan, each cron trigger execution is limited to 10ms of CPU time. On the paid Bundled plan, the limit is 50ms. If you use the Standard (unbound) usage model, CPU time extends to 30 seconds per execution. These limits apply equally to both scheduled and fetch handlers.

Disclosure: I'm the founder of Runhooks, one of the tools mentioned in this article.