Self-hosted runner vs shared runner: what changes in CI logs
Why failures on self-hosted runners differ from shared runners: network, registry, disk, cache, tool versions, permissions, and contaminated host state.
A shared runner is convenient: the platform manages the infrastructure. A self-hosted runner is flexible: you can install your own tools, access internal networks, and speed up builds. In logs, these are two different worlds.
If you are new to runner operations, do not blame every failure on the code. Sometimes the runner is the broken part.
Job vs runner
A job is the set of commands in your CI config. A runner is where those commands execute. The same job may behave differently on GitHub-hosted, GitLab shared, or self-hosted runners.
What fails more often on self-hosted runners
- network access to registry or internal services;
- full disk;
- old Docker/Node/Java versions;
- runner user permissions;
- files left by previous jobs;
- local cache nobody cleans;
- access to secret managers or Kubernetes clusters.
What fails more often on shared runners
- no access to internal network;
- shorter timeouts;
- restrictions on privileged containers;
- slow cold starts;
- incompatible image version;
- external registry rate limits.
How to read the log
Do not look only at the final error. If npm test failed after ENOSPC, the root issue is disk, not tests. If docker pull cannot reach the registry, the application has not even started. If the failure appears only on one self-hosted runner, compare host state.
Where Exlogare fits
Exlogare helps separate code regressions from environment failures. RCA can say “looks like disk full on a self-hosted runner” or “registry unavailable from shared runner.” Use generic ingest, or the GitLab/GitHub integrations for provider-specific setup.
Related reading
- GitLab Runner: docker, shell, and kubernetes executor failure classes
- CI artifacts and logs: what to keep, and what not to upload to S3 as-is
Checklist
- Identify the runner type for the failed job.
- Check disk, network, and registry.
- Compare tool versions.
- Reproduce on another runner if possible.
- Separate infra failure from test failure.
- Do not keep raw logs with secrets longer than needed.