Anyone who can run a workflow can enable runner diagnostic logging and step debug logging for a re-run. Setting them permanently takes write access to the repository. Debug logs are more verbose, so they widen the chance that something sensitive is printed. Treat debug runs as runs to review, then delete if needed.
What the two switches do
GitHub documents two settings:
| Setting | Effect |
|---|---|
| ACTIONS_STEP_DEBUG set to true | Step debug logging, which increases the verbosity of a job's logs during and after execution, with more debug events in step logs |
| ACTIONS_RUNNER_DEBUG set to true | Runner diagnostic logging, which adds two extra files to the log archive in a runner-diagnostic-logs folder: a runner process log and a worker process log |
You enable them by setting secrets or variables with those names in the repository containing the workflow, or at the environment or organization level.
Who can set them
- Repository level, organization repositories: write access.
- Repository level, personal repositories: collaborator.
- Environment level: admin access on organization repositories, or the owner for personal ones.
- Organization level: organization owners.
- For a single re-run: anyone with access to run the workflow can enable both from the re-run dialog.
Note what the documentation does not say. It does not state whether secrets remain masked when debug logging is on, and it gives no retention or visibility warning. Do not assume masking behaves the same way; verify it in a scratch repository with a fake value before trusting it.
Why it matters
More verbose logs print more of what tools and actions are doing: environment details, command lines, request information. GitHub's secure use guidance reminds you that secret redaction happens on the runner and only applies to secrets used in that job, so you should not assume every exposure is masked. It also says that if an unredacted secret appears in a run log, you should delete the log and rotate the secret.
Debug logging also leaves a trail attackers like. If a debug variable is set at the organization level, every repository inherits more verbose logs. A stale debug setting is easy to forget.
Steps to handle it well
- Search your repositories, environments, and organization for secrets or variables named ACTIONS_STEP_DEBUG and ACTIONS_RUNNER_DEBUG. Remove any left on permanently.
- Prefer the per-run option when debugging, so the setting does not persist.
- After a debug run, open the logs and look for tokens, keys, URLs with credentials, and authorization headers.
- If you find a real credential, delete the run log and rotate the credential. Deleting alone is not enough, since someone may already have read it.
- Restrict who can view logs by limiting access to the repository, and keep forks from running with write tokens.
- Record the incident, even a near miss, so the next debug session starts with the same checklist.
For private data in logs
Never log credentials at all. OWASP's secrets guidance says secrets should never be logged, and that there must be a process for removing a secret from logs while maintaining log integrity. For CI this means short log retention where policy allows, plus a rotation habit.
Quick check
Does enabling debug logging change what a workflow can do?
It changes what is written to logs, not permissions. The risk is exposure through verbosity.
Is deleting the run enough after a leak?
No. Delete it, then rotate the credential, because anyone who saw the log may still hold the value.
Safeguard compliance and evidence automation can help you keep records of log reviews and rotations. A free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Enabling debug logging
- GitHub Docs: Secure use reference
- OWASP Secrets Management Cheat Sheet
Last reviewed: 19 October 2026.
