Scheduled workflows silently not firing, and firing hours late, in a private repository — while workflow_dispatch starts in the same minute (209/209)

[reverete]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Repository: reverete/mfpar360 (private, personal account on the Free plan; renamed on Aug 26, 2026). Support tickets are not available on this plan, so I am bringing the measurements here.

Since Aug 19, 2026 we have two distinct symptoms with schedule events, while workflow_dispatch on the same workflows and the same branch behaves perfectly.

Symptom 1 — events not delivered at all. Four incidents:

• Aug 19: the 05:45 UTC daily run did not fire.
• Aug 22 (Sat): no scheduled event fired the entire day, across all workflows.
• Aug 27: no scheduled event fired between Aug 26 ~18:30 UTC and Aug 27 midday (slots at 05:45, 08:23, 08:33 and 09:05-10:05 UTC all skipped); the 16:07 UTC cron then fired normally.
• Aug 28: again nothing between 05:45 and at least 10:05 UTC (same slots); a manual dispatch at ~11:20 UTC ran fine and published at 13:09 UTC.

Symptom 2 — systematic delay of hours, not minutes. Measured per run through the Actions API (run.created_at minus the cron time), over the runs available in early September:

workflow	scheduled runs	median delay	worst
afternoon notification	28	4h32	8h11
morning notification	57	18 min	11h05
main data refresh	26	37 min	8h41
second-attempt refresh	29	47 min	19h02

For the afternoon workflow, 26 of the 28 scheduled runs were delivered more than one hour late, and none within 5 minutes of the cron time. Our delivery window for that job is 30 minutes, so a 4h32 median makes the schedule unusable: we had six different cron times for it and all six landed outside the window on Sep 1.

The contrast that seems relevant for diagnosis. In the same period, workflow_dispatch on the same workflows and branch started in the same minute in 209 of 209 runs we measured. Same repository, same branch, same workflow files — only the schedule event is late or missing.

What we already ruled out on our side:

• Not chronic slot congestion: from Aug 16 to Aug 26 the 05:45 UTC cron fired nine days in a row with the usual 16-40 minute delay.
• Not the "minute zero" pile-up: all our crons use non-zero minutes (45 5 * * *, 7 16 * * *, etc.).
• Not the 60-day inactivity rule: the repository is private and has commits every day.
• Not our workflow logic: when the event is delivered, the run behaves normally, and manual dispatches of the very same workflows always run.

Where we are now. We have moved our scheduling to an external trigger that calls workflow_dispatch through the REST API, so this is no longer an outage for us — the cron entries are now a third layer that arrives hours late and is discarded by a guard step.

The questions:

1. Is a median delay of several hours (and occasional non-delivery) expected behaviour for schedule in a private repository on the Free plan, beyond the documented "may be delayed during periods of high load"?
2. Is schedule delivery de-prioritised or throttled per repository or per plan in a way that workflow_dispatch is not? The 209/209 contrast suggests the runner capacity is fine and the difference is in event delivery.
3. Is there any way to see, from the repository side, that a schedule event was dropped (as opposed to delayed)? Today the only evidence is the absence of a run.

Thanks for any insight — even "this is by design, use an external trigger" is a useful answer, because it is what we ended up doing.

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