Q: How do you troubleshoot, triage, and handle failed workflows in GitHub Actions?

Diagnose workflow failures quickly without clicking through multiple web UI menus:

# List recent pipeline runs
gh run list --limit 20

# View only the failed log output directly in terminal
gh run view 12345678 --log-failed

# Download diagnostic artifacts
gh run download 12345678 --dir ./artifacts/

# Re-run only the failed jobs in the workflow
gh run rerun 12345678 --failed

• Inspect Failed Logs: Use gh run view <run-id> --log-failed to output only the exact failing step lines.
• Download Artifacts: Retrieve test reports, screenshots, and logs using gh run download.
• Rerun Only Failed Jobs: Avoid re-executing successful 30-minute test jobs by using gh run rerun --failed to retry only the affected component.
• Debug Logging: Enable runner and step diagnostic logging by setting repository secrets ACTIONS_STEP_DEBUG=true and ACTIONS_RUNNER_DEBUG=true.

Prevent recurring transient failures from blocking development velocity:

# Example automated retry for network-sensitive step
- name: Push container image with exponential retry
  uses: nick-fields/retry@v3
  with:
    timeout_minutes: 5
    max_attempts: 3
    retry_wait_seconds: 10
    command: docker push ghcr.io/org/api:${{ github.sha }}

• Step-Level Retries: Use retry actions (such as nick-fields/retry) for network-sensitive operations like Docker image pushes or registry downloads.
• API Rate Limit Mitigation: Authenticate all external API calls (e.g. GitHub API, Docker Hub) using personal or bot tokens to avoid anonymous IP rate limits.
• Flaky Test Isolation: Quarantine flaky end-to-end tests into a non-blocking job or rerun failed tests once before failing the entire pipeline.
• Notification Webhooks: Configure Slack / PagerDuty alert webhooks triggered only on if: failure() to notify on-call engineers immediately.