GitHub Actions scheduled workflow delayed by 4 hours 23 minutes

[a0911724285-afk]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

GitHub Actions scheduled workflow delayed by 4 hours 23 minutes

I'm reporting a significant delay in a GitHub Actions scheduled workflow.

Expected behavior

The workflow is configured to run daily at 00:10 UTC (08:10 Beijing time).

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

Actual behavior

On October 19, 2026, the scheduled workflow started more than four hours late.

• Expected trigger: 2026-10-19 00:10:00 UTC
• Actual run creation: 2026-10-19 04:32:47 UTC
• Delay: 4 hours, 22 minutes, 47 seconds
• Trigger event: schedule
• Run conclusion: success
• Workflow completed: approximately 04:38:43 UTC

The runner began executing within seconds of run creation, and the workflow completed successfully.

This indicates that the delay occurred before the workflow began executing, rather than during the actual job execution.

Impact

This workflow generates a daily automated research report that must be ready before 09:00 Beijing time. The scheduling delay caused the morning delivery to fail even though the workflow itself was functioning correctly.

The repository is private. I can provide the run URL and additional logs to GitHub Support through a private channel if needed.

Questions

1. Was there a known issue or scheduler backlog affecting GitHub Actions scheduled workflows on October 19, 2026?
2. Why was this scheduled run created more than four hours after its configured time?
3. Is GitHub investigating similar multi-hour scheduling delays?
4. Is there a recommended mitigation for time-sensitive scheduled workflows?

I understand that scheduled workflows are not guaranteed to execute at an exact time, but a delay exceeding four hours makes this automation unreliable.

Thank you for investigating.

[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. ⭐

[omeraydin00]

This isn't something wrong with your repo. GitHub's docs say the schedule event can be delayed when Actions is under high load, and that the start of every hour is a high-load time. If the load is high enough, some queued runs can even be dropped. Midnight UTC is one of the busiest moments of the day because so many workflows are scheduled for it, so 10 0 * * * sits right in the worst window. There's no guarantee on when a scheduled run actually starts.

If the report has to be ready at a fixed time, a few things help:

1. Move the cron off the busy times. Something like 37 22 * * * (06:37 Beijing) instead of 00:10 UTC. It usually cuts the delay a lot, but it's still best-effort.

2. Run it twice and skip if done. Schedule it at e.g. 22:37 and 23:37 UTC, and have the job exit early if today's report already exists. A late first run then doesn't matter.

3. If the time really matters, trigger it from outside. Add workflow_dispatch to the workflow and call the API from an external scheduler (Cloud Scheduler, a cron on a small server, cron-job.org…):

   curl -X POST \
     -H "Authorization: Bearer $TOKEN" \
     -H "Accept: application/vnd.github+json" \
     https://api.github.com/repos/OWNER/REPO/actions/workflows/report.yml/dispatches \
     -d '{"ref":"main"}'

   A fine-grained token with Actions: Read and write on that repo is enough. Dispatched runs start within seconds, the same as when you run it by hand.

For your first question, the incident history on https://www.githubstatus.com shows whether Actions had a known problem that day.

If this solves it, could you mark it as the answer? 🙂

[dfbustosus]

What @omeraydin00 described is the root cause — documented load-shedding behavior, not anything in your repo. Two practical notes for your specific constraint (report ready by 09:00 Beijing time):

1. Move off the peak. The docs call out that the start of every hour is the highest-load window, and midnight UTC is the single busiest moment of the day because so many workflows target it — 10 0 * * * sits in the worst possible slot, with only ~50 minutes of slack before your deadline. Your deadline is 01:00 UTC; schedule the run hours earlier at an off-peak minute (e.g. 37 19 * * * = 03:37 Beijing) so a multi-hour delay still lands inside your window. Delay scales with how busy the window is, so this change alone usually eliminates the failure mode.

2. If the deadline is hard, don't use schedule as the trigger. Dispatch from an external cron instead — Cloudflare Workers Cron Trigger, EventBridge, or cron-job.org calling workflow_dispatch via the REST API with a PAT:

curl -X POST -H "Authorization: Bearer $PAT" \
  "https://api.github.com/repos/<owner>/<repo>/actions/workflows/report.yml/dispatches" \
  -d '{"ref":"main"}'

Dispatch runs aren't subject to the scheduled-event queue, a failed trigger becomes a visible HTTP error you can alert on (instead of silent delay), and you can retry immediately from the scheduler.

3. Optional guard: a tiny watchdog on a different schedule that checks whether today's report run exists (gh run list --workflow report.yml --created $(date -u +%F)), and dispatches it if missing — catches both delayed and dropped runs.

For a daily 09:00 deliverable, #2 is the setup I'd ship; #1 is the zero-effort version that fixes most of it.

[ndw1029-prog]

I saw a similar problem on October 20, 2026, across two scheduled workflows in a private repository. Adding timing evidence here rather than opening a duplicate discussion.

All times below are KST (UTC+9), on October 20:

• Scheduled 07:55 → run created 10:18:31 → first job started 10:50:31. Creation was 2h 23m 31s late. A separate manual run explains the additional 32-minute concurrency wait after creation.
• Scheduled 12:00 → run created 16:57:17 → first job started 16:57:20. Creation was 4h 57m 17s late.
• Scheduled 17:32 → run created 22:48:15 → first job started 22:48:17. Creation was 5h 16m 15s late.

For UTC correlation, the scheduled times were October 19 at 22:55, October 20 at 03:00, and October 20 at 08:32, respectively.

A manual run of the same workflow as the morning/evening schedules was created at 18:40:25 KST and its first job started at 18:40:29. That job completed successfully at 19:22:01, well before the evening scheduled run was created.

The morning/evening event values matched the configured schedules, so this was not a comparison against old cron settings. Those two slots were already away from the start of the hour. The noon workflow uses a different concurrency group and had not changed since October 9.

The large delay is before run creation, but I cannot establish the internal cause from these timestamps. Is there a confirmed scheduling issue covering these UTC windows, and a supported mitigation for multi-hour delays? Is there evidence that disabling/re-enabling or re-registering a schedule addresses this specific symptom, rather than just changing its enabled state?

I have omitted private repository identifiers, code and raw logs.