Which job schedulers fire on time? We tested ten. | smplkit blog
Log in
Menu Products Smpl Audit™<br>Smpl Config™<br>Smpl Flags™<br>Smpl Jobs™<br>Smpl Logging™
Pricing Docs Agents GitHub
← All posts Which job schedulers fire on time? We tested ten.<br>Mike Gorman July 31, 2026 · 6 min read
comparison<br>cron<br>scheduled-tasks<br>benchmark<br>One of the application infrastructure products we built for smplkit is an HTTP job<br>scheduler called Smpl Jobs. Of course, we wanted it to compare favorably<br>with competing job schedulers, but we wondered how well it really stacked up in terms of what matters: making<br>HTTP requests on time . We decided to find out.
The contestants
AWS EventBridge
Cloudflare Workers
cron-job.org
EasyCron
GitHub Actions
Google Cloud Scheduler
Posthook
QStash
Runhooks
Smpl Jobs
The setup
The idea was simple: fire a request at the top of the hour at some public endpoint and capture the date/time it<br>arrives. The number of milliseconds past the hour is the skew: the lower the skew, the more “on time” the scheduler<br>is.
While the idea may be simple, actually finding a public endpoint schedulers can hit that will also capture and store<br>the received time was not so simple. Ultimately, what we were looking for was some general-purpose benchmark-hosting<br>website that we could POST JSON messages to that would identify the benchmark, the subject, and record the date/time<br>the request arrived. We couldn’t find anything that worked the way we wanted it to so we built one. Three weeks later,<br>smplmark.org was open for business and ready to start hitting with the schedulers we wanted to test.
We created the benchmark, defined the subjects, and then configured each scheduler to fire a request at smplmark’s<br>measurement API with a JSON<br>payload identifying the benchmark, the run, and the ID of the scheduler being tested. smplmark records the date/time<br>each measurement was created; a separate skew metric is derived from that as created_at mod 3600000 which gives<br>us the number of milliseconds past the top of the hour.
Every contestant runs on its free tier — or close to it: a couple of them bill us about a dollar a month. Partly to<br>keep the field level; mostly to keep the bill near zero.
Why I built smplmark.org
A few flaws
The methodology has four flaws we know about:
Skew is computed modulo the hour, so a scheduler that fires exactly 60.1 minutes late will actually look<br>like it’s only 6 seconds late. It’s a corner case: the only contestant late enough to threaten the wrap is<br>GitHub Actions, and they miss by wild margins, not by seconds.<br>The wrap cuts the other way too: a request that arrives early would read as nearly an hour late. But the<br>only arrivals anywhere near the wrap belong to GitHub Actions, and their unreliability is obvious (and<br>well-documented).
The endpoint is in US-East so schedulers running in US-West, or Europe, will pay a network tax the US-East schedulers<br>don’t pay. But it’s only a few milliseconds; the scheduler’s engine is ultimately what dominates.
smplmark.org itself runs on Cloudflare so Cloudflare Workers may have a home-field<br>advantage; its request may never leave Cloudflare’s network.
The skew trusts smplmark’s clock. smplmark runs on Cloudflare, whose clocks are NTP-synced; we don’t independently<br>verify them. If that clock drifted, every subject would shift by the same amount — the ordering would survive, the<br>absolute numbers wouldn’t. A scheduler’s own clock is not corrected for: firing when your clock says it’s time is part<br>of what’s being measured.
The leaderboard
Here’s where things currently stand. The images below are pinned snapshots, so the numbers we cite stay next to the<br>charts they came from; the live board updates every hour and will have moved by the time you read this.<br>We removed GitHub Actions from this chart because, at its scale, the other bars<br>stop being visible.
Median skew in milliseconds past the top of the hour as of July 31. Open the live board for current numbers and methodology.
What the numbers say
Posthook lands closest to the mark with a median skew of 656 ms followed closely by Runhooks at 749 ms. QStash and<br>Smpl Jobs are locked in a dead heat at around a second and a half and, behind them, EasyCron, Google Cloud Scheduler,<br>and cron-job.org all consistently fire within about 4 to 8 seconds of the requested time.
Four days of arrivals ending the morning of July 31, one point per arrival, GitHub Actions excluded for scale.
Curiously, AWS EventBridge arrives almost exactly 26.5 seconds late.<br>Every arrival we’ve logged sits inside a band a few hundred milliseconds wide; you could set a watch by exactly how<br>late it is. In fairness, EventBridge exists to fan events out at enormous scale, and it’s good at that.
Cloudflare Workers is also consistently late: typically about 33 seconds past the hour — though a handful of runs<br>this week drifted toward 51 seconds. The one contestant whose request we thought might never leave<br>its own network still...