How can I monitor GitHub Actions performance and cost across my organization?

Use Depot's GitHub Actions dashboard to monitor every job that runs on GitHub Actions runners managed by Depot across your GitHub organization.

The main page shows queued, running, and completed jobs from every connected repository. The Analytics page shows duration, failure rates, and CPU and memory utilization. The Usage page breaks billable time down by workflow, repository, and runner type. Global log search lets you find the same error across previous jobs without opening runs one at a time.

This gives a platform team one place to answer the questions that actually matter:

• Which workflows consume the most time and money?
• Which jobs are getting slower?
• Are jobs constrained by CPU, memory, disk, or the network?
• Which jobs are failing repeatedly?
• Which tests are slow, flaky, or responsible for recurring failures?

There's one important boundary. Depot collects this job telemetry for jobs running on Depot GitHub Actions runners. It can't attach runner metrics or Depot usage to a job that still runs on a GitHub-hosted or unrelated self-hosted runner.

Start with the organization-wide job view

The GitHub Actions page in Depot shows live runner status and jobs across the repositories connected to your Depot organization. Start here during an incident. You can see whether jobs are queued, running, or finished without moving between repository tabs in GitHub.

For longer timeframes, open GitHub Actions Analytics. It shows the slowest jobs across repositories and workflows, duration trends, failure rates, and CPU and memory utilization. Filter by repository, workflow, or timeframe to move from an organization-wide pattern to the job behind it.

The useful sequence is:

1. Find the slow workflow at the organization level.
2. Open one of its 50 slowest job runs.
3. Compare step timing with resource utilization.
4. Search prior logs for the same symptom.

That's faster than starting from one failed pull request and trying to guess whether it's an isolated problem.

Read CPU, memory, network, and disk signals correctly

Resource charts are useful only when they're aligned with the job's steps. Depot puts metrics next to the log timeline and marks step boundaries, so you can see what the runner was doing when utilization changed.

For GitHub Actions jobs on Depot GitHub Actions runners, the current dashboard exposes CPU and memory telemetry plus step-level timing. Network and disk don't currently have dedicated GitHub Actions telemetry charts. Use the job's step timing and logs to identify those bottlenecks instead of treating low CPU as proof that the runner is oversized.

Depot Linux and macOS runners include an in-memory disk accelerator, and Depot accelerates compatible GitHub Actions caches at up to 1000 MiB/s. Those features can remove a large amount of disk and transfer waiting, but the step timing still tells you whether they affect the workload in front of you.

Depot CI has a separate job view. It exposes CPU and memory alongside step timing and adds disk I/O telemetry for read and write throughput, IOPS, and total bytes transferred. Depot CI doesn't currently expose a dedicated network throughput chart either. Network-bound work is still diagnosed from the steps and logs that perform the transfer.

Use step timing to find the work worth fixing

A ten-minute job isn't one problem. It may be two minutes of dependency installation, five minutes of tests, one minute building a container, and two minutes uploading artifacts.

Open a slow job from the Analytics page and inspect its step-level timing breakdown. Focus on the longest step before changing the runner size:

• A test step with high CPU may benefit from more cores or better test parallelism.
• A test step with low CPU may be serialized, waiting on a database, or blocked on network I/O.
• A dependency step that changes dramatically between runs usually points to cache misses or unstable downloads.
• A file-heavy build with low CPU may be disk constrained.
• An artifact upload that dominates the job won't get faster from more CPU.

Runner size recommendations on the Insights page use historical CPU and memory utilization to flag consistently constrained or underutilized jobs. A size-up recommendation identifies a job that may finish faster with more resources. A size-down recommendation identifies a job that may cost less on a smaller runner without changing its performance.

Treat the recommendation as a benchmark to run, not a guarantee. The right runner is the one with the best completed job cost and feedback time for that workload.

Connect workflow performance to cost

Open the organization Usage page and select GitHub Actions. It reports total jobs, billable time, elapsed time, and usage over the selected month. The tables break usage down by workflow, repository, and runner type, with recent job health alongside workflow usage.

Start with billable time, not job count. One workflow with 100 thirty-second jobs can consume less than a workflow with five thirty-minute jobs.

For each runner type, the basic calculation is:

job cost = billable runtime x runner price
workflow cost = sum of every job cost in the workflow

Depot tracks GitHub Actions runner usage by the second and calculates total minutes at the end of the billing period. There's no one-minute minimum for each job. Larger runners have higher rates and minute multipliers, so compare the runtime reduction against the current runner price.

If an eight-core runner costs four times as much as a two-core runner, it must finish more than four times faster to reduce compute cost. A smaller runner isn't cheaper when resource pressure makes the job run for much longer. The Usage page and Analytics page give you both sides of that calculation.

Search failures across repositories

Per-run logs explain one failure. Depot's global GitHub Actions log search shows whether the same failure exists elsewhere.

Search by an error message, package name, hostname, timeout, or exit code. Then filter results by timeframe, repository, workflow, action, or runner type. Results include the matching line and can show surrounding lines for context. Click a result to open the complete logs for that workflow job.

This is especially useful for shared infrastructure failures. A registry timeout in six repositories is probably not six unrelated application bugs. A broken Marketplace action version may appear in dozens of workflows. Global search turns those failures into one incident instead of a pile of individual pull requests.

Filter state lives in the URL, so you can share the exact log search with the person investigating it.

Add test-level analytics with JUnit XML

Job failures are too coarse for a large test suite. A job can be red because one test failed once, one test fails on every run, or a shard contains several tests that have become progressively slower.

Depot can ingest JUnit XML from GitHub Actions jobs running on runners. Add depot/test-report-action after the test command:

jobs:
  test:
    runs-on: depot-ubuntu-24.04
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          mkdir -p test-results
          pnpm exec vitest run \
            --reporter=default \
            --reporter=junit \
            --outputFile.junit=test-results/junit.xml
      - name: Report tests
        uses: depot/test-report-action@v1
        if: ${{ !cancelled() }}
        with:
          path: test-results/

The job view shows pass, fail, error, and skip counts with failure details. The organization test analytics page shows failure rate, recurring failures, new failures, duration trends, and the slowest tests across repositories. Filter it to GitHub Actions or compare results with Depot CI.

Flakiness needs one qualification. GitHub Actions test results contribute to recurring-failure and slow-test analysis, but the Possibly flaky tests card depends on Depot CI attempt metadata. That specific detection is more complete for workflows running on Depot CI.

Run a practical weekly triage

CI monitoring works when it produces a short list of changes. Run this review every week:

1. Open the Usage page and rank workflows by billable time.
2. Open Analytics and compare average duration, duration trends, slowest jobs, and failure-rate changes.
3. Inspect CPU, memory, and step timing for the largest regressions.
4. Use global log search to group repeated failures across repositories.
5. Review runner size recommendations and benchmark one size change at a time.
6. Check test analytics for recurring failures and tests with rising P95 duration.
7. Record the change, then compare runtime, failure rate, and billable time after a representative week.

Don't optimize from averages alone. A stable average can hide a handful of terrible runs. A low average CPU percentage can hide one step pinned at 100%. A falling bill can hide a rising failure rate if developers are rerunning jobs manually.

Start with the workflows consuming the most billable time, then fix the longest step or most common failure inside each one. That keeps the work tied to both developer feedback time and actual spend.

Keep Depot GitHub Actions runners and Depot CI data separate

Depot offers two ways to run GitHub Actions workflow syntax, and their observability surfaces are related but not identical.

The GitHub Actions Usage and Analytics pages don't merge Depot CI execution into GitHub Actions runner usage. The organization test analytics page can combine reported JUnit results from both products, with a CI filter to separate them.