My Workflow Scheduled Itself into a Black Hole: The Silent Death of the '0/5' Cron

Your GitHub Actions schedule is a suggestion, not a command. You can spend hours crafting the perfect YAML, double-checking your logic, and pushing to main with the confidence of a senior dev, only to find that your workflow has entered a state of permanent hibernation. If you’ve ever used 0/5 * * * * in a cron trigger and wondered why the "Actions" tab looks like a ghost town, you've fallen into the syntax trap.

Cron is one of those technologies we all pretend to understand until we’re staring at a crontab -e prompt with sweat on our brows. When it comes to GitHub Actions, the stakes are weirdly higher because there’s no immediate feedback loop. You push the code, and then... you wait.

The Syntax That Failed You

In many cron dialects—like the ones you’d find on a standard Linux box or within Jenkins—writing 0/5 * * * * is a common way to say "run every five minutes, starting at minute zero."

However, GitHub Actions uses a specific flavor of cron parsed by a library that can be a bit particular. In the world of GitHub, 0/5 is often interpreted literally as "starting at minute 0, run every 5 minutes." While that sounds correct, the parser frequently chokes on the 0/5 format or treats it as a single execution point.

The industry standard for "every 5 minutes" is the wildcard slash:

on:
  schedule:
    # This is the "correct" way that won't make the parser cry
    - cron: '*/5 * * * *'

If you use 0/5, you aren't necessarily "wrong" by historical standards, but you are playing a dangerous game with GitHub’s internal scheduler. I’ve seen workflows with 0/5 run exactly once and then never again, as if the runner decided it had fulfilled its life’s purpose and retired.

The Five-Minute Floor

Even if you get the syntax right, there’s a hard reality you have to accept: GitHub does not care about your deadlines.

The documentation states that the shortest interval you can run a scheduled workflow is every 5 minutes. If you try to be clever and set it to */2 * * * *, GitHub won’t throw an error. It won't email you. It will just silently throttle your workflow to run whenever it feels like it—usually around the 5-minute mark, but often much later.

During periods of high load on GitHub’s infrastructure, that "every 5 minutes" cron might actually fire every 10, 15, or even 30 minutes. If your business logic depends on high-precision timing, GitHub Actions schedules are the wrong tool for the job.

Why Your Cron is Ghosting You

Aside from syntax errors, there are three common reasons your scheduled workflow isn't firing:

1. The "Main" Branch Requirement: Scheduled workflows only run if the workflow file exists on the default branch (usually main or master). If you’re testing your cron on a feature branch, it will never trigger. This is a classic "I’ve been staring at this for two hours" mistake.
2. Repo Inactivity: If your public repository has had no activity for 60 days, GitHub will automatically disable your scheduled workflows. You’ll get an email, but let’s be honest, that’s going straight to your "Updates" folder to die.
3. The Delay Queue: Scheduled jobs are queued. If the "Actions" servers are slammed (hello, Tuesday mornings), your 9:00 AM job might not start until 9:20 AM.

A Better Way to Test

Waiting five minutes to see if a cron works is a terrible way to spend an afternoon. Instead of sitting there hitting refresh, add the workflow_dispatch trigger to your YAML:

on:
  schedule:
    - cron: '*/15 * * * *'
  workflow_dispatch: # This allows you to trigger it manually for testing

jobs:
  heartbeat:
    runs-on: ubuntu-latest
    steps:
      - name: Proof of Life
        run: echo "The machine is breathing."

By adding workflow_dispatch, you can trigger the job manually from the GitHub UI to ensure the actual logic works. Once you know the job functions, you can trust the cron—as much as one can trust a cloud-based scheduler, anyway.

Final Thoughts

If your workflow has disappeared into the black hole of the 0/5 syntax, switch to */5. It’s more portable, more standard, and less likely to confuse the parser.

And for the love of all that is holy, if you need something to run exactly every 60 seconds, stop using GitHub Actions and go find yourself a dedicated VPS or a serverless function with a guaranteed trigger. GitHub Actions is a powerhouse for CI/CD, but as a precision clock, it’s a bit of a sundial.