DEV Community: Ronen Cypis

Kubernetes CronJob Not Running? Fixing Missed Schedules

Ronen Cypis — Sun, 27 Sep 2026 16:51:19 +0000

You check on a CronJob that's supposed to run every hour and find it hasn't fired since yesterday. No failed pod, no alert, no error in your dashboards — it just stopped, and the only clue is buried in the controller's events:

Cannot determine if job needs to be started: too many missed start times

Kubernetes CronJobs are convenient, but they fail quietly in several distinct ways. Once you know the failure modes, you can decide which jobs are safe to leave on the built-in controller and which need a more reliable trigger.

Why Kubernetes CronJobs Miss Runs

The CronJob controller is best-effort, and several mechanisms can silently drop a run:

1. The controller fell behind, or was down

The controller has to be running at the scheduled minute to create the Job. If it's unavailable — a control-plane hiccup, a node drain, an upgrade — the scheduled time can pass unhandled. Whether the run is recovered depends on startingDeadlineSeconds.

2. `startingDeadlineSeconds` skipped it

If the controller is late by more than startingDeadlineSeconds, it skips that run entirely rather than starting it late. Leave the field unset and a missed window is simply lost. Set it too low and normal scheduling jitter causes skips.

3. `concurrencyPolicy: Forbid` suppressed it

With Forbid, if the previous run is still executing when the next is due, the new run is skipped, not queued. A job that occasionally runs long can quietly eat its own next execution — and the one after that.

4. "Too many missed start times"

If the controller counts more than 100 missed schedules since the last successful start — common after a CronJob is suspended, or after the controller is down for a while — it gives up with too many missed start times and stops trying. The job stays dead until someone notices.

5. Timezone confusion

Unless you set spec.timeZone, many clusters interpret the schedule in UTC. A 0 9 * * * you meant for 9am local runs at the wrong hour, which looks a lot like "not running" to whoever's expecting it.

The common thread: the CronJob controller optimizes for in-cluster batch scheduling, not for guaranteed timing or visibility. When a run is skipped, nothing pages you — you find out when the downstream data is missing.

The Fix: Trigger and Watch From Outside the Cluster

For jobs where timing and guaranteed execution actually matter, the reliable pattern is to drive the schedule from outside the cluster and treat the in-cluster workload as the thing that runs, not the thing that keeps time.

Expose the work behind an authenticated endpoint — an existing service route, or a small handler that creates the Kubernetes Job via the API:

# The Job template stays in the cluster; an external call decides WHEN it runs.
apiVersion: batch/v1
kind: Job
metadata:
  generateName: nightly-report-
spec:
  template:
    spec:
      containers:
        - name: report
          image: myorg/report:latest
      restartPolicy: Never

An external scheduler calls your endpoint (or the Kubernetes API) at the exact time. Because the trigger lives outside the control plane, a controller hiccup, a suspended CronJob, or a too many missed start times condition can't silently swallow a run — and every attempt is logged and alertable.

Why a DIY External Cron Isn't Enough

Moving the trigger to a cron job on a bastion host just relocates the problem:

Requires an always-on machine that you now have to patch and monitor.
Fails silently — a failed kubectl create job or API call gets no retry and no alert.
No execution history across runs, so a missed trigger looks identical to a run that never was.
No retries — a transient API error means a lost run.

You'd rebuild retries, logging, and alerting around a script — which is a scheduler with none of the guarantees.

How Runhooks Triggers Kubernetes Jobs Reliably

Runhooks is a scheduled HTTP execution service, and triggering an in-cluster job is just an HTTP call:

Create a job — name it "Trigger nightly report."
Set the URL — your authenticated in-cluster endpoint (behind an Ingress) or the Kubernetes API endpoint that creates the Job.
Set the method and auth — POST with the appropriate token or shared secret header.
Set the schedule — any cron expression, in a timezone you specify explicitly, with retries enabled.

What you get that the native controller doesn't:

Accurate timing — the job is triggered when you asked, independent of control-plane state.
Automatic retries — a transient API error retries instead of silently losing the run.
Execution logs — every trigger recorded with status and response, so a skipped run is visible.
Missed-run alerts — you're notified when a run fails or doesn't happen, instead of discovering it from missing data.
Unambiguous timezone — the schedule is defined once, in the timezone you choose.

This is the same principle behind triggering GitHub Actions reliably: separate the timing from the execution, and put a scheduler you can observe in front of it.

When the Built-in CronJob Is Fine

To be fair, native CronJobs are a good fit for in-cluster batch work that tolerates drift — log rotation, cache warming, cleanup jobs where "sometime in the next few minutes" and an occasional skipped run are acceptable. Set startingDeadlineSeconds and spec.timeZone sensibly and they'll serve you well.

Reach for an external trigger when exact timing, guaranteed execution, or missed-run alerting matter — billing runs, data exports, SLA-bound syncs — the jobs where a silent skip has real consequences.

Get Started

Kubernetes is excellent at running jobs and only best-effort at scheduling them. Separate the two:

Expose the job as an authenticated endpoint (or use the Kubernetes API to create the Job).
Create a Runhooks account and trigger it on an exact schedule with retries, logs, and missed-run alerts.
Build and preview your cron expression with the cron visualizer.

Frequently Asked Questions

Why is my Kubernetes CronJob not running?

The most common causes are: the CronJob controller was unavailable past startingDeadlineSeconds so the run was skipped; concurrencyPolicy: Forbid suppressed the run because the previous job was still active; the schedule is being interpreted in UTC rather than your local timezone; or the job hit the "too many missed start times" condition after being paused or after the controller fell behind. None of these produce an obvious error unless you're watching events.

What does "too many missed start times" mean in Kubernetes?

The CronJob controller logs "Cannot determine if job needs to be started: too many missed start times" when it counts more than 100 missed schedules since the last successful run. This usually happens after the CronJob was suspended, or the controller was down long enough to miss many runs. Once it trips, the controller stops trying to catch up and your job stays stopped until you fix the underlying gap.

How do I make a Kubernetes CronJob run reliably on time?

For jobs where exact timing and guaranteed execution matter, trigger the work from outside the cluster instead of relying solely on the CronJob controller. An external scheduler like Runhooks calls an in-cluster endpoint (or an API that creates the Job) at the precise time, retries if the call fails, logs every attempt, and alerts you when a run is missed — the visibility native CronJobs don't provide.

Do Kubernetes CronJobs support timezones?

Modern Kubernetes supports a spec.timeZone field on CronJobs, but many clusters and manifests still rely on the controller's default, which interprets schedules in UTC. If you set 0 9 * * * expecting 9am local time and the controller uses UTC, the job runs at the wrong hour. Always set timeZone explicitly, or drive the schedule from an external scheduler where the timezone is unambiguous.

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

Keeping AWS Lambda Warm Without Provisioned Concurrency

Ronen Cypis — Sun, 27 Sep 2026 15:00:25 +0000

Your Lambda-backed API is quick — until the first call after a quiet period. That one takes a second or two longer than the rest, sometimes enough to trip a client timeout. Call it again and it's snappy.

That first slow call is a cold start, and AWS's official fix for it — provisioned concurrency — solves the latency but adds a bill you may not want for a low-traffic function.

Why Lambda Cold Starts Happen

Lambda runs your code in an execution environment that AWS creates on demand. When a function goes idle, AWS reclaims that environment. The next invocation has to build a new one: download your deployment package, start the runtime, and run your initialization code (imports, SDK clients, database connections) before your handler even begins.

That setup is the cold start. It's most painful for:

Functions in a VPC, which historically pay extra for network setup.
Large dependency bundles, which take longer to load.
JVM and .NET runtimes, which have heavier startup than Node.js or Python.

AWS's answer is provisioned concurrency: keep a set number of environments initialized and ready at all times. It delivers consistent low latency — and it bills you to keep those environments warm continuously, whether or not anyone is calling. For a function that's idle most of the day, that's paying full-time to fix an occasional delay.

The Fix: A Scheduled Warm-Up Invocation

There's a lighter approach: invoke the function yourself on a schedule so AWS keeps at least one environment warm between real requests.

Most Lambda functions sit behind an API Gateway route or a Function URL. Point a scheduled GET at a lightweight health path:

export const handler = async (event) => {
  // A cheap path that skips the real work when it's just a warm-up.
  if (event.rawPath === '/health' || event.warmup) {
    return { statusCode: 200, body: 'ok' };
  }
  // ... real handler logic
};

Then schedule that request every 5 minutes (*/5 * * * *). Each invocation keeps an execution environment alive, so the next real caller lands on a warm function instead of paying the cold-start tax — and you only pay for a handful of short pings an hour, not a continuously provisioned environment.

Why a DIY Cron Job Isn't Enough

You could schedule the ping with a cron job, or even an EventBridge rule. Both have gaps:

A laptop or VPS cron job stops when the machine sleeps, and means running a server to keep your serverless function warm.
Fails silently. If a warm-up call errors, there's no retry, no alert, no log — the environment goes cold and the next user notices.
No unified execution history. Correlating a slow request with a missed warm-up means digging through scattered logs.
No retries. A single dropped ping can be the gap where the environment is reclaimed.

You can bolt retries, logging, and alerting onto a curl or a Lambda-invoking script — but at that point you've rebuilt a scheduler.

How Runhooks Keeps Lambda Warm

Runhooks is a scheduled HTTP execution service with reliability built in. Warming a function is a two-minute setup:

Create a job — name it "Lambda keep-warm."
Set the URL — your API Gateway or Function URL health path, e.g. https://abc123.execute-api.us-east-1.amazonaws.com/health.
Set the schedule — */5 * * * *.
Enable retries — 3 attempts with exponential backoff.

What you get beyond a bare cron job or EventBridge rule:

Execution logs — every warm-up recorded with status, response, and duration.
Automatic retries — a transient failure retries instead of leaving the function to go cold.
Failure alerts — if the function starts erroring, you're notified immediately.
Managed infrastructure — runs 24/7, independent of your own machines.

Because each ping is logged and alertable, you get keep-warm and uptime monitoring in one job: the invocations keep an environment ready, and the alerts catch a genuinely broken function rather than just a cold one.

When Provisioned Concurrency Is Still Worth It

To be fair, warming isn't a total replacement. If you need guaranteed zero cold starts under load — a high-traffic, latency-critical API where a burst of concurrent requests must all be fast — provisioned concurrency pre-initializes the environments a warm-up ping can't. A single warm environment handles the trickle after it; it doesn't pre-warm the extra environments Lambda spins up when concurrency spikes.

Use a scheduled warm-up when you want to kill the idle cold start on a low-traffic function without paying to keep environments provisioned around the clock. Reach for provisioned concurrency when consistent latency at scale is a hard requirement.

Get Started

Lambda's pay-per-use model is great for cost — cold starts are the trade-off, and you can soften them cheaply:

Add a lightweight health path to your function.
Create a Runhooks account and schedule a GET every 5 minutes.
Callers hit a warm function, and you get alerted if it starts failing.

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

Frequently Asked Questions

Why does AWS Lambda have cold starts?

When a Lambda function hasn't been invoked recently, AWS tears down its execution environment. The next invocation has to create a fresh environment — download your code, start the runtime, and run any initialization — before your handler runs. This adds latency, and it's worst for functions in a VPC, with large dependency bundles, or on JVM and .NET runtimes.

How do I keep a Lambda function warm?

Invoke the function on a schedule so AWS keeps its execution environment alive between real requests. A warm-up invocation every 5 minutes is the common interval. You can trigger it by calling the function's API Gateway URL or Function URL on a schedule with an external scheduler like Runhooks, which also retries failed pings and alerts you when the function errors.

Is a warm-up ping cheaper than provisioned concurrency?

For low-traffic functions, yes. Provisioned concurrency bills you to keep a set number of environments initialized around the clock. A warm-up ping only pays for a short invocation every few minutes, which is far cheaper for functions that are idle most of the time. Provisioned concurrency is still the right tool when you need guaranteed zero cold starts at scale.

Does pinging a Lambda eliminate all cold starts?

It keeps one execution environment warm, which removes the cold start for the steady trickle of traffic that follows. It does not remove cold starts that happen when many requests arrive at once and Lambda spins up additional concurrent environments. For that, provisioned concurrency is the answer. For most low-traffic APIs and webhooks, a single warm environment covers it.

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

Worker Exceeded CPU Time Limit? Split the Job to Fix It

Ronen Cypis — Sun, 27 Sep 2026 14:56:51 +0000

Your Worker runs fine on small inputs. Then you point it at the full dataset and it dies mid-run with:

Error 1102: Worker exceeded CPU time limit

Nothing's wrong with your logic — you've hit a per-invocation CPU ceiling. And the fix isn't a bigger limit. It's a smaller job.

Why Cloudflare Limits CPU Time

Cloudflare Workers run on shared infrastructure at the edge, so each invocation gets a bounded slice of CPU time — the time actually spent computing. Crucially, this is not wall-clock time: a Worker can await a slow subrequest for a while without penalty, because waiting on I/O doesn't burn CPU. What burns CPU is work — looping over tens of thousands of records, parsing a huge payload, hashing, transforming.

The exact budget depends on your plan and changes over time (as of 2026, check Cloudflare's current docs for the numbers). The free plan gives a small CPU budget per request; paid plans give far more and let you raise the ceiling in configuration. But every plan has a per-invocation cap, so any job whose CPU cost grows with your data will eventually cross it — a bigger plan just moves the wall further out.

The common thread: the CPU limit protects Cloudflare's shared edge, not your batch job. For request-sized work it's invisible. For "process everything" work, it's a hard stop.

The Fix: Split the Work Across Invocations

If the work is divisible — a bulk import, a mailing, a nightly sync, reindexing 100k rows — you don't need one long invocation. You need many short ones, each processing a batch that finishes comfortably under the CPU limit.

The pattern is a cursor plus repeated triggering:

export default {
  async fetch(request, env) {
    const BATCH = 500;
    const cursor = Number(new URL(request.url).searchParams.get('cursor') ?? 0);

    const rows = await getRows(env, cursor, BATCH);   // fetch a small batch
    for (const row of rows) await processRow(env, row); // stays under CPU limit

    const next = cursor + rows.length;
    const done = rows.length < BATCH;
    return Response.json({ processed: rows.length, next, done });
  },
};

Each call does a bounded amount of CPU work and returns where to resume. Something on the outside just has to keep calling it — advancing the cursor — until done is true. That "something" is a scheduler.

Why a DIY Loop Isn't Enough

The obvious approach is a script that calls the Worker in a loop, or a laptop cron job:

Requires an always-on machine. A local loop dies when your laptop sleeps; a VPS means running a server to drive an edge Worker.
Fails silently. If a batch errors or times out, a naive loop either stops (leaving the job half-done) or barrels past the failure with no record.
No execution history. When the backlog stalls at row 45,000, you have no log of which batch failed or why.
No retries. A transient subrequest error kills a batch, and nothing retries it.

You'd end up rebuilding retries, logging, and alerting around the loop — a scheduler, minus the guarantees.

How Runhooks Drives the Batches

Runhooks is a scheduled HTTP execution service. Draining a large job is a two-minute setup:

Create a job — name it "Reindex batch."
Set the URL — your Worker endpoint, e.g. https://your-worker.workers.dev/.
Set the schedule — frequently enough to drain the backlog, e.g. */2 * * * *.
Enable retries — a failed batch retries instead of stalling the run.

What you get that a DIY loop doesn't:

Reliable cadence — batches fire on schedule until the work is done, without a machine of your own.
Automatic retries — a transient failure retries at 1s → 2s → 4s instead of dropping a batch.
Execution logs — every batch recorded with status, response, and duration, so you can watch the cursor advance and spot where it stalled.
Failure alerts — if batches start failing, you're notified immediately rather than discovering a half-processed dataset later.

Keep your batch logic small enough to stay under the CPU limit, and let Runhooks handle the "run it again until it's done" part.

When a Scheduler Can't Help

Be honest with yourself about the workload. Splitting only works when the job is divisible. If a single unit of work is itself too CPU-heavy — one massive cryptographic operation, an in-memory transform that can't be chunked, a computation that must complete in one pass — no amount of scheduling helps, because you can't make one invocation cheaper by calling it more often.

For genuinely indivisible heavy compute, reach for Cloudflare Queues or Durable Objects to restructure the work, or move that step to a runtime built for long-running jobs. A scheduler is the right tool for orchestrating divisible batches — not for extending a single expensive computation.

Get Started

The CPU limit isn't a wall you upgrade past — it's a nudge to size your jobs to the request:

Rewrite the heavy job to process one bounded batch per invocation, with a cursor.
Create a Runhooks account and trigger it on a schedule with retries and logs until the backlog drains.
Build and preview your cron expression with the cron visualizer.

Frequently Asked Questions

What does "Worker exceeded CPU time limit" mean?

It means your Worker used more CPU time in a single invocation than its plan allows, so Cloudflare terminated it (Error 1102). CPU time is the time actually spent computing — not the wall-clock time spent waiting on network or subrequests. A Worker can wait a long time on I/O without a problem, but a tight loop over a large dataset burns CPU time fast and trips the limit.

How much CPU time does a Cloudflare Worker get?

It depends on your plan, and the limits change over time — check Cloudflare's current docs for exact numbers. The free plan allows only a small CPU budget per invocation, while paid plans allow far more and let you raise the ceiling via configuration. The key point is that every plan has a per-invocation CPU cap, so a single job that grows without bound will eventually hit it regardless of plan.

How do I process a large job without hitting the CPU limit?

Split the work so each invocation processes a small batch that finishes well under the CPU limit, then run the Worker repeatedly until the whole dataset is done. Track progress with a cursor (an offset, an ID, or a queue) so each run picks up where the last left off. An external scheduler like Runhooks triggers the Worker on a schedule, retries a failed batch, and logs each run so you can watch the backlog drain.

When can't a scheduler help with the CPU limit?

When the work is a single indivisible computation — one large cryptographic operation, an in-memory transform that can't be chunked, or anything that must complete in one pass. Splitting only helps divisible workloads like bulk imports, mailings, and syncs. For indivisible heavy compute, use Cloudflare Queues, Durable Objects, or move that step to a runtime built for long-running work.

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

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.

DEV Community: Ronen Cypis

Kubernetes CronJob Not Running? Fixing Missed Schedules

Why Kubernetes CronJobs Miss Runs

1. The controller fell behind, or was down

2. startingDeadlineSeconds skipped it

3. concurrencyPolicy: Forbid suppressed it

4. "Too many missed start times"

5. Timezone confusion

The Fix: Trigger and Watch From Outside the Cluster

Why a DIY External Cron Isn't Enough

How Runhooks Triggers Kubernetes Jobs Reliably

When the Built-in CronJob Is Fine

Get Started

Frequently Asked Questions

Why is my Kubernetes CronJob not running?

What does "too many missed start times" mean in Kubernetes?

How do I make a Kubernetes CronJob run reliably on time?

Do Kubernetes CronJobs support timezones?

Keeping AWS Lambda Warm Without Provisioned Concurrency

Why Lambda Cold Starts Happen

The Fix: A Scheduled Warm-Up Invocation

Why a DIY Cron Job Isn't Enough

How Runhooks Keeps Lambda Warm

When Provisioned Concurrency Is Still Worth It

Get Started

Frequently Asked Questions

Why does AWS Lambda have cold starts?

How do I keep a Lambda function warm?

Is a warm-up ping cheaper than provisioned concurrency?

Does pinging a Lambda eliminate all cold starts?

Worker Exceeded CPU Time Limit? Split the Job to Fix It

Why Cloudflare Limits CPU Time

The Fix: Split the Work Across Invocations

Why a DIY Loop Isn't Enough

How Runhooks Drives the Batches

When a Scheduler Can't Help

Get Started

Frequently Asked Questions

What does "Worker exceeded CPU time limit" mean?

How much CPU time does a Cloudflare Worker get?

How do I process a large job without hitting the CPU limit?

When can't a scheduler help with the CPU limit?

Cron Job Monitoring Tools Compared: From DIY to Fully Managed

Heartbeat Monitoring vs. Execution Monitoring

Comparison at a Glance

DIY Monitoring

Healthchecks.io

Cronitor

Better Stack (formerly Better Uptime)

PagerDuty / Opsgenie

Runhooks Built-In Monitoring

Choosing the Right Approach

Get Started

Frequently Asked Questions

How do I know if my cron job stopped running?

What is the difference between heartbeat monitoring and execution monitoring?

What is the best free cron job monitoring tool?

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

Best External Cron Job Services Compared (2026)

Quick Comparison

Cron-job.org

EasyCron

Cronhooks

Google Cloud Scheduler

AWS EventBridge Scheduler

Runhooks

Get Started

Frequently Asked Questions

What is an external cron job service?

Is cron-job.org reliable enough for production?

What is the best EasyCron alternative?

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

Scheduling Cloudflare Workers Beyond Cron Triggers

How Cloudflare Cron Triggers Work

The Limitations of Cron Triggers

Trigger limits per worker

No retries on failure

Limited execution visibility

No failure alerts

CPU time constraints

2. `startingDeadlineSeconds` skipped it

3. `concurrencyPolicy: Forbid` suppressed it