iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A 43-minute CI queue is a problem to diagnose, not proof that Jenkins or GitHub Actions is inherently slower. Find out whether the job was waiting for a worker, blocked by a concurrency rule or approval, or delayed somewhere else; only then compare execution speed. Jenkins capacity depends on agents and executors, while GitHub Actions depends on hosted-runner limits or the availability of a matching self-hosted runner.
What a 43-minute queue does—and does not—tell you
Queue time is the delay between a job becoming eligible to run and a worker actually starting it. It is different from execution time, which begins once the job starts. A long wait for one workflow does not establish that either CI platform is generally slower, and the 43-minute figure here is an incident description, not an independently verified measurement or a typical wait-time statistic.
First locate the delay in the workflow. A job can wait before assignment to a worker, behind a concurrency rule, for an environment approval, or at another workflow gate. Record timestamps for the trigger, queue entry, worker assignment, job start, and completion. That timeline shows whether the delay was in scheduling or in the job itself.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How Jenkins and GitHub Actions allocate work
| What to compare | Jenkins | GitHub Actions |
|---|---|---|
| Where work runs | Agents execute jobs. Each agent has a configured number of executors, which determines how many tasks it can run concurrently. | Jobs run on GitHub-hosted runners or self-hosted runners. Hosted capacity is subject to plan and runner type; self-hosted capacity depends on available machines that match the job. |
| Common reason for waiting | Suitable agents may be offline or busy, the job may not match an agent label, or controller resources may be constrained. | Hosted concurrency may be at its limit; for self-hosted jobs, no online idle runner may match the job’s labels and groups. Workflow concurrency rules can also affect pending runs. |
| Who operates the workers | You operate and size the Jenkins controller and agents, including their capacity and connectivity. | GitHub operates hosted runners. With self-hosted runners, you operate the machines and handle their upkeep, security, and connectivity. |
| Cost evidence | The sources cited here do not establish a Jenkins deployment cost; infrastructure and configuration determine it. | Hosted usage rates and included usage vary by runner SKU and account plan. Check current GitHub terms for the account and runner type. |
Jenkins: check executors and agents
In Jenkins, an executor is a slot for running a task on an agent. As Jenkins explains, “The number of executors determines how many concurrent tasks can be run on an agent.” See the Jenkins project’s Using Jenkins agents documentation.
#1 Best Overall
Check whether an agent that can run the job is online, whether its labels meet the job’s requirements, and whether its executors are already occupied. Also check controller health and resource contention. Jenkins recommends setting the controller’s executor count to zero to avoid resource contention; configure agents to do build work instead.
GitHub Actions: check runner type and capacity
For GitHub-hosted runners, check whether the account’s plan and selected runner type have available concurrent-job capacity. For self-hosted runners, verify that a runner is online, idle, and matches the job’s labels and groups. GitHub documents that a self-hosted job can remain queued when no such runner is available, with a 24-hour queue timeout. That timeout is a product limit, not a promise that jobs will start within a particular period.
GitHub’s limits documentation, accessed October 7, 2026, lists 500 workflow runs queued per 10 seconds. It lists total concurrent GitHub-hosted standard runner jobs as 20 for Free, 40 for Pro, 60 for Team, and 500 for Enterprise. These are plan limits, not estimates of normal queue time. The same documentation lists a maximum concurrency of 1,000 for certain larger runners on Team and Enterprise, subject to runner-type exceptions and plan eligibility. Check the current GitHub Actions limits because limits and eligibility can change.
Check whether workflow rules caused the wait
GitHub Actions concurrency settings can change what “waiting” means. By default, a concurrency group allows only one pending run; a newer pending run in the same group can cancel the older pending run. If the workflow must execute runs sequentially rather than replace a pending run, configure queueing with queue: max. GitHub documents a limit of up to 100 workflow runs in such a concurrency-group queue. Confirm that the group name and cancellation behavior match the workflow’s needs before treating a pending run as a runner-capacity problem.
For either platform, check environment approvals and other workflow gates alongside worker availability. A job that has not been released to a runner is not evidence that the runner pool itself is undersized.
A practical incident checklist
- Build a timeline. Capture trigger, queue entry, assignment, start, and completion times for the affected run. Use the job and workflow history to identify when the delay began.
- Identify the waiting state. Determine whether the job awaited an agent or runner, sat in a concurrency group, required an environment approval, or was blocked elsewhere.
- Inspect Jenkins workers, if applicable. Check that a suitable agent is online, labels match, executors are available, and controller resources are not constraining scheduling.
- Inspect GitHub Actions capacity, if applicable. Check plan concurrency and runner type for hosted jobs. For self-hosted jobs, confirm a matching runner is online and idle, with the required labels and groups.
- Review workflow concurrency and gates. Look for pending-run replacement or cancellation behavior, queue configuration, and approval requirements.
- Compare like with like. Use the same job matrix, workload, runner resources, concurrency, caching, and environment. Report queue time separately from execution time.
Should you switch platforms to avoid queues?
Not on the evidence of one 43-minute wait. Jenkins may need more available agent executors or better-matched agents; GitHub Actions may need a change in hosted capacity, a matching self-hosted runner, or different concurrency settings. A platform change does not by itself establish that the underlying capacity or scheduling issue will disappear.
If considering self-hosted GitHub runners, account for the operational work that comes with control over the machine: resource sizing, network access, updates, isolation, and security boundaries. GitHub warns that workflows from forks of public repositories can run dangerous code on self-hosted machines. Do not expose machines or credentials to untrusted workflow code without an appropriate security design.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Choose by the operating model and measured workload, not by an isolated queue duration. A fair comparison needs equivalent job definitions and resources, plus separate measurements of scheduling delay and job runtime. Hosted-runner costs and included usage should be checked against the actual plan and runner SKU; Jenkins deployment costs depend on the infrastructure used.
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.
