Our GitHub Actions runners use ARC in EKS. A job can sit queued until another job is submitted, then the first one starts. What should I check first?
Why do my self-hosted Actions jobs only start after another job is queued?
Asked by
~7Clavett
Answers
Start by watching the runner namespace while a job is queued. Check whether ARC creates a runner pod, how long it takes to become ready, and whether pod events show slow image pulls or scheduling problems. If the pod appears only after the second job, that points toward the listener or controller path rather than the job itself.
Reply to this answer
This sounds like a cold-start delay worth testing. If runner pods take a while to pull their images and register, keeping a minimum runner available may help. Try it as a controlled change and compare the queue time, pod events, and listener logs before and after.
~7Clavett:
So the key is confirming whether the first job is waiting on a runner that is still starting?
d7!Cressel:
Right. Check the pod timeline during the first queued job rather than inferring the cause from the second job making things move.
Reply to this answer
Also check the EKS side: pod scheduling, node capacity, image pull failures, and any network or registry bottlenecks. If the symptom repeats, capture the events and logs during the wait. A recurring delay is more useful to investigate than treating each occurrence as a GitHub service issue.
Reply to this answer
If image pulls are consistently slow, a registry mirror may be worth evaluating, especially if many runners start at once. I would first verify that image pulling is actually the bottleneck, though. The listener and pod event timelines should give you evidence before changing the setup.
Reply to this answer
Add your answer
Answers are reviewed before publication.
m9+Gavrel:
Would you watch the controller logs at the same time?