A GitHub Actions Cron Alternative for Scheduled Jobs

Using GitHub Actions as a cron scheduler is one of those decisions that works well enough for long enough that you build real dependencies on it. It's free, it's already in the repo, and it's three lines:

on:
  schedule:
    - cron: '0 * * * *'

Then one day you look at the run history and your hourly job went at 17:00, 18:47, and 19:52. Nothing on your side changed.

Why It Drifts

GitHub documents schedule as best-effort, and they mean it. Scheduled workflows queue on shared infrastructure, and when the platform is busy they wait their turn.

Delays of five to twenty minutes are normal. Jobs at the top of the hour fare worst, because everyone writes 0 * * * * and the queue at :00 is enormous — scheduling at :07 or :23 measurably improves your odds, which tells you everything about what's going on underneath. Under heavy load runs get dropped entirely rather than delayed.

And then there's the one that actually causes incidents: scheduled workflows disable themselves after 60 days without repository activity. A backup job on a mature, stable repo — exactly the kind of repo nobody pushes to — quietly stops. Nothing tells you. Any push re-enables it, so it works again the moment you investigate, which is its own special kind of frustrating.

When None of That Matters

Plenty of jobs genuinely don't care. Nightly dependency scans, weekly stale-issue cleanup, cache warming where a miss costs nothing, anything that reads the repo and opens a PR.

If the job is repo-related, tolerant of an hour's drift, and its failure is obvious next time you glance at the Actions tab, stay where you are. It's free and it's already there, and adding a service to solve a problem you don't have is its own mistake.

When to Move It

Move when timing is part of the requirement — an invoice run on the first of the month, a report that needs to be in someone's inbox at 09:00, a rate-limited API you're calling on a deliberate cadence. Arbitrary delay breaks all of those.

Move when the job has nothing to do with the repository. If you're pinging a health endpoint or triggering a webhook, you're spinning up a virtual machine and doing a full git checkout to make one HTTP request, and you're only there because Actions was the nearest thing to cron.

Move when silent failure is expensive. Actions will email you about a failed workflow, eventually, if notifications are on and somebody reads them. It cannot tell you that a run never happened — and after 60 quiet days, that's precisely the failure you get.

And move if you want retries with any judgment to them. Retrying inside a workflow means writing shell loops. There's no "try three times with backoff, then alert me."

What a Dedicated Scheduler Gives You

A job that's fundamentally "call this URL on this schedule" doesn't need a VM, a checkout, or a YAML file. It needs a URL, a method, headers, a body, and a cron expression:

schedule: 0 9 * * 1-5
timezone: America/New_York
method:   POST
url:      https://api.example.com/reports/daily
headers:  Authorization: Bearer ...
retries:  3

With Bluejay Schedule that runs on time, because it isn't queued behind everybody's CI. The timezone is a real IANA zone, so 0 9 * * 1-5 stays 9am local across daylight saving instead of drifting an hour twice a year — more on that here. Retries are configured rather than scripted. Run history keeps the status, timing, and response body for every execution.

The one I'd point at specifically is the missed-run monitor: you declare how long you're willing to go without a success, and it alerts when that window passes empty. That's the failure Actions structurally cannot detect, because nothing failed — nothing ran. Pair it with auto-disable after repeated failures so a job hammering a dead endpoint stops on its own, and you have a schedule that keeps running because it's a schedule, not because someone pushed a commit recently.

You Can Keep Both

This isn't all-or-nothing, and the split is usually obvious. Jobs that build, test, or modify the repo stay in Actions — they need the checkout and the runner. Jobs that call an HTTP endpoint on a timetable move out, because they need neither.

There's a nice middle option too. Keep the logic in Actions and stop relying on schedule: to start it — trigger the workflow over the API from a scheduled call:

POST https://api.github.com/repos/{owner}/{repo}/actions/workflows/{id}/dispatches
Authorization: Bearer <token>
Body: { "ref": "main" }

The schedule becomes accurate and monitored, and the job still runs exactly where it always did.

---

Run scheduled jobs on time, with alerts when they don't. Try Bluejay Schedule free.