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 queued GitHub Actions job is not automatically a broken runner. It may be waiting for hosted-runner capacity, an online self-hosted runner with matching labels, an ARC scale set, a workflow concurrency slot, an environment approval, or recovery from temporary GitHub load. Open the run, inspect the specific job, identify what it is waiting for, and then follow the matching branch below.
The fastest reliable diagnosis is: determine whether the job is waiting on a runner or a policy gate; identify the runner type and scope; check capacity or eligibility; then verify workflow settings, schedule timing, logs, billing, and service health.
Why is my GitHub Actions job stuck in the queue?
GitHub uses the queued state for several different conditions. A job can be ready but have no available execution slot, or it can be deliberately prevented from starting by workflow policy. Treating every queued job as a runner outage often leads to the wrong fix.
- Hosted capacity: your account has reached its concurrent-job limit, so additional jobs wait.
- Self-hosted eligibility: no online, idle runner matches every label and runner-group requirement in
runs-on. - ARC scaling: an Actions Runner Controller scale set cannot create enough runner pods, or its configured capacity is zero.
- Workflow concurrency: a concurrency group is intentionally holding a run or replacing an older pending run.
- Environment protection: a deployment job is waiting for required reviewers, wait timers, or another protection rule.
- Platform load: a scheduled workflow is delayed during a high-load period, especially near the start of an hour.
- Account or network conditions: billing limits, permissions, firewall, DNS, or a GitHub service incident prevents scheduling or runner communication.
First establish which of these states applies. The runner model and the policy that controls the job determine the remedy.
#1 Best Overall
- Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
- With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
- Wide Application: attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
- Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
- Economical &Reusable: Built durable materials with a long-lasting battery,our CAGIWIRU air duster it's a sustainable alternative to disposable air cans.
Start with the run and job details
- Open the workflow run. In the repository, open the Actions tab, select the workflow, and open the affected run.
- Open the individual job. Read the job’s status and details rather than relying only on the run-level badge. A run can contain jobs that are running, skipped, waiting for an environment, and queued for runners at the same time.
- Determine what “waiting” means. If the job references an environment, check whether deployment protection rules must pass before a runner is requested. GitHub documents these controls in its deployment protection guidance.
- Read
runs-onand workflow-level settings. Record the runner label, runner group, environment, and anyconcurrencyblock. These values define where the job may run and whether another run can occupy its slot. - Note the age of the queue entry. A short delay during a burst is different from a job that has waited long enough to indicate a stale or unavailable runner.
Identify the runner model before changing anything
GitHub supports standard GitHub-hosted runners, larger hosted runners, self-hosted runners, and Actions Runner Controller (ARC) scale sets. Their capacity controls and failure modes are different. Use GitHub’s runner overview to confirm the model used by the repository and organization.
Standard GitHub-hosted runners
GitHub provisions the machine for each job. You do not repair an individual host; you inspect account concurrency, plan limits, usage, and any service-wide load.
Larger hosted runners
These are hosted machines with larger specifications and separate access and billing requirements. Confirm that the repository is permitted to use the runner and that the applicable billing arrangement is active before treating a queue as a capacity problem.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC 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 & 11Self-hosted runners
Your organization owns or manages the machine. The job can start only when at least one connected runner is online, idle, permitted for the repository, and matches all requested labels and runner-group restrictions.
ARC scale sets
ARC creates self-hosted runner pods on demand. A healthy controller, available cluster capacity, and sensible minimum and maximum runner settings are all required before a queued job can be assigned.
Branch 1: diagnose hosted-runner capacity
Inspect active and total usage
- Open the organization or enterprise Settings.
- Go to Actions → Runners.
- Select the relevant GitHub-hosted runner entry.
- Review Active jobs and All jobs usage.
When the account reaches its maximum concurrent-job count, new jobs enter a queue. The limit depends on the plan and product context, so do not assume that a value seen in another organization applies to yours.
Current Enterprise Cloud limits
The following figures are listed in GitHub’s current Enterprise Cloud Actions limits documentation, accessed October 13, 2026. They are plan-specific documentation values, not universal limits for every GitHub product or account.
Rank #2
- Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
- Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
- Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
- Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
- Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth
| Plan | Concurrent standard hosted jobs | Concurrent macOS jobs |
|---|---|---|
| Free | 20 | 5 |
| Pro | 40 | 5 |
| Team | 60 | 5 |
| Enterprise | 500 | 50 |
Check the limits documentation for your exact plan, enterprise product, runner type, and region before making a purchasing or architecture decision. GitHub states that support can increase concurrency limits in some circumstances.
Fixes for an exhausted hosted pool
- Wait for currently running jobs to finish when the spike is temporary.
- Cancel obsolete runs, especially duplicate pull-request builds, if your development process permits it.
- Reduce unnecessary matrix combinations or split expensive workflows so critical checks receive capacity sooner.
- Move workloads that require guaranteed parallelism to a runner option with capacity appropriate for the workload, after confirming repository access and billing requirements.
- Ask GitHub Support about a higher concurrency limit when demand is sustained and the plan permits an increase.
Do not scale hardware or restart self-hosted machines while the evidence points to a hosted concurrency ceiling; those actions cannot create another hosted slot.
Branch 2: get a self-hosted runner to pick up a job
Verify online, idle, and authorized status
In organization, enterprise, or repository Settings, open Actions → Runners. Confirm that at least one runner is shown as online and not already executing another job. Then verify that the runner is available to the repository through its runner group and that its labels include every label requested by runs-on.
GitHub routes a job only to an available runner that satisfies all of these conditions. A runner labeled linux cannot accept a job requiring linux and gpu unless it has both labels. A runner in a group that excludes the repository is not eligible even if it is online.
Recommended Free Tools
Check the service process and machine health
- Confirm the runner service or listener process is running under the intended account.
- Check that the host has not shut down, suspended, exhausted disk space, or lost access to required tools.
- Verify outbound network access, DNS resolution, and any organizational firewall or proxy rules that affect GitHub communication.
- Review the runner application and operating-system logs for disconnects, authentication failures, or repeated restarts.
- Use the runner configuration script’s documented
--checknetwork diagnostic on the host when connectivity is suspect, then correct the reported endpoint, DNS, proxy, or firewall issue.
Understand the assignment timers
If an online matching runner does not pick up an assigned job within 60 seconds, GitHub re-queues that job so another runner can accept it. A self-hosted job that remains queued for more than 24 hours fails. These timers make a brief re-queue normal, but a repeated cycle indicates that runners are disconnecting, rejecting the assignment, or failing eligibility checks.
Check runner software age
GitHub stops queueing jobs to a self-hosted runner that has not performed a software update within 30 days. A required critical security update can also block queueing until the runner is updated. If the runner appears online but never receives work, compare its installed runner version with the current supported release, apply the update, restart the service, and confirm that it returns online.
Validate the workflow’s labels and groups
Inspect the exact runs-on expression after variable expansion and matrix evaluation. Common mistakes include a spelling difference, a label that exists only on a retired machine, a group restriction that excludes the repository, and a matrix combination for which no runner has all required labels. Temporarily targeting a known-good label set can isolate an eligibility problem, but restore the intended restrictions after the test.
Rank #3
- 【Large size】：Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
- 【LED backlight mouse pad】：Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
- 【Anti-slip rubber base】：Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
- 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
- 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
Branch 3: troubleshoot ARC scale-set queues
With ARC, a queued job may be waiting for a pod rather than a permanently provisioned machine. Inspect the ARC controller and the scale set that owns the requested labels.
Check minimum and maximum capacity
Review the scale set’s minRunners and maxRunners settings. The minimum controls the baseline number of runners kept available; the maximum limits how far the set can scale. Ensure the maximum is high enough for the burst you are trying to absorb and that cluster quotas allow the corresponding pods.
Look for an intentional zero setting
Setting both minRunners and maxRunners to zero intentionally stops new runner pods while existing work drains. This is a valid maintenance configuration, but it leaves new jobs queued. Restore a nonzero capacity, allow the controller to reconcile, and verify that pods become ready before diagnosing the workflow itself.
Inspect controller and pod creation failures
- Check controller logs for authentication, registration-token, or API errors.
- Check whether the cluster can schedule the runner pod because of CPU, memory, taints, quotas, or image-pull failures.
- Confirm that the scale-set labels match the workflow’s
runs-onvalue. - Verify that newly created pods register as online runners and become idle before the assignment timeout.
Branch 4: check workflow concurrency rules
A workflow can create its own queue even when runners are available. A concurrency group limits how many runs in the same group may execute or wait. By default, a group has one running run and one pending run. When a newer run enters the group, it replaces the older pending run unless queueing behavior is configured to retain runs.
Cancel obsolete validation runs
For pull-request checks where only the newest commit matters, configure the group to cancel in-progress work and prevent a backlog of stale runs:
concurrency:
group: ci-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueThis reduces wasted runner time, but it deliberately discards older runs.
Retain every run when order matters
For release, migration, audit, or other workflows where every invocation must be preserved, use a group without canceling in-progress work and select the queueing behavior supported by your workflow design. Confirm that retaining runs will not create an unbounded backlog.
Rank #4
- 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
- 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
- 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
- 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
- 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
Distinguish policy waiting from capacity waiting
If the run page shows repeated replacement or a single pending run in the same group while unrelated jobs start normally, the concurrency rule is the bottleneck. Changing runner counts will not remove that policy queue. Adjust the group key or cancellation choice only after deciding whether older runs are disposable.
Branch 5: resolve environment and deployment protection waits
A job that references an environment may not request a runner until environment protection rules pass. Required reviewers, wait timers, and other deployment controls can therefore look like a runner queue.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Open the job details and identify the environment named by the workflow.
- Open the repository or organization environment settings.
- Check required reviewers, wait timers, branch restrictions, and any rules that can prevent approval.
- Approve the deployment or correct the rule if the release is authorized.
- Recheck the job after the protection rule passes; only then should you investigate runner capacity.
Keep protection rules intact for production deployments. The correct fix is to satisfy or deliberately revise the gate, not to add more runners.
Branch 6: account for scheduled-workflow timing and GitHub load
GitHub reports that platform load is high near the start of every hour. During sufficiently high load, some scheduled jobs may be delayed or dropped. This is a specific risk for schedule-triggered workflows, not a universal explanation for every queued job.
Move cron jobs away from the top of the hour
If the same scheduled workflow is delayed at 00 minutes past the hour, choose a less congested minute and observe subsequent runs. For example, move a job from 0 * * * * to a minute such as 17 * * * * when that timing fits the business requirement. Do not change a release schedule without checking dependencies, maintenance windows, and downstream systems.
Use evidence before changing schedules
Compare queue times for scheduled and manually dispatched runs. If only scheduled runs show the pattern and interactive runs start normally, timing or transient platform load is plausible. A schedule change can reduce exposure to that pattern, but it is not a guarantee and will not fix a missing self-hosted runner or a concurrency rule.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Use metrics and logs to confirm the bottleneck
Actions metrics can show average queue time, runtime, and failure rates by workflow, job, repository, and runner type. Compare these categories instead of looking only at one failed run.
Best Value
- 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
- 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
- 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
- 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
- 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
- High queue time across workflows and runner types: investigate account capacity, platform load, or an incident.
- High queue time for one self-hosted label set: inspect that fleet’s online count, labels, groups, service health, and update status.
- High queue time for one workflow: inspect its concurrency group, matrix size, environment gate, and schedule.
- Normal queue time but high runtime: optimize the job itself; adding runners may not improve completion time.
- Frequent assignment failures: inspect runner logs, connectivity, registration, and the 60-second pickup behavior.
Review the run log and enable GitHub Actions debug logging when ordinary logs do not show why scheduling or runner communication stopped. Capture timestamps, runner labels, group names, queue duration, and the first error so platform administrators can correlate events.
Check billing, permissions, networking, and service status
Billing and usage controls
Actions usage includes runner minutes and artifact storage. Budget controls, exhausted allowances, or billing errors can prevent expected execution or storage operations. Review organization and enterprise billing settings when a queue coincides with a usage alert or payment change.
Repository and runner permissions
Confirm that the repository is allowed to use the selected runner group or larger runner. A runner can be healthy and online but unavailable to a repository because of access policy. For larger runners, verify both repository access and the billing arrangement required by the configuration.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsNetwork and external dependencies
Inspect organizational firewalls, proxies, DNS, and third-party services used by the runner. A disconnected self-hosted listener may remain visible briefly while being unable to accept work. Resolve connectivity errors, restart the runner service if required, and watch for a return to online and idle status.
GitHub service incidents
Check GitHub Status when multiple unrelated repositories experience simultaneous queue delays. Record the incident identifier and affected timestamps before opening a support request. If your local checks are clean and the delay persists across runner types, provide GitHub with run URLs, queue times, plan context, and diagnostic logs.
Decision table: match the symptom to the fix
| What you observe | Most likely bottleneck | Next action |
|---|---|---|
| Active hosted jobs are at the account ceiling and new jobs wait | Hosted concurrency exhaustion | Wait, cancel obsolete work, reduce burst size, or request additional concurrency |
| A self-hosted label has no online idle runner | Fleet availability or connectivity | Start or repair the runner service and verify network access |
| Runners are online but none match all labels or groups | Eligibility mismatch | Correct runs-on, labels, or repository runner-group access |
| An online runner repeatedly receives and loses assignments | Pickup, service, or version problem | Inspect logs, apply updates, and verify the listener stays connected |
| ARC has no ready pods and both capacity settings are zero | Intentional scale-set drain or maintenance mode | Restore nonzero capacity and verify controller reconciliation |
| Only one concurrency group has a pending run | Workflow serialization | Change the group key or cancellation/queueing policy deliberately |
| A deployment job waits for approval before any runner starts | Environment protection | Satisfy or revise the environment rule |
| Scheduled runs delay around the start of each hour | Transient platform load | Move the cron minute and monitor later runs |
| Many repositories and runner types queue at once | Account-wide or GitHub service issue | Check usage, GitHub Status, and support guidance |
A practical recovery sequence for administrators
- Classify the wait. Decide whether the job is runner-queued, environment-gated, concurrency-pending, or part of a scheduled-load pattern.
- Capture evidence. Save the run URL, job name, queue start time, runner labels, runner group, environment, and concurrency group.
- Check the narrowest dependency first. For a self-hosted job, inspect the matching fleet; for a hosted job, inspect active usage; for a deployment, inspect the environment rule.
- Apply one reversible change. Start a runner, correct a label, approve an authorized deployment, cancel a stale run, or move a cron minute. Avoid changing several independent settings at once.
- Observe the next assignment. Confirm that the job moves from queued to in progress and that the same class of jobs no longer accumulates.
- Escalate with context. If the queue persists, include metrics, logs, timestamps, account plan, runner type, and GitHub Status information so the next team can distinguish capacity from service failure.
Prevent recurring queue backlogs
- Set labels and runner groups deliberately, and remove labels for retired or unavailable machines.
- Monitor online, idle, busy, and offline self-hosted runners rather than discovering shortages from failed builds.
- Keep self-hosted runner software within the supported update window and schedule maintenance before a critical update becomes mandatory.
- Size ARC
minRunnersandmaxRunnersfor normal demand and predictable bursts; document any zero-capacity maintenance window. - Use cancellation for disposable pull-request CI and retention for workflows where every run is required.
- Review hosted concurrency and usage against the plan’s current limits before launching large matrices.
- Stagger hourly schedules when they do not need to run at the top of the hour.
- Track queue time, runtime, and failure rate by workflow, repository, and runner class so a regression is visible before a 24-hour self-hosted failure deadline.
- Include billing, artifact storage, firewall, DNS, and GitHub Status checks in the incident runbook.
What the queue state tells you
The queue is a symptom, not a diagnosis. A hosted concurrency ceiling calls for capacity or workload changes; a self-hosted queue calls for an eligible, connected, maintained runner; ARC requires controller and pod capacity; concurrency groups require a policy decision; environments require approval; and scheduled-load delays may respond to a different cron minute. Following that order prevents unnecessary runner rebuilds and makes the eventual fix measurable.
Quick Recap
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.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →
