## TL;DR

A newly registered runner does not run untagged jobs by default: if the job has no tags and the runner's tag_list is set, jobs never match. Either tag the job or set run_untagged=true on the runner via the API. The two classic causes are runner tags and shared-runner competition.

## Fix

1. A newly registered runner does not run untagged jobs by default: if the job has no tags and the runner's tag_list is set, jobs never match.
   Expected: You get the expected result; the problem is gone.
2. Either tag the job or set run_untagged=true on the runner via the API.
   Expected: You get the expected result; the problem is gone.
3. If shared runners are exhausted and a project runner exists, GitLab still routes to the exhausted pool unless shared runners are explicitly disabled for the project (shared_runners_enabled=false), so disable them when you go dedicated.
   Expected: You get the expected result; the problem is gone.

## When to use

- You are setting up or using this GitLab CI feature.
- The symptom matches: runner online but jobs stuck - tags and shared-runners.

## When NOT to use

- Unrelated GitLab CI issues (different feature, different failure).
- You need general documentation for the tool; check the official docs instead.

## Compatibility

Reported against GitLab CI. Source: https://github.com/velrite/atlas/blob/HEAD/docs/incidents/incident-log.md.

## Variant phrasings

### runner online but jobs stuck - tags and shared-runners

## Why it happens

The runner shows Online in the UI but jobs stay stuck with 'no runners online assigned to it'.

## Edge cases

- If your error message differs even slightly, this is probably a different issue; search the exact text.
- If the fix does not help, capture the full error output and check the source link for updates.

## Source

https://github.com/velrite/atlas/blob/HEAD/docs/incidents/incident-log.md