Unexpected delay in scheduled GitHub Actions workflows using cron

[SssoDev]

Select Topic Area

Bug

Body

Hello GitHub Support Team,

I'm currently using GitHub Actions to schedule a workflow using the cron syntax, and I’ve been encountering some unexpected behavior related to execution time.

For example, when I set:

schedule:
- cron: "0 21 * * *"

...the job runs around 6:30 AM KST the next day. Similarly, when I set:

schedule:
- cron: "0 9 * * *"

...the job runs around 6:30 PM KST.

I also tested:

schedule:
- cron: "0 0 * * *"

...expecting it to run at 9 AM KST (since GitHub Actions use UTC), but the job ran around noon instead.

There also appears to be a consistent delay of about 30 minutes on each run, which makes it hard to determine the precise execution time.

I'm wondering:

• Are there known delays with cron jobs on GitHub Actions?
• Could workflows from other users affect when mine is executed?
• Is there any way to ensure more accurate timing?

Any insight or advice would be greatly appreciated.
Thank you in advance for your help!

Best regards,
SssoDev

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[sefinek]

Hello!

1. Hm, I just checked how it looks on my end. I have an action in one repository scheduled with 0 0 * * *. The cron job ran on April 10, 2025, at 2:29 AM (GMT+2), so with a 29-minute delay. Based on UTC, it should've triggered at 00:00 UTC, which corresponds to 2:00 AM local time in GMT+2 (daylight saving). Just to clarify, I live in the Europe/Warsaw time zone.

2. Other users’ workflows don’t directly impact your jobs, but GitHub uses a shared pool of runners (unless you're on self-hosted), so resource availability at a given moment can affect when your job actually starts.

3. If precision is crucial, it’s worth considering self-hosted runners – you get full control over the environment and avoid GitHub’s queueing. Alternatively, you can schedule the job ahead of time and use a sleep to align it with the exact hour.

[adambirds]

Self hosted runners don't stop the delay, github isn't even bothering to trigger my scheduled actions

[sefinek]

Strange, I've never had any issues like that with runners. Make sure that both the server and the workstation have their time properly synchronized.

E.g.:

dpkg-reconfigure tzdata

[braboobssiere]

• Is there any way to ensure more accurate timing?

i give up and use third party cron instead, more reliable than github built-in schedule (the delay at worst is less than 1 min. from schedule time) https://cron-job.org/en/

[adambirds]

Yeah if it doesn't get better I'm just gonna switch to cron jobs on my Kubernetes cluster tbh!

[psyfox]

Same problem here.

I'm almost giving up on using GitHub Actions in our Enterprise account...
Taking over 30 minutes to start a simple cron job that's supposed to run every 5 minutes on a self-hosted runner...
That's just surreal.

[carrotliang]

I am triggering the action by a self hosted cron api request

[psyfox]

I am triggering the action by a self hosted cron api request

Seemed to be the best fast-win solution to me so far.
Thanks.

[EmpireOperating]

This matches what we’ve seen too: GitHub Actions schedules are best-effort and can be delayed (especially at high-load times like :00). A consistent ~20–40 min delay isn’t unheard of.

A few practical mitigations:

• Avoid the top of the hour. Instead of 0 * * * *, pick something like 17 * * * * (or any “random” minute) to dodge the load spike.
• If you need tighter guarantees, treat GH schedule as a trigger source, not the clock: run a real scheduler elsewhere (k8s CronJob / system cron / cloud scheduler) and use workflow_dispatch to kick the workflow.
• If you just need “did it happen today?” reliability, add an external dead-man’s-switch (Healthchecks/Cronitor/etc). We’re building one (CronPulse) aimed exactly at “alert me when a scheduled job didn’t happen,” regardless of where it runs.

GitHub also documents that schedules can be delayed/dropped under load, so the only real fix for exact timing is an external scheduler.

[nylla8444]

experienced this too. thanks for the recommendations everyone

[takeshi-yanagita]

Coming here to chime in that this issue is still present.
Until about 3 months ago, it used to run about 9 minutes behind schedule, but has since been running at a 25-30minute delay consistently.

[nylla8444]

normal. Ive read that cron jobs are executed via shared resources (unless you host your own).

solution here is to pick a time where there is no much demand.

[takeshi-yanagita]

Makes sense.
I think that the solution for us may just be to simply set the schedule 30 minutes in advance.

[evalue-simon-harrison]

huh. Lately, our /15 mins job is running once an hour if that, even avoiding "top of the hour"

[emanuelen5]

Same issue for us. We've resorted to a separate cron job that triggers the workflow through workflow_dispatch instead. And then it runs each time on the minute regardless of how often we trigger it.

[kholiavko-roman]

My workflow is scheduled for :20 past the hour, but it often starts with a delay of more than 20 min

I specifically moved the schedule away from the start of the hour (:00) to avoid peak congestion, but the margin of error is still over 20 minutes. It's frustrating that the "best effort" delivery has become this unpredictable, making it nearly impossible to use Actions for time-sensitive infrastructure tasks.

[nylla8444]

still expected. even u think it is not in the peak time, there are still thousands or millions of people running stuff at the same time on github's server.

i recommend that you setup your own server if you need this for time-sensitive infrastructure tasks.

[stjen]

I've seen this with quite long delays even.
A job was set to trigger at 06:30 UTC (08:30 CEST). It triggered at 11:04 CEST!

[marwie]

I see the same, cron jobs trigger hours late for me which is quite frustrating.

[USBAkimbo]

@syedahmedx3 this is pathetic and embarrassing - my scheduled jobs won't start at the time they're configured for, but I can have them run at the time I want if I use a DIFFERENT scheduler to call the GitHub API and ask it to run my job?

Uh... Isn't that what the schedule in the action is supposed to do? This is ridiculous - it's bad enough that GitHub has awful service uptime, but now I find that virtually all 46 of my migrated pipelines will not run when they're supposed to

What's the point of using actions at all? I might as well throw this all in the bin and move the jobs to K8s cron jobs since I'm already providing my own runner infrastructure

Move to GitHub they said, it's better than Azure DevOps they said

Ugh

[USBAkimbo]

Thanks for the AI slop response - did you consider the reason we're having to deal with this mess to begin with is because of AI?

[joric]

My repo https://github.com/joric/leetcode/ tries to update at 00:17 GMT and it consistently runs 3.5 to 4 hours late (!)
Upd. trigger set to 21:17 fired at 22:12 GMT (1 hour delay) I am setting it to 23:17 so it fires after midnight.
Upd. trigger set to 23:17 ran at 00:07 GMT. So the delay for me is precisely 50 minutes if scheduled before midnight.

[akorp]

Since last week we also experience a lot of delays for one of our cronjobs in github actions.

[CpuID]

I've got a ticket in now - I measured one workflow yesterday that has 20min spaced executions, it only fired 33% of the time 😢

[jacob-schwartz-kr]

Delays are ticking up to an average of 45 minutes for us, and we've seen them exceed an hour. This is insane.

[USBAkimbo]

Yep, I've been seeing delays of 45 mins up to 2 hours

I've had to work around it using k8s cron jobs that just curl the GitHub API and say "run the job now pls"

Insanity - core feature does not work

[cbeauchesne]

I'm seing consistently a two hours delay.

Nothing more to say about the increasing frustration of using github actions 😞

[EverStarck]

yup, fucking annoying

[PatBolkun]

Same, just over a two-hour delay today.

[lindsayevanslee]

Also experiencing delays, and they're getting worse. Here's some data from a job I've had running for a long time: the delay in actual job start time from the scheduled time has been steady for the entire history of the run, but things start getting wacky around February 2026. The dashed vertical line shows when I tried to adjust the schedule to avoid running the job at the top of the hour, but that hasn't made a difference.

Thanks for the tip to try cron-job.org. I'll be using that for the foreseeable future until Github can sort this out.

[JamesOBR]

We’re also experiencing delays, and they’ve become increasingly noticeable over the past few weeks.

[cbeauchesne]

Thanks a lot for this insightful data, @lindsayevanslee. The good news is that, regarding the exponential trend, either GitHub will fix it, or we'll all be forced to find an alternative to GitHub Actions cron jobs very soon... 😄

[evalue-simon-harrison]

...we'll all be forced to find an alternative to GitHub Actions cron jobs very soon... 😄

and then they'll say "oh, look, the load has gone down, we don't need to fix it any more!"

[nebuk89]

Hey y'all, sorry I missed you raising this.
We are aware that the drift on the start of our scheduled jobs has got worse; we will be working on this as we go through our current availability improvement work but (there is always a 'but' 😞 ) this isn't a fix 'now'. This drift is part of us balancing load coming in as scheduled drops have grown >30% in 2ish months. We need to get everything properly stable before we increase the throughput further from scheduled jobs.

Keep poking me here, I am here and reading/listening. We are working on this as part of the wider work <3

[jasonheffnerpsu]

I don't think anyone is arguing that point. The issue on hand at the moment is that delay in start is consistently outside of "the hour" and well over 2 hours on regular for heavier traffic start times. Additionally capacity should be really spun up to handle load when this happens.

[USBAkimbo]

@jasonheffnerpsu it's worse - this happens with self hosted runners too

Fair enough with hosted ones from GitHub - I only use them for jobs that just need to run at some point, not a specific point, so I don't care

But for my own runners? Why would they be delayed? If it's my own fault then fine but there's nothing I can do here to fix this

[jasonheffnerpsu]

@USBAkimbo Agreed, I noticed that as well, though I presume that some orchestration still has to manage the self-hosted runners which suggests that there isn't any prioritization for those jobs taking less compute.

[nebuk89]

Correct on the self-hosted part and this is to be totally honest 'how the system was designed when we created it ~5 years ago for Actions' and is part of what we are going to change as part of the work we are doing.

[nebuk89]

We are working on this, it won't magically 'make these instant' but we are now putting time into making this better.

Thank you for all the patience and continued engagement here. We will keep chipping away and doing this in a way we aren't putting our wider availability at risk as a result of making these changes.

[techlinn]

GitHub's own staff confirmed this is an infrastructure problem on their end. The scheduler backlog has grown over 30% in a short period and there's nothing you can configure to fix it. Moving to off peak hours takes the edge off but doesn't solve it because the delay is happening before your workflow enters any queue at all, not during runner pickup.

The workaround that actually holds up is to ditch the cron trigger and use an external service to fire workflow_dispatch instead. cron-job.org is free. Point it at: https://api.github.com/repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches

Headers:

Authorization: Bearer YOUR_PAT
Accept: application/vnd.github+json

Body:

{ "ref": "main" }

workflow_dispatch goes through a completely different queue than scheduled jobs. It doesn't touch the cron backlog at all and starts within seconds. A nicely grained PAT with Actions read/write is all you need for auth!

Hope this helps!

[wernichw]

github needs to fix this. what's the point in setting a cron schedule for actions if they aren't accurate? we have actions to run at 00:00 UTC and they four hours late. we moved from azure to github recently and it's not been a fun experience.

to me it seems no matter what cron schedule we use, it essentially translates to "sometime after that if you're lucky, but don't wait up"

[seanogdev]

Fully agree. At the very least there shouldn't be more proactive communication that there's degradation here.

[evalue-simon-harrison]

Finally gave up with this yesterday, after the /15 job went from 30 mins delay, to an hour, to 2.5 hrs. Now triggering the workflows via a cronjob from our local cluster - working perfectly.
It shouldn't be like this

[madhanravi17]

Facing similar issue a job which should trigger everyday at 00:00 UTC at 9:48am IST for the last few days. Hence will be moving to Apple Shortcut triggers which is precise.

[jdpinedaj]

Quick clarification on the self-hosted runner point above, since it came up twice: self-hosted runners won't fix this. The delay isn't the runner being slow to pick up the job, but it's upstream, in GitHub's own event dispatch. The schedule trigger sits in a queue that GitHub drains on a best-effort basis, and under load it slips or gets dropped entirely (that second part is the one that really hurts). Your runner only enters the picture after the job is queued, so there's no lost time for it to claw back.

If you need it to fire on time, stop treating schedule as your clock. Run the actual schedule somewhere you control, cloud scheduler, a k8s CronJob, even cron-job.org, and have it call the workflow_dispatch API at the exact minute. workflow_dispatch gets picked up near-instantly; it's specifically the schedule event that's deprioritized. Leave a schedule entry in as a lazy fallback if you like, just don't depend on it for anything time-sensitive.

[denolfe]

Getting bit by this lately. Here's the list of crons on hacker-news-highlights. This has been steadily degrading since February.

Scheduled for 10:30 UTC 🫠

Date	Queued (UTC)	Delay
2026-07-07	12:41	+131 min
2026-07-06	14:05	+216 min
2026-07-05	11:53	+83 min
2026-07-04	11:50	+81 min
2026-07-03	12:24	+114 min
2026-07-02	11:21	+51 min
2026-07-01	11:34	+64 min
2026-06-30	11:29	+59 min
2026-06-29	12:08	+98 min
2026-06-28	11:13	+43 min
2026-06-27	11:05	+35 min
2026-06-26	11:27	+58 min
2026-06-25	11:23	+53 min
2026-06-24	11:25	+56 min
2026-06-23	11:33	+64 min
2026-06-22	12:31	+122 min
2026-06-21	11:30	+61 min
2026-06-20	11:16	+47 min
2026-06-19	11:53	+83 min
2026-06-18	11:47	+77 min
2026-06-17	12:02	+92 min
2026-06-16	12:14	+105 min
2026-06-15	12:40	+130 min
2026-06-14	11:18	+49 min
2026-06-13	11:15	+46 min
2026-06-12	11:45	+75 min
2026-06-11	11:57	+87 min

[Nicodol]

Adding measurements, since this thread is mostly qualitative so far and numbers might help.

I keep a public repo whose only job is to watch how schedule: actually behaves. Last 7 days, on spec-compliant workflows:

A 30 6 * * * job ran all seven days and not once at 06:30. Start times: 09:09, 09:07, 09:03, 08:29, 08:56, 10:26, 09:17. Average 2h42 late, best day 1h59, worst 3h56. That lines up with the 06:30 UTC job someone reported starting at 11:04 CEST above.

A */5 * * * * job started 97 times out of ~2,016 slots over the same week, so about 5%. Effectively one run every ~104 minutes for a job asking for one every five, which matches the "our /15 job runs once an hour if that" report.

Caveat so nobody has to point it out: free plan, single repo with a lot of crons, so this is a worst case rather than a benchmark. Also worth noting that staggering away from :00 doesn't help much here, my daily is at :30 and my 5-minute job spreads across the hour by definition.

@nebuk89's answer is the useful one in this thread: the drift is upstream of the runner queue, so there's nothing to configure your way out of. What I'd add from the data is that the variance matters as much as the average. A predictable 30 minutes late is workable; 1h59 one day and 3h56 the next means you can't reason about "did it run yet" at all, which is why so many people here end up externalizing the trigger.

Longer write-up with the full table, if useful: https://dev.to/nicodol/my-0630-cron-has-never-once-started-at-0630-30me

Disclosure: measuring this annoyed me enough that I built a read-only GitHub App to watch for the runs that don't show up. Not the point of this comment and not linking it, happy to share if anyone wants it.

[jxu]

Originally posted here: https://github.com/orgs/community/discussions/196910#discussioncomment-17842538

I have an Action scheduled weekly at 13:37 UTC

These are these actual creation times:

2026-07-30T15:32:55Z
2026-07-23T15:32:49Z
2026-07-16T15:17:12Z
2026-07-09T16:12:07Z
2026-07-02T15:52:39Z
2026-06-25T16:03:09Z
2026-06-18T16:44:49Z
2026-06-11T17:06:23Z
2026-06-04T16:32:06Z
2026-05-28T17:06:33Z
2026-05-21T16:24:08Z
2026-05-14T15:41:06Z
2026-05-07T15:51:22Z
2026-04-30T15:27:20Z
2026-04-23T15:25:45Z
2026-04-16T15:11:39Z
2026-04-09T15:06:17Z
2026-04-02T14:39:24Z
2026-03-26T14:48:06Z
2026-03-19T14:29:28Z
2026-03-12T14:27:53Z
2026-03-05T14:24:32Z
2026-02-26T14:31:05Z
2026-02-19T14:31:05Z
2026-02-12T14:32:22Z
2026-02-05T14:26:39Z
2026-01-29T14:10:22Z
2026-01-22T14:01:48Z
2026-01-15T13:57:37Z
2026-01-08T13:57:34Z
2026-01-01T13:51:12Z
2025-12-25T13:49:09Z
2025-12-18T13:55:28Z
2025-12-11T13:56:11Z
2025-12-04T13:54:31Z
2025-11-27T13:49:35Z
2025-11-20T13:46:37Z
2025-11-13T13:50:39Z
2025-11-06T13:49:03Z
2025-10-30T13:48:30Z
2025-10-23T13:48:56Z
2025-10-16T13:48:21Z
2025-10-09T13:47:14Z
2025-10-02T13:42:57Z
2025-09-25T13:45:47Z
2025-09-18T13:43:46Z
2025-09-11T13:40:54Z
2025-09-04T13:43:09Z
2025-08-28T13:45:20Z
2025-08-21T13:47:36Z
2025-08-14T13:53:20Z
2025-08-07T13:58:17Z
2025-07-31T13:57:09Z
2025-07-24T13:56:09Z
2025-07-17T13:54:39Z
2025-07-10T13:53:06Z
2025-07-03T13:49:27Z
2025-06-26T13:50:25Z
2025-06-19T13:48:52Z

Last year it was roughly on time, but the delay is getting worse!

Today it straight up failed to run.