When a runner is deleted after one job, everything stored on it goes too: job logs, local build output, process history and temporary files. Unless you ship that data to external storage before the runner ends, the evidence of what ran, and who triggered it, may no longer exist when someone asks.
What GitHub says about logs
GitHub's guidance on autoscaling is direct. It warns that runner application log files for ephemeral runners "must be forwarded to an external log storage solution for troubleshooting and diagnostic purposes," and recommends making sure runner logs are forwarded and preserved externally before deploying an ephemeral autoscaling solution in production. The same point applies on any platform: if the log lives on the thing you delete, it is deleted.
What can go missing
| Evidence | Where it used to live | Where it should live now |
|---|---|---|
| Job output and exit status | Agent disk or CI server | CI platform history plus an exported copy |
| Runner start and stop events | Agent logs | Your orchestrator or cluster logs |
| Which image and digest ran the job | Implicit on a static agent | Recorded in the job metadata |
| Credentials issued to the job | A stored secret | Issuer logs of your identity or secrets service |
| Scan results for the commit | Local report file | Stored with the build record |
| Who approved a deploy | CI approval log | Exported approval record |
Steps to keep the trail
- Decide what an auditor or incident responder would ask. Typically: which commit, which pipeline definition, which image, who approved, and what the scan said.
- Make the job record those facts as part of its own output, for example the commit hash and the runner image digest.
- Forward runner and job logs to storage outside the runner, with retention set by your own policy.
- Keep scan reports and SBOMs as build artifacts tied to the commit, not as files on the runner.
- Log credential issuance in the system that issues credentials, since the runner will not remember.
- Test the trail: pick a build from last week and try to reconstruct it from stored data alone.
Retention is a platform setting too
CI platforms apply their own retention windows to logs and artifacts, and those can change. Check the current setting rather than assuming, and export what you must keep for longer. If you need background, GitHub Actions retention change and audit evidence covers one such change.
A note on claims
Evidence supports your own controls. It does not make you compliant by itself, and whether a given record satisfies a framework or an auditor is a judgment for your assessor. Keep the facts accurate and consistent, and avoid describing a control as operating before it has run.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a single piece of evidence can map to several controls, which is the reason to store it once and reference it.
Safeguard offers compliance and evidence automation, so records from scans and policies can be kept in one place. You can start with a free scan at gold.safeguard.sh/scan.
Quick check
Do ephemeral runners make audits harder?
Only if you leave evidence on the runner. Done well, a pipeline that records its inputs and ships logs gives a cleaner trail than a shared agent did.
Is the CI platform's own history enough?
It may be for job results, but it usually does not cover runner level events or credential issuance. Check what it retains and for how long.
Sources
Last reviewed: 19 October 2026.
