Skip to content

Run Logs and Job Summaries


You’ve been glancing at the Actions tab for a few chapters now just to confirm things ran. It’s worth slowing down and actually learning what’s on that screen — because once workflows get more complex, the run history and logs are where you’ll spend most of your debugging time.

The Run List

Open your actions-practice repository and click the Actions tab. Down the left side is a list of your workflows (right now, just “Hello World”); the main panel lists every run of the selected workflow, most recent first. Each entry shows:

  • A status icon — a green check for success, a red X for failure, a yellow dot for in-progress.
  • The commit message that triggered the run, and which branch it ran on.
  • How long the run took, and roughly how long ago it happened.

Click any run to drill into it.

Inside A Run

A run’s detail page shows a graph of its jobs — right now just the single greet job — with a status icon of its own. Click the job to see its steps listed top to bottom, each with its own status and duration. This is the same list you’ve already been expanding to check output, but now look at what’s around it:

  • Set up job and Complete job are steps GitHub adds automatically, bookending every job. Expanding “Set up job” shows exactly which runner image was assigned and a link to its full list of preinstalled software — useful when you’re wondering whether some tool is already available without installing it yourself.
  • Each of your steps shows its exact duration. If a job is slow, this is the first place to look for which step is the bottleneck.
  • Failed steps are expanded automatically and highlighted in red, with the specific line that caused the failure easy to spot without scrolling through the whole log.

Tip

Annotations — warnings or errors surfaced above the log, near the top of the run page — catch some problems before you even open a step’s log, including issues GitHub detects in the workflow file itself (like a deprecated action version).

Re-Running And Canceling

From a run’s page, the Re-run jobs button (top right) lets you re-run either the whole workflow or just the failed jobs — handy when a failure looks like a flaky network blip rather than a real problem, since it re-runs without needing a new commit. A Cancel workflow option appears on any run still in progress, for when you’ve spotted a mistake and don’t want to wait for it to finish.

You can also download a run’s complete logs as a zip file from the “…” menu in the top right of a run’s page — useful for keeping a record of a run, or sharing failure output outside GitHub.

Writing To The Job Summary

Every job has a Summary tab alongside its step logs — a space for markdown-formatted output that’s easier to read than raw log lines. You write to it with the $GITHUB_STEP_SUMMARY environment variable, which points at a file any step can append markdown into.

Add a summary step to hello.yml:

name: Hello World

on:
  push:

jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install dependencies
        run: pip install pytest
      - name: Run tests
        run: pytest
      - name: Write summary
        run: |
          echo "### Test Run Complete" >> "$GITHUB_STEP_SUMMARY"
          echo "- Python version: 3.12" >> "$GITHUB_STEP_SUMMARY"
          echo "- Status: all tests passed" >> "$GITHUB_STEP_SUMMARY"

Push it, open the run, and click the job’s Summary tab. Instead of scrolling through raw log output, you’ll see a small rendered markdown report — a heading and a bulleted list, exactly as if you’d written them in any other markdown file.

git add .github/workflows/hello.yml
git commit -m "Add job summary output"
git push

Note

>> appends to $GITHUB_STEP_SUMMARY rather than overwriting it, which matters the moment more than one step in a job writes to the summary — each one adds on rather than clobbering the last. A single > would silently erase whatever a previous step had already written.

This is a small addition on its own, but it’s worth having in your toolkit early: as workflows grow more steps and more jobs, a clear summary at the top of the run is often more useful than making someone dig through logs to find out what actually happened.

Last updated on