A 43-minute CI queue does not show that Jenkins or GitHub Actions is inherently slower. It shows that one job waited somewhere in a particular setup. To find the cause, separate time waiting for an available worker from time spent executing the job, then check worker capacity, workflow rules, and plan limits.
What a 43-minute CI queue can—and cannot—tell you
The reported wait is an incident to diagnose, not a benchmark. The available product documentation does not establish why this job waited, how common a 43-minute delay is, or which platform would run a particular workload faster. It also provides no attributable average queue time for either service.
As an Amazon Associate I earn from qualifying purchases.
First identify what “waiting” means in your workflow. A job may be waiting for an agent or runner, held by a concurrency rule, paused for an environment approval, or delayed elsewhere. Record timestamps for the trigger, queue entry, worker assignment, execution start, and completion. That timeline distinguishes scheduling delay from execution time.
How Jenkins and GitHub Actions assign work
| Area | Jenkins | GitHub Actions |
|---|---|---|
| Where work runs | Agents run jobs using executors. The number of executors determines how many tasks can run concurrently on an agent. | Jobs run on GitHub-hosted or self-hosted runners. |
| What can cause a wait | Agents may be offline, occupied, unavailable to the job, or constrained by controller resources. | Hosted concurrency can be reached; a self-hosted job waits if no online, idle runner matches its labels and groups. Workflow concurrency rules can also hold or replace pending runs. |
| Who operates the machine | You operate the Jenkins controller and agents, including their capacity and connectivity. | GitHub operates hosted runners; with self-hosted runners, you operate the machines and their upkeep. |
| Cost comparison | Not stated in the cited Jenkins documentation; deployment and infrastructure determine cost. | Hosted rates and included usage depend on runner type and account plan; check current terms. |
Diagnose the queue in Jenkins
Check executors and agent availability
Jenkins documentation says executor count determines how many concurrent tasks an agent can run. If all relevant executors are occupied, new work waits until capacity frees up. Check whether the agents intended for this job were online, whether their executors were busy, and whether the job was eligible to run on them.
#1 Best Overall
Check the controller’s role
Jenkins recommends configuring the controller with zero executors to avoid resource contention. If the controller is also running builds, its resource use may compete with controller duties. Review the controller and agent setup rather than treating executor count alone as the whole explanation.
Diagnose the queue in GitHub Actions
For GitHub-hosted runners, check concurrency limits
GitHub-hosted concurrency depends on the account plan and runner type. GitHub’s Actions limits documentation, accessed October 7, 2026, lists total concurrent jobs on standard hosted runners as 20 for Free, 40 for Pro, 60 for Team, and 500 for Enterprise. These are product limits, not guaranteed capacity for a particular job; runner-type exceptions and changing plan terms mean you should verify the current limits table before relying on a number.
The same documentation lists maximum concurrency of 1,000 for certain larger runners on Team and Enterprise, subject to runner-type exceptions and separate eligibility. This is not a general limit for every runner or account.
For self-hosted runners, check matching capacity
A self-hosted job needs an online, idle runner whose labels and groups match the job’s requirements. If none is available, it remains queued. GitHub’s current limits documentation says such a job can wait up to 24 hours before timing out. Check runner status, labels, groups, and whether matching machines are already occupied.
Inspect concurrency-group behavior
Concurrency settings can change which run is waiting and whether it remains pending. By default, only one run may be pending in a concurrency group; a newer pending run can cancel the earlier pending run. When sequential runs need to stay queued, GitHub documents configuring queue: max, which permits up to 100 workflow runs in a concurrency group. GitHub also lists a limit of 500 workflow runs queued per 10 seconds. These are documented limits, not evidence that either limit caused a particular delay.
What self-hosting changes
A self-hosted runner gives you control over the machine and its capacity, but also makes you responsible for keeping it available and secure. Plan for resource sizing, network access, updates, and isolation. GitHub warns that workflows from forks of public repositories can run dangerous code on self-hosted machines, so runner placement and workflow permissions need careful security boundaries.
A dedicated machine can be part of a self-hosted setup, but suitability depends on the resources and workload your workflows require; no particular machine is established here as an appropriate choice.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →How to make a fair platform comparison
- Define the interval. Capture trigger, queue, assignment, start, and completion timestamps for each run. Compare queue time separately from execution time.
- Match the workload. Use the same job matrix, commands, dependencies, caching strategy, and environment on each platform.
- Match available resources. Account for runner or agent CPU, memory, storage, and concurrency. Note whether capacity is hosted or self-managed.
- Record scheduling settings. Include Jenkins agent labels and executor availability, GitHub runner labels and groups, plan limits, and concurrency-group behavior.
- Compare repeated runs. A single queue incident cannot establish typical performance. Report the conditions and separate observed queue time from job execution time.
Choosing between Jenkins and GitHub Actions
For a queue problem, choose based on the capacity and operational model you can support—not on the 43-minute incident alone. Jenkins requires operating its controller and agents; GitHub Actions offers hosted runners with plan-dependent limits or self-hosted runners that you operate. In either case, the practical question is whether eligible workers are available when jobs need them, and whether the workflow’s scheduling rules permit those jobs to proceed.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
