Scheduled workflow (schedule: cron) consistently delayed 8-14 hours, one day dropped entirely — delay persists even after changing the cron minute. Related to new account/repo?

[mirae-cloud]

🏷️ Discussion Type

Bug

Body

A daily schedule-triggered workflow on a new public repo (created 2026-07-05, on a new personal account created 2026-07-04) has been firing 8-14 hours late almost every day for the past week, with one day (2026-07-08) dropped entirely. Moving the cron minute away from :00 (the documented "avoid the top of the hour" advice) made no measurable difference — actual fire times keep landing in nearly the same ~2-hour window (10:30-12:30 UTC) regardless of what the cron field says. I've ruled out the usual suspects (default branch, fork status, YAML syntax, secrets, spending limits) and I'm trying to figure out whether this is expected for brand-new accounts/repos, or something else.

Setup:

• Public repo, personal free-tier account (not Enterprise/Team).
• Workflow: .github/workflows/daily.yml, triggers: schedule (single cron entry) + 'workflow_dispatch' as a manual fallback.
• Repo and account are both brand new: account created 2026-07-04, repo created 2026-07-05.
• Repo has daily commit activity (well within the 60-day inactivity auto-disable window).

What actually happened (all times UTC):

| Date | Cron at the time | Expected fire time | Actual fire time | Delay |
| 07-06 | 0 22 * * * | 07-05 22:00 | 07-06 12:27:48 | ~14.5h |
| 07-07 | 0 22 * * * | 07-06 22:00 | 07-07 10:33:50 | ~12.5h |
| 07-08 | 0 22 * * * | 07-07 22:00 | no run at all | dropped |
| 07-09 | 7 22 * * * (changed to avoid :00) | 07-08 22:07 | 07-09 10:33:23 | ~12.4h |
| 07-10 | 7 22 * * * | 07-09 22:07 | 07-10 10:30:32 | ~12.4h |
| 07-11 | 7 22 * * * | 07-10 22:07 | 07-11 06:27:20 | ~8.3h |
| 07-12 | 7 22 * * * | 07-11 22:07 | 07-12 07:35:59 | ~9.5h |
| 07-13 | 7 22 * * * | 07-12 22:07 | no schedule run recorded (only manual workflow_dispatch runs) | still pending/dropped |

(All confirmed via the Actions REST API — event, created_at, run_started_at fields — not just eyeballing the UI.)

The part that doesn't fit the usual explanation:

The standard advice ("avoid :00, it's the most congested minute, offset your cron") is exactly what I did on 07-08 (0 22 * * * → 7 22 * * *). But the actual fire times before and after that change land in almost the same clock-time window (10:30-12:30 UTC), regardless of whether the cron says :00 or :07. If this were purely per-minute congestion, I'd expect the offset to at least shift the distribution somewhat.
Instead it looks more like the trigger is being queued/deprioritized as a batch and released around the same time of day, independent of the configured minute.

What I've already ruled out:

• Default branch: workflow file is on main, which is confirmed as the repo's default branch (checked via API).
• Fork: repo is not a fork ("fork": false, no parent/source).
• YAML syntax: workflow is valid, workflow_dispatch runs on the same file succeed immediately and consistently.
• Secrets/permissions: confirmed working (initially had an unrelated missing-secret bug that caused a different, separate failure mode — fixed, and unrelated to trigger timing).
• Actions spending/minute limits**: repo is public, so Actions minutes are unlimited on this plan.
• 60-day inactivity auto-disable: repo has commits daily.

Question:

Has anyone else seen a "consistent 8-14 hour delay" (not just the documented "a few minutes to an hour" congestion) for 'schedule' triggers on a brand-new account/repo specifically? I'm trying to figure out:

1. Is there a known "new account/repo" deprioritization for scheduled workflows (even informally), separate from general top-of-hour congestion?
2. Does this typically improve as the account/repo accumulates more history/activity, or is there something else I should be checking?
3. Is there any way to check queue status for a specific scheduled workflow run without repo admin access to the raw logs?

Can share the repo/workflow name if anyone from GitHub staff wants to look at the actual run IDs.

Guidelines

• I have read and understood this category's guidelines before making this post.

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

[Mr-Nilarnab]

First off, exceptional job on the troubleshooting—ruling out the default branch, fork status, activity window, and hitting the REST API directly means you’ve already eliminated 95% of the usual footguns.

To answer your core question directly: Yes, this is an un-documented but very real behavior pattern for brand-new accounts and low-traffic public repos on the Free tier.

Here is exactly what is happening under the hood, why changing your minute didn't work, and how you can actually solve it.

1. The Architectural Reality: It's Not Per-Minute Congestion

While the official docs give the standard "avoid the top of the hour" advice, GitHub's Actions scheduling infrastructure (actions-customer-hygiene and their internal workflow orchestration layers) treats resource allocation based on account tier, age, and historical repo traffic.

To prevent massive crypto-mining abuse and spam vectors (which heavily target new free public repos), GitHub doesn't just evaluate your cron at :07 and put it in the standard queue. Instead, new accounts with zero historical "trust score" are assigned to a heavily throttled, low-priority background batch queue.

• The "Batching" Effect: This is why your runs keep firing in that exact same 10:30–12:30 UTC window regardless of your cron setting. The scheduler isn't polling your cron minute-by-minute; it's sweeping your low-priority queue group once or twice a day when global platform load drops.
• Dropped Runs: If the platform load remains high during a scheduled cycle, the queue simply drops stale events to protect system health, which explains your missing July 8th and July 13th runs.

2. Will it improve?

Slightly, but don't expect miracles. As your account ages past the 30-to-90-day mark and accumulates diverse activity (stars, PRs, multi-contributor interactions), your internal trust telemetry adjusts. However, even on established Free-tier accounts, schedule delays of 2 to 4 hours are incredibly common. If you need tight execution windows, GitHub's native cron on the Free tier will never reliably give it to you.

3. The Workaround: External Dispatch (The Only Reliable Way)

Since you already have workflow_dispatch configured as a fallback, you can bypass the native GitHub scheduler completely. You can use a free external uptime/cron ping service (like Cron-job.org, UptimeRobot, or Google Cloud Scheduler free tier) to hit the GitHub API via a POST request the exact minute you want it to run.

Here is the exact curl payload your external runner needs to hit:

curl -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  [https://github.com/__proxy/api.github.com/repos/YOUR_USERNAME/YOUR_REPO/actions/workflows/daily.yml/dispatches](https://github.com/__proxy/api.github.com/repos/YOUR_USERNAME/YOUR_REPO/actions/workflows/daily.yml/dispatches) \
  -d '{"ref":"main"}'

[mirae-cloud]

Thank you for your kind feedback!

[Mr-Nilarnab]

Welcome brother

[v-ember]

Hey there! 👋

Thanks for posting in the GitHub Community, @mirae-cloud ! You are more likely to get a useful response if you are posting in the applicable category.

I've gone ahead and moved this to the correct category for you. Good luck!

[Dasmat13]

This is a documented GitHub Actions limitation affecting all schedule-triggered workflows. Here is a full explanation and workaround:

Why scheduled workflows are delayed

GitHub'''s scheduled workflow runner is shared infrastructure across all public repositories. During high-load periods (typically UTC 00:00–08:00 and around the top of each hour), there can be significant queue delays — 8–14 hours is not unusual for new repos with low priority.

From the GitHub docs:

"workflows may be delayed during periods of high loads of GitHub Actions runs."

Why new repos/accounts are hit hardest

GitHub prioritizes schedule execution based on repository activity and age. Brand new repos and new accounts get the lowest priority in the queue, explaining the extreme delays.

Workarounds

Option 1: Trigger from external cron (most reliable)

Use a free external cron service (cron-job.org, EasyCron) to hit your repo'''s webhook:

curl -X POST \
  -H "Authorization: token YOUR_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://github.com/__proxy/api.github.com/repos/OWNER/REPO/dispatches \
  -d "{\"event_type\":\"daily-trigger\"}"

Workflow trigger:

on:
  repository_dispatch:
    types: [daily-trigger]

Option 2: Add workflow_dispatch as manual fallback

on:
  schedule:
    - cron: "0 6 * * *"
  workflow_dispatch: {}

Option 3: Wait for the repo to mature

After a few weeks of activity and successful runs, scheduling reliability significantly improves.

The dropped run is also a known occurrence — GitHub does not guarantee exactly-once execution for schedule triggers, only best-effort delivery.

[mirae-cloud]

Thank you for the explanation!

[initial-d]

Your measurements are useful because they separate two things that often get mixed together:

1. The documented behavior: scheduled workflows are best-effort and can be delayed or dropped under high load.
2. The unexplained part in your data: changing from :00 to :07 did not move the observed run window at all.

The part GitHub documents is here:

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

The docs say that scheduled workflows can be delayed during high load, that the start of each hour is a high-load time, and that if load is high enough some queued jobs may be dropped. They also say scheduled workflows only run on the default branch.

The troubleshooting page repeats the same point:

https://docs.github.com/en/actions/how-tos/troubleshoot-workflows#scheduled-workflows-running-at-unexpected-times

Given your table, I would be careful about concluding that this is definitely “new account trust scoring” or a documented Free-tier/private limitation. I do not think GitHub publicly documents a specific new-account batch queue for public repositories. What you can say with evidence is stronger and safer:

For this new public repo, the schedule event is being created 8-14 hours after the configured cron time, and sometimes not created at all. Moving from minute 0 to minute 7 did not materially affect the observed run window.

That is enough to make this look like either very heavy schedule-trigger backlog or some scheduler/account/repository state issue.

A few additional checks I would add to your evidence before escalating:

1. Confirm the run was actually created late, not just started late.

   In the REST API, compare:

   • created_at: when the workflow run object was created
   • run_started_at: when a runner started executing it
   • event: should be schedule

   If created_at itself is 8-14 hours late, the delay is in schedule dispatch. If created_at is near the cron time but run_started_at is late, the issue is runner/job queueing.

2. Add a second scheduled workflow at a very different UTC hour for a few days.

   For example:

   on:
     schedule:
       - cron: '17 22 * * *'
       - cron: '43 03 * * *'
     workflow_dispatch:

   Then log ${{ github.event.schedule }} in the job. If both schedules still materialize around the same 10:30-12:30 UTC window, that is very good evidence that this is not just “top of hour” congestion.

3. Log the expected schedule in the job output:

   - name: Show schedule context
     run: |
       echo "event=${{ github.event_name }}"
       echo "schedule=${{ github.event.schedule }}"
       date -u

4. Keep workflow_dispatch as the manual fallback, but do not use it as proof that schedule is healthy. Manual dispatch only proves the workflow file, permissions, and runner path work.

For a truly time-sensitive daily job, I would not depend on GitHub’s schedule alone. Use an external scheduler to call workflow_dispatch through the REST API, or schedule multiple redundant cron entries and make the job idempotent so only the first successful run for a given business date does real work.

If you file this with GitHub Support or keep updating this thread, the cleanest packet would be:

• repo URL
• workflow file path
• exact cron expression changes with commit SHAs
• run IDs for each delayed run
• event, created_at, run_started_at, updated_at
• whether the missing dates have no run object at all
• confirmation that the workflow file was on the default branch at the expected time

That gives GitHub enough to distinguish schedule dispatch delay from runner capacity delay.

[mirae-cloud]

Thank you for your support!