You set up a workflow to run every morning. It worked for a week, then two weeks. Then one day you check the Actions tab and see the last run was a month ago.
No error. No email. It just stopped.
If you use GitHub Actions for small automations like reports, checks or posts, this can happen to you. The scheduler isn't broken. It just works differently from what most people expect.
"Every day at 9:00" is more of a suggestion
When you write a cron schedule in GitHub Actions, you're telling GitHub when you'd like the workflow to start. You're not guaranteeing it.
GitHub says scheduled runs can be delayed when a lot of workflows are running at once. The busiest time is the start of every hour. In bad cases, a queued run can be dropped completely.
If your workflow is set to 0 9 * * *, you're asking for the most crowded minute of the day. Try 17 9 * * * instead. The odd minute costs you nothing, and it makes a delay less likely.
The 60-day quiet period
This is the one that catches people.
In a public repository, GitHub automatically turns off scheduled workflows after 60 days without any repository activity. Your workflow file is still there and the cron line still looks fine, but it has been switched off.
Picture a small shop owner who sets up a Monday morning sales summary. The workflow works, so they leave the repo alone. Two months later the summaries stop, and nobody notices until someone asks where the numbers went.
To fix it, open the Actions tab and re-enable the workflow. Any new activity in the repo resets the clock. If your automation is the only thing in that repo, put a reminder in your calendar every couple of months.
A few other quiet reasons
Sometimes nothing is wrong with the schedule. The setup just doesn't match what GitHub expects.
- Wrong branch. Scheduled workflows only run from the default branch. A workflow that only exists on a feature branch will never fire.
- Forks. If you forked someone's project, scheduled workflows in your copy don't run until you enable them.
- Time zones. Cron times are in UTC by default. "9:00" may not be 9:00 where you are.
- The person who last edited it left. If that person is removed from the repository, the scheduled workflow can be disabled. Changing the cron line with write access turns it back on.
- Too frequent. The shortest interval is every 5 minutes. Anything faster won't work.
Why this is worse than it sounds
A workflow that fails loudly is easy to deal with. You get a red mark, you look at it, you fix it.
A workflow that stops running leaves nothing to look at. There's no failed run, because there's no run at all.
Say you built a free uptime check that pings your website every 10 minutes. If the schedule quietly stops, you have no monitoring. You'd find out when a customer tells you your site has been down. (If you want to build one, I wrote a Python uptime monitor guide.)
What you can do about it
You don't need anything complicated. A few habits cover most of it.
Pick odd minutes. Avoid :00 and :30 when you can.
Make the job forgiving. If a run is late or skipped, the next one should catch up. A script that says "process everything since the last successful run" is safer than one that assumes it runs exactly on time.
Watch for the absence of a run. This is the important one. Add a last step that sends a small "I finished" ping to a monitoring service, and set that service to alert you when a ping doesn't show up. Now silence sets off the alert.
I go into this more in how to monitor your automations when something breaks.
Check once in a while. Open the Actions tab once a month and look at the run history. It takes two minutes.
When GitHub's scheduler isn't the right tool
If a task has to run at an exact time, like a payment cutoff or a message that must go out at a specific minute, a free scheduler on shared infrastructure may not be enough. That isn't a flaw. GitHub built it for convenience, not precision.
For a daily report, a content post or a website check, a few minutes of drift usually doesn't matter. Just make sure you'd notice if it stopped.
The short version
A scheduled workflow is convenient, but it isn't guaranteed. It can run late, get dropped, or switch itself off.
So ask yourself: if this stopped tomorrow, how long would it take you to find out?
If the answer is "a while," add the heartbeat check first. You can find more practical automation guides on Procwire.
Top comments (0)