ARC listener pod "CrashLoopBackOff" in CI

By Kaveh Alemi·Latchkey

The listener pod that receives job assignments is restarting on a loop. Kubernetes marks it CrashLoopBackOff, and no jobs dispatch. The reason is in the listener logs, usually auth or session creation.

What this error means

The listener pod in the controller namespace shows STATUS CrashLoopBackOff with a climbing restart count. Runner pods never appear because the listener never stays up.

$ kubectl get pods -n arc-systems
NAME                              READY   STATUS             RESTARTS
arc-runner-set-...-listener       0/1     CrashLoopBackOff   6

Common causes

Authentication or session creation fails on start

The listener exits immediately when it cannot authenticate or open a session, so Kubernetes restarts it repeatedly.

Controller and listener image version skew

A listener image that does not match the controller version can fail to start with an incompatibility error.

How to fix it

Read the listener logs to find the exit reason

1. Get the listener pod logs, including the previous crashed container.
2. Look for 401, 403, or session errors and fix the credential or scope.
3. Confirm the controller and scale set chart versions match.

kubectl logs -n arc-systems <listener-pod> --previous --tail=100

Align controller and scale set chart versions

Upgrade or reinstall so the gha-runner-scale-set-controller and gha-runner-scale-set charts are the same version.

helm list -n arc-systems
helm list -n arc-runners

How to prevent it

• Deploy controller and scale set charts at the same version.
• Validate credentials before rolling out a new listener.
• Alert on listener restart counts so crashes are caught fast.

Frequently asked questions

Related guides

References

• GitHub Actions documentation