DevOps / GitHub Actions Interview Questions
How do you debug failing GitHub Actions workflows — enabling debug logging and using tmate?
When a workflow fails and the log output is not enough to diagnose the problem, GitHub Actions provides two main debugging mechanisms: enhanced log verbosity via repository secrets, and live interactive SSH access to the runner via the tmate action.
1. Enable debug logging by adding two repository secrets (or re-running the workflow with debug enabled in the UI):
ACTIONS_RUNNER_DEBUG=true— enables verbose runner-level diagnostics (why jobs were queued, runner setup details)ACTIONS_STEP_DEBUG=true— enables verbose step-level logs, including inputs/outputs of actions and shell-expanded commands
You can also re-run a failed job with debug logging enabled from the GitHub UI via "Re-run jobs" → "Enable debug logging".
2. Interactive SSH debugging with tmate — the mxschmitt/action-tmate action pauses the runner and opens an SSH tunnel so you can connect to the live runner and explore the filesystem, environment, and run commands manually:
steps: - uses: actions/checkout@v4 - name: Run tests (may fail) run: npm test continue-on-error: true # don't abort before tmate step - name: Setup tmate debugging if: failure() # only open SSH if something failed uses: mxschmitt/action-tmate@v3 timeout-minutes: 15 # auto-close after 15 min with: limit-access-to-actor: true # only the workflow triggerer can connect
Other useful debugging techniques:
run: env | sort— print all environment variables at a step to verify injected values.run: cat $GITHUB_EVENT_PATH | python3 -m json.tool— inspect the raw event payload.- Use
actions/upload-artifactto save log files or test-result directories for inspection after the run.
More Related questions...