← All guides

Scheduled workflows: the GitHub Actions cost nobody is watching

A workflow on a schedule: trigger has a property no other CI job has: it runs with nobody waiting on it. No PR author watching the check, no reviewer blocked. That makes scheduled workflows the place where CI cost and CI rot go to hide — they burn minutes around the clock, and when they hang or break, they hang or break silently.

The runaway case: a nightly build with no ceiling

nodejs/node runs a daily workflow (cron: 0 0 * * *) that does a full LTO build — configure, then a whole-program optimized compile, one of the most expensive things you can ask CI to do — and at the time of writing, no job in that file sets timeout-minutes. If that build ever wedges, it rides GitHub's six-hour default. Every night. Nobody is watching a nightly job's duration, so the failure mode isn't a red X you notice — it's a number on next month's usage report.

The fix is the same one line as always, it just matters more here (the timeout guide has the details):

jobs:
  nightly:
    runs-on: ubuntu-latest
    timeout-minutes: 90   # a ceiling sized to the build, not GitHub's 360

The frequency case: crons that fire more than they need to

cal.com has a workflow that fires every 15 minutes (cron: "*/15 * * * *") to curl an internal reminder endpoint — 96 runs a day for a job an external cron service (or a single scheduled function) would do without spinning up a runner. Each run is small; the cadence is what costs. Audit every cron in your repo against one question: what breaks if this ran half as often? The answer is usually "nothing."

The good pattern, from a repo that does it right

serde runs a daily scheduled CI pass too — with timeout-minutes: 45 on every single job in the file. A wedged nightly run costs serde 45 minutes, not six hours. That is the whole discipline: scheduled workflows get a timeout first, because they're the ones nobody will catch by hand.

While you're in there: check for zombie crons

Scheduled workflows are also where always-failing workflows live — the cron that has been red for months because the thing it deploys or lints moved on. A schedule that fires, fails, and gets ignored is pure burn. Fix it or turn it off; don't let it keep billing you for red.

Audit yours in two minutes

GitSpider's scan flags crons that fire more than ~4×/hour, scheduled workflows failing on nearly every run, and every job missing timeout-minutes — the three ways a schedule quietly drains minutes.