Repository navigation
Auto Start CI delayed running 2 - 3 hours instead of every 5 minutes #4443
Description
Activity
This should possibly be raised to GitHub Support.
There is no
workflow_dispatchevent trigger in the workflow, so no means to start it manually.MikeMcC399 commented
on Aug 27, 2026 on Aug 27, 2026 · Hidden as outdatedAuthorshow commentMore actionsIt's still having a long pause between runs: 2 - 3 hours gap:
Ago Timestamp 37 minutes ago 2026-08-28T07:27:36Z 3 hours ago 2026-08-28T04:53:09Z 6 hours ago 2026-08-28T02:02:17Z 8 hours ago 2026-08-27T23:17:34Z 11 hours ago 2026-08-27T20:06:23Z 15 hours ago 2026-08-27T16:39:46Z 19 hours ago 2026-08-27T12:53:18Z 22 hours ago 2026-08-27T09:18:41Z 1 day ago 2026-08-27T06:08:17Z 1 day ago 2026-08-27T03:56:58Z 1 day ago 2026-08-27T02:02:58Z 1 day ago 2026-08-27T00:20:11Z 1 day ago 2026-08-26T23:08:20Z 1 day ago 2026-08-26T22:01:17Z 1 day ago 2026-08-26T20:57:46Z 1 day ago 2026-08-26T20:05:20Z 1 day ago 2026-08-26T19:24:51Z 1 day ago 2026-08-26T18:43:42Z 1 day ago 2026-08-26T18:00:43Z 1 day ago 2026-08-26T16:58:54Z I opened nodejs/node#65612
If it doesn't help, I don't think we can do much more with GitHub actions. Another approach could be to have the schedule in Jenkins and trigger workflow runs using the API.
Reacted by Stewart X Addison- added a commit that references this issue
on Aug 28, 2026 I guess it's worth a try to skew the start, however since it was working reasonably before, and it has stopped doing what is expected of it, it may need a support ticket to GitHub opened.
GitHub is generally coming under increased load due to the proliferation of AI-based submissions.
In April, monthly commits were at 1.4 billion. GitHub says it now handles 2.9 billion commits, 24 million new repositories, and 130 million merged pull requests each month.
- added a commit that references this issue
on Aug 28, 2026 https://github.com/nodejs/node/blob/main/.github/workflows/auto-start-ci.yml is now showing a skewed start of 3 minutes:
on: schedule: # Runs every five minutes (fastest the scheduler can run). Five minutes is # optimistic, it can take longer to run. # To understand why `schedule` is used instead of other events, refer to # ./doc/contributing/commit-queue.md - cron: 3/5 * * * *
This hasn't produced any change and the workflow is still showing a last run of almost 3 hours ago.
I would suggest opening a ticket on https://support.github.com/ (https://support.github.com/contact-next)
I seem to recall mention of an overuse of our monthly github actions allocation from the 20th August and I'm wondering if that may have caused us to be restricted. Ping @nodejs/tsc since I believe this may have been discussed by you somewhere...
It does look like a deliberate throttling.
I seem to recall mention of an overuse of our monthly github actions allocation from the 20th August and I'm wondering if that may have caused us to be restricted. Ping @nodejs/tsc since I believe this may have been discussed by you somewhere...
That's for private repo action use.
Reacted by Stewart X AddisonI would suggest anyway to reduce the requested cron frequency to once every 15 minutes, instead of every 5 minutes. When the Jenkins runs are taking several hours, there is little advantage to checking every 5 minutes, even if GitHub Actions were running it that frequently.
- pinned this issue
on Aug 28, 2026 https://github.com/nodejs/corepack/actions/workflows/sync.yml (weekly cron) was scheduled to run at 00:05 UTC this morning, it ended up running at 3:20 UTC. I doubt that changing the requested frequency would have much effect
I didn't mean change the frequency to solve the issue and I still think this needs escalation to GitHub Support.
Reacted by Antoine du HamelLooks like it's not just us: https://github.com/orgs/community/discussions/205984
In the interests of reducing the backlog and using up some "quiet time" for the machines over the weekend I'm manually starting a few of the tests. They'll get throttled to avoid overwhelming the system due to reducing node-test-commit to only being able to run 10 in parallel. Surprisingly there aren't that many with the
request-cilabel (14 at the moment) I'll also note that I've seen some PRs where the result has not been propagated back once the job is complete which could be indicative of a greater problem somewhere. Adding in the PR links so the originators get this issue link to know that these have been manually triggered. I did see that some of these had the label added 2-3 weeks ago and weren't triggered. May have been some other issue at that time. I've left the "Commits" column to be able to track issues such as status not being reported back if they occur.PR PR test job Comments 65609 76636 65406 76637 65352 76638 65278 76639 65064 76640 64618 76641 64528 76642 64125 76643 59950 76644 65553 76645 65490 76646 Reacted by Mike McCreadyI did see that some of these had the label added 2-3 weeks ago and weren't triggered.
Then they didn't have approvals for the latest commit. That they don't run or get scheduled is expected.
Reacted by Mike McCready, Antoine du Hamel and Stewart X AddisonMay have been some other issue at that time
One of the upside of using a cron is that is not possible: if GHA is down is disabled (or down) at some point, once it's up again it simply picks up those old jobs.
Reacted by Stewart X Addison and Mike McCreadyI'll close this issue, since the frequency of the Auto Start CI cron job is now around 10 - 15 minutes.
I suspect that GitHub was deliberately throttling these jobs and has now removed the throttle.
- added a commit that references this issue
on Aug 29, 2026 - unpinned this issue
on Sep 1, 2026 - added a commit that references this issue
on Sep 3, 2026 - added a commit that references this issue
on Sep 9, 2026 - added 2 commits that reference this issue
on Sep 9, 2026



Situation
The workflow node/actions/workflows/auto-start-ci.yml is set up with:
to run every 5 minutes. On Aug 27, 2026 it is running instead every 2 - 3 hours.
There was a GitHub Incident for Actions & Pull Requests that was supposed to be resolved on Aug 27, 2026 00:6 UTC.
This is preventing timely response to
request-cilabels.For example,
request-ciwas applied to nodejs/node#65492 at 2026-08-27T11:03Z and 2 hours later, the PR is still waiting for the request to be fulfilled.https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule says:
A delay of 2 - 3 hours over an extended period of time is outside of what could be expected.