Actions scheduled workflow runs are starting hours away from the configured cron times

[crystal6216]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

🤔 GitHub Actions scheduled runs starting hours later than expected

Hi everyone! 👋
I'm having a strange issue with a GitHub Actions scheduled workflow, and I'd appreciate any suggestions.

⚙️ Setup
Schedule: 0 2,6,10 * * * (UTC)
Expected runs: 02:00, 06:00, and 10:00 UTC daily
Default branch: main
Manual runs using workflow_dispatch work normally.
🐛 Problem
Since October 1, 2026, scheduled runs have frequently started hours away from the expected times. Some expected runs also appear to be missing.

For example, one scheduled run started at 08:37 UTC, even though the configured cron only specifies 02:00, 06:00, and 10:00 UTC.
I added a diagnostic step and confirmed that this run reported:

Event: schedule
Scheduled cron: 0 2,6,10 * * *
Workflow ref: the expected workflow on main
The workflow schedule has not been intentionally changed. Manual runs still work.

I also encountered HTTP 403 responses from the target website on some runs, but I suspect this is a separate issue from the scheduling behavior.

❓ Questions
Has anyone experienced scheduled runs starting several hours away from their configured cron times?
Is there a way to determine which scheduled slot triggered a run?
Are there additional checks I should perform to investigate missing or delayed scheduled runs?
I understand that GitHub Actions schedules are not guaranteed to start exactly on time, but the repeated multi-hour deviations are unusual.

Thanks in advance for any help! 🙏

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

[91fazlulkarim91-dotcom]

A useful first step is to log the scheduled event's expected cron time and compare it with the actual workflow start time.

For scheduled workflows, GitHub Actions does not guarantee execution at the exact cron time, and runs can be delayed or even dropped during periods of high load. However, repeated multi-hour delays are worth investigating.

A few checks that may help:

1. Check the workflow run history and compare scheduled start times with the configured UTC cron schedule.
2. Verify that the workflow file containing the schedule trigger exists on the default branch (main).
3. Check the GitHub Actions status page for incidents affecting scheduled workflows.
4. Review workflow concurrency settings, job queues, and runner availability to see whether the delay occurs before the workflow starts or after it is queued.
5. Check whether the repository has been inactive or whether any repository or organization settings changed.

One important limitation: the schedule event does not provide a dedicated field identifying which cron occurrence triggered a run. The github.event.schedule context contains the matching cron expression, but when multiple scheduled times use the same expression, it cannot distinguish the individual occurrence.

For better diagnostics, record the workflow's event timestamp, run ID, run number, and actual start time. You can then compare these with the expected schedule. The HTTP 403 responses should also be investigated separately, since they may indicate rate limiting, authentication, or access restrictions at the target website.

If the multi-hour delays continue, collecting several run IDs and timestamps would help when reporting the issue to GitHub Support.

[91fazlulkarim91-dotcom]

The behavior you are experiencing is actually a well-known, documented characteristic of GitHub Actions scheduled workflows.
Here are the answers to your questions and a breakdown of why this is happening.

1. Why are runs starting hours late or missing?

GitHub Actions does not guarantee that scheduled workflows will run exactly at the configured cron time.
During periods of high load on GitHub's infrastructure, scheduled jobs are routinely delayed, sometimes by several hours.
• The "Top of the Hour" Spike: Your cron job is set to 0 minutes (0 2,6,10 * * *). The top of the hour—especially midnight, 02:00, and early UTC hours—is when thousands of developers schedule their workflows. This creates massive resource queues, causing severe delays.
• Dropped/Missing Runs: If your workflow is delayed so long that the next scheduled run time arrives before the previous one has even started, GitHub will often drop or skip the earlier run entirely to prevent a backlog.

2. Can you determine which slot triggered a run?

Unfortunately, GitHub does not natively provide a payload property that indicates the exact target slot (e.g., "this was the 02:00 run"). The github.event.schedule context only gives you the exact cron string you configured, not the specific timestamp it was intended for.
If you absolutely need to know, you have to write custom logic in your workflow script to inspect the current time (using a script step) and round it down to the nearest expected slot (02:00, 06:00, or 10:00) to deduce which one it likely was.

3. How to fix or investigate this further

To minimize these delays and figure out what is happening, try these steps:
• Shift to an Unusual Minute: The easiest fix is to avoid the top of the hour. Change your cron from 0 to a random minute, like 17 or 42. For example: 17 2,6,10 * * *. This moves your job out of the peak queue.
• Check GitHub Status: When multi-hour delays happen consistently, check the official GitHub Status page. They often log incidents regarding "Actions delays" or "Workflow queuing."
• Separate the HTTP 403 Issue: You mentioned HTTP 403 errors. If your target website expects data at an exact time, a run executing 6 hours late might be rejected by the server due to stale tokens, or the target site might be rate-limiting the GitHub Actions IP ranges if multiple delayed jobs hit it at once.
If your workflow requires strict, time-sensitive execution, GitHub Actions schedules are not the best tool. You might want to trigger the workflow externally using a reliable third-party cron service (like Cron-Job.org or an AWS CloudWatch Event) that hits the GitHub API repository_dispatch webhook to start your workflow on demand.
To help narrow down the best solution, let me know:
• How time-sensitive is the data this workflow handles?
• Can the target website handle shifted execution times (e.g., running at 02:23 instead of 02:00)?

[wallace-computing]

On your second question: there is a way to tie each run to its slot. Give each slot its own cron line:

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

github.event.schedule holds the cron string that fired, so with one line per slot it names the slot directly:

- run: echo "slot=${{ github.event.schedule }} started=$(date -u +%FT%TZ)"

Your 08:37 run would then show whether it was the 06:00 slot 2h37m late or the 02:00 slot 6h37m late; schedule runs aren't created before their slot, so it can't be the 10:00 one. Over a few days that gives you a delay per slot, and the slots that never appear are the dropped ones: the table GitHub Support will want if you open a ticket.

Two notes:

• Editing the schedule block re-registers it, so give it a slot or two before reading the results.
• Multi-hour delays have been reported widely since early October (in Scheduled workflows create no runs across repositories while push and manual dispatch succeed #209838 the runs did arrive, 5h47m to 6h19m after their cron times), so this is probably not specific to your repo. If the job's output depends on when it runs, have it check the current time and decide (skip, or run and note the lateness) instead of assuming it ran on schedule. For strict timing, an external scheduler calling workflow_dispatch is the reliable route, with schedule kept as a fallback.