Skip to content
Latchkey

GitHub Actions "Runner not found" - Registration Lost or Raced

GitHub assigned the job to a runner record that no longer exists by the time the job tried to start. On ephemeral and autoscaling fleets this is usually a registration race or a runner that was reclaimed mid-handoff, not a configuration mistake.

What this error means

A queued job fails to start with "Runner not found" (or the runner disappears from the org/repo runner list moments after it appeared). Re-running the job typically succeeds because a fresh runner registers cleanly.

github-actions
Error: Runner not found.
The runner that was assigned to this job no longer exists or has not registered.

Common causes

Ephemeral runner deregistered before pickup

A just-in-time ephemeral runner registers, is assigned a job, then is reclaimed or expires before it finishes acquiring the job, so its record is gone when the job starts.

Registration race on an autoscaling fleet

The scale-up created a runner whose registration with GitHub had not fully propagated when the job was routed to it, leaving a dangling assignment.

A spot/preemptible instance was reclaimed mid-handoff

The underlying VM was preempted between registration and job start, removing the runner the job was waiting on.

How to fix it

Re-run the job - transient registration races clear on retry

  1. Re-run the failed job; a fresh runner registers and acquires it cleanly.
  2. If it recurs constantly, treat it as a fleet capacity or registration-propagation problem, not a single-job flake.

Ensure ephemeral runners are configured one-job-per-runner

Register self-hosted runners with --ephemeral so each runs exactly one job and a stale record is never reused for a second assignment.

Self-hosted runner setup
./config.sh --url https://github.com/ORG/REPO \
  --token "$REG_TOKEN" --ephemeral --unattended

Add capacity headroom so jobs are not routed to runners mid-teardown

  1. Keep enough warm/idle runners that a new job lands on a fully-registered runner.
  2. Confirm scale-down does not reclaim a runner that has just been assigned a job.

How to prevent it

  • Run self-hosted runners as --ephemeral so each runner record serves exactly one job.
  • Keep warm capacity so jobs route to fully-registered runners rather than ones still propagating.
  • On Latchkey managed runners, "Runner not found" registration races are detected and the job is retried automatically on a freshly registered runner, so transient handoff failures do not fail the run.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →