GitHub Actions GITHUB_STEP_SUMMARY Not Showing or Too Large
A job summary written via GITHUB_STEP_SUMMARY does not appear, or is truncated, because the content exceeded the per-step summary size cap, was written to the wrong file, or used an unsupported feature.
What this error means
The Markdown summary you appended to GITHUB_STEP_SUMMARY is missing from the run page or cut off, even though the step succeeded and wrote output.
Warning: $GITHUB_STEP_SUMMARY upload aborted, supports content up to a
limit, got much larger
- run: cat huge-report.md >> "$GITHUB_STEP_SUMMARY"Diagnose it: is the job queued, or is the runner gone?
A job that never starts and a job whose runner disappeared mid-run look similar in the UI and have opposite causes. The first is a labelling or capacity problem, the second is the runner being killed, usually by memory pressure or a spot reclaim.
- name: Runner facts
run: |
echo "runner name: $RUNNER_NAME"
echo "os/arch: $RUNNER_OS/$RUNNER_ARCH"
nproc; free -h; df -h /
echo "labels this job asked for: ${{ toJSON(job) }}"Common causes
Summary content exceeds the size limit
Each step summary has a maximum size. Dumping a large report or full log into GITHUB_STEP_SUMMARY exceeds it, and the summary is dropped or truncated.
Writing to the wrong target or too late
Echoing to stdout instead of appending to the GITHUB_STEP_SUMMARY file produces no summary. Each step owns its summary file, so cross-step appends do not accumulate as expected.
How to fix it
Append concise Markdown within the limit
- run: |
{
echo "## Test results"
echo "- Passed: 142"
echo "- Failed: 0"
} >> "$GITHUB_STEP_SUMMARY"Move bulk output elsewhere
- Keep summaries short; link to an uploaded artifact for full reports.
- Append to GITHUB_STEP_SUMMARY (the file), not stdout.
- Write the summary in the same step that produces it, since each step has its own summary buffer.
The failures that are not your workflow
- Exit 137 is the kernel out-of-memory killer, not an application error. Check
free -habove against your peak usage. - Disk exhaustion presents as unrelated write errors deep in a build. GitHub-hosted runners ship roughly 14 GB of free space, which a Docker-heavy job can exhaust.
- A lost connection to the server on a self-hosted runner is usually the host being reclaimed or rebooted, not a network fault in your job.
- A job that starts and immediately fails with no step output normally failed during runner setup, before your workflow ran at all.
How to prevent it
- Treat the step summary as a concise overview, not a full log.
- Upload large reports as artifacts and link them from the summary.
- Always append to the GITHUB_STEP_SUMMARY file.