11 best cron job services for 2026: an honest comparison

If you need to make some HTTP request on a schedule, you’ll find there are two very different kinds of products answering to the name “job scheduler” and it’s not always obvious which kind you’re looking at. So our first order of business is to understand how these two types of job schedulers work.

Full disclosure: I build one of the schedulers on this list: Smpl Jobs. I’ve put it where I think it belongs and said where I think the others are stronger. This is one of our honest comparisons; the rest live under the comparison tag.

The two kinds of “job scheduler”

Cloud-platform schedulers that execute arbitrary code

AWS EventBridge, Cloudflare Workers, GitHub Actions, Google Cloud Scheduler, and Vercel Cron Jobs all live here. They execute arbitrary code on a schedule. It’s up to you as to what happens after that. In our case, we’ll have them make an HTTP request. But capturing the response, keeping a history of runs, or having it retry transient failures are all yours to build. We’ll call this type a trigger.

Purpose-built, managed services

cron-job.org, EasyCron, Posthook, Runhooks, Smpl Jobs, and Upstash QStash live here - though, as you’ll see, a couple of them are in this camp on a technicality. You give them a URL and a schedule. They make the call, and most of them record the response and keep the history. Nothing to deploy, no database to wire up. We’ll call these managed services.

The field at a glance

Service	Type	Timezones	Captures response	History API	Retries	Free tier
AWS EventBridge	Trigger	✓	✗	✗	✓	14M/mo
Cloudflare Workers	Trigger	✗	✗	✗	Undocumented	5 jobs
cron-job.org	Managed	✓	✓	✓	✗	Unlimited
EasyCron	Managed	✓	✓	✓	✗	200/day
GitHub Actions	Trigger	✓	Logs only	Limited	✗	Free min
Google Cloud Scheduler	Trigger	✓	Logs only	✗	✓	3 jobs
Posthook	Managed	✓	Dashboard only	Limited	✓	1K/mo
Runhooks	Managed	✓	✓	✓	✓	2K/mo
Smpl Jobs	Managed	✓	✓	✓	✓	3K/mo
Upstash QStash	Managed	✓	Logs only	Limited	✓	1K/day
Vercel Cron	Trigger	✗	✗	✗	✗	1/day

✓ first-class support  ·  ✗ build it yourself

Retries: where the products actually differ

The retries column deserves more than a checkmark because “supports retries” hides four separate questions:

1. Can you configure the request timeout?
2. Can you define what counts as success, so the scheduler knows when to retry?
3. Can you shape the retry (e.g. attempts, backoff, delays)?
4. Can you define a retry policy once, name it, and reuse it across jobs?

The answers vary. EventBridge lets you configure how many retries but not the delays in between. QStash, at the other extreme, accepts a math expression for the retry delay.

But how does a scheduler know when it should retry? Most schedulers assume that any API that returns anything other than a 2xx status should be retried. But if, say, “Not Found” is also acceptable, only Smpl Jobs lets you configure that (e.g. “don’t retry a 404,” etc.).

As for reusable retry policies, Posthook supports per-project defaults, but Smpl Jobs is the only scheduler to support “named” policies that can be shared across jobs.

Service	Configure timeout	Define success	Shape the retry	Named policies
AWS EventBridge	✗	✗	Attempts, not the curve	✗
Google Cloud Scheduler	✓	✗	✓	✗
Posthook	✗	✗	✓	Project default
Runhooks	✗	✗	✓	✗
Smpl Jobs	✓	✓	✓	✓
Upstash QStash	✓	✗	✓	✗

Category 1: schedulers that trigger your code

AWS EventBridge Scheduler

EventBridge Scheduler is the most powerful option in the category, and effectively free: the free tier covers 14 million invocations a month, so a once-a-minute job won’t come close. The timezone support is real, daylight saving included. The thing to understand is what it does. EventBridge invokes a target (e.g. a Lambda function, a queue, a Step Function, or an HTTPS endpoint via an API destination). It will not call your URL and save what came back. For that you’ll wire up a Lambda to make the request and store the result, DynamoDB for the history, API Gateway to read it back, and maybe use CloudWatch for the logs. Best when you’re already on AWS, need to trigger AWS resources, or run at a scale where 14 million invocations is a number that matters.

Cloudflare Workers Cron Triggers

If you’re already on Cloudflare, Cron Triggers are about as low-friction as scheduling gets: add a cron trigger and a scheduled() handler runs your Worker. The free tier is generous and it’s fast at the edge. It runs in UTC only, though, with no timezone handling, and you’ll build response capture and history yourself, usually on D1 or KV. Best when you already deploy Workers and your scheduling needs are simple and UTC-friendly.

GitHub Actions (scheduled workflows)

Scheduled workflows are free for small jobs, with no new infrastructure if the code already lives on GitHub. But don’t count on them to execute on time. When we measured it, the median run was roughly 22 minutes late. Like the other schedulers in this category, capturing responses is up to you. Ultimately, it’s a CI tool that happens to have a timer. Best when the task is CI-adjacent and occasional, and exact timing doesn’t matter.

Google Cloud Scheduler

Cloud Scheduler is Google’s managed cron, and it’s priced by an unusual meter: you pay per job definition - $0.10 a month each. Your first three are free and executions cost nothing, so a job can fire every minute all month for a dime. Timezone support is full IANA with daylight saving observed and retries get proper exponential backoff. It will happily call any public URL, but it keeps nothing your endpoint says: each run writes start and finish entries to Cloud Logging, the HTTP status code surfaces only in the failure text, and there’s no executions API to fetch run history. Best when you’re already on Google Cloud and want an SLA-backed trigger for Cloud Run, Pub/Sub, or a public URL, and don’t need to capture the response.

Vercel Cron Jobs

Vercel Cron Jobs are a solid choice if you just want one of your existing Vercel routes invoked on a schedule. But the “Hobby” plan only gets you one run per day, and even that is approximate. A job set for 1:00 can fire anywhere in the following hour. To get per-minute scheduling, you’ll need to upgrade to “Pro”. Schedules are UTC-only and capturing and querying history is up to you.

Category 2: managed cron-as-a-service

cron-job.org

cron-job.org has been running for over 15 years and is still genuinely free: unlimited jobs down to once a minute, timezone support, response capture, run-now testing, and a REST API for managing jobs and reading history. But the devil is in the details: responses are only stored for 2 days, only the last 50 executions are saved, and it won’t retry failures. Requests time out at 30 seconds, and it’s a community-funded project with no formal SLA. Best when you want a free, no-friction way to ping a URL and see recent responses.

EasyCron

EasyCron is one of the longest-running services in the category. It supports per-job timezones and captures responses, but it won’t retry failures. The free plan allows up to 200 executions a day with a 20-minute minimum interval; paid plans start around $24 a year and unlock one-minute intervals and higher volumes. Best when you have a modest number of URL-pinging jobs and want a proven, no-surprises service.

Posthook

Posthook is a bit specialized. Its bread and butter is the one-off hook (i.e. POST to this path at this exact time, in any timezone you name, daylight saving handled), while recurring schedules come from a fixed menu of intervals rather than cron expressions. Each project is pinned to one domain with the per-hook target given as a path. Retries are configurable per project and per hook, against a fixed 10-second timeout. Responses are captured but, curiously, are only surfaced via the UI and not by any public API. The free tier is 1,000 hooks a month with 7-day history; paid plans start at $39 a month.

Runhooks

Runhooks supports cron schedules with IANA timezones (or fixed intervals), response status and body captured for every run, a REST API for run history, replay of failed executions, and retries with exponential backoff. The fine print is mostly retention and caps: the homepage’s “up to 30 days” of logs belongs to the $129 plan; the free tier keeps them for 24 hours, allows 3 jobs and 2,000 runs a month (capped at 200 a day), and times requests out at 30 seconds. Overall, a solid, API-first managed service with response capture and retries.

Smpl Jobs

Smpl Jobs supports timezone-aware cron schedules, non-recurring jobs, response capture, configurable retries via “named policies”, and RESTful APIs for querying job history. The free tier supports up to 3,000 runs a month and 30 days of run history. Smpl Jobs is also the only service whose jobs are “environment-aware”; the same job can be configured to hit different endpoints in development vs. production while role-based security governs which users are allowed to update the production configuration. And with SDKs in six languages, a CLI, and a Terraform provider, Smpl Jobs can be used for both “simple” and enterprise use cases.

Upstash QStash

QStash gets HTTP requests to your endpoints reliably, with automatic retries, a dead-letter queue, delays, and callbacks. It supports cron schedules with timezones, and the free tier covers around 1,000 messages a day. While QStash will call your API, what your endpoint said in response is only kept briefly for logging and debugging, and there’s no queryable archive of captured bodies. QStash is another solid choice if response capture is not a hard requirement.

Which should you pick?

If you want something free and bare-bones, use cron-job.org. It’s been pinging URLs for fifteen years, it’s genuinely free, and it captures responses - just accept that there are no retries, history is short, and there’s no SLA. If you outgrow it, EasyCron is in the same class with a modest price tag.

If you’re already on one of the big platforms, each vendor provides a decent solution for calling your API on a schedule. The only vendor we really can’t recommend is GitHub Actions unless you don’t really care about your jobs executing on time.

If you’re looking for a cloud-neutral solution with enterprise-class features (e.g., response capture, named retry policies, environment-aware jobs, role-based security, SDKs, CLI, Terraform, etc.), Smpl Jobs deserves serious consideration.

One more thing