How to Profile a Slow Workflow With Step Timings in GitHub Actions

Each step shows its own duration in the run view, and a small summary step can record timings so you optimize the real bottleneck.

GitHub shows per-step durations in the run UI and a job timing graph in Insights. To make timings explicit, write start and end timestamps to the job summary around the steps you suspect.

Steps

• Open the run and read each step duration in the log header.
• Use the repository Insights to compare job durations over time.
• Add a summary step that records elapsed time around a suspect step.

Workflow

steps:
  - run: echo "start=$(date +%s)" >> "$GITHUB_ENV"
  - run: npm run build
  - run: |
      end=$(date +%s)
      echo "Build took $(( end - $start ))s" >> "$GITHUB_STEP_SUMMARY"

Gotchas

• Queue time is separate from run time; a slow start is a runner-availability problem, not a step.
• Profile a few runs, since cache hits and cold starts swing single-run timings.

Related guides