GitHub Actions Job Analytics and Cost Breakdowns
GitHub has Actions metrics for organizations and repositories. WarpBuild adds per-job p75 and p90 duration and queue time, CPU and memory, cost per job execution and runner sizing recommendations.
Last verified:
GitHub has Actions metrics for organizations and repositories. WarpBuild adds more detail per job for jobs on its runners. The Jobs page shows p75 and p90 duration, queue time, CPU, memory and success rate per job. The Spend page shows the cost of each job execution. Recommendations and Usage cover runner sizing and per-instance metrics.
Workflows stay in GitHub Actions, and WarpBuild runs the jobs. The data comes from WarpBuild reports and observability.
What does GitHub show about job duration and cost?
GitHub shows the execution time of each job in the workflow run summary. It also shows billable minutes, but only for jobs in private repositories that use GitHub-hosted runners. Those minutes are rounded up to the next minute and do not include any minute multipliers, per GitHub's docs on job execution time.
GitHub also has Actions metrics for organizations and repositories. Usage metrics show how many minutes workflows and jobs use. Performance metrics show job run times, queue times and failure rates. Under Insights, WarpBuild adds p75 and p90 duration and queue time per job, CPU and memory per job, the cost of each job execution, and runner sizing recommendations.
| Question | Where to look in the WarpBuild dashboard |
|---|---|
| What are the p75 and p90 duration, queue time, CPU and memory of a job? | Jobs page |
| What is the success rate of a job? | Jobs page |
| What did each job execution cost, and how many minutes were billed? | Spend page, CI tab |
| What did Docker builds, cache and agent runners cost? | Spend page, other tabs |
| Is this job on the right runner size? | Recommendations page |
| What did one runner instance do during a job? | Usage page |
What does the Jobs page show for each GitHub Actions job?
The Jobs page in Reports shows one row for each unique combination of repository, workflow and job name. Each row aggregates all runs of that job in the selected date range.
| Column | What it shows |
|---|---|
| Runs | Total number of executions |
| Success | Percentage of successful runs |
| Duration p75 / p90 | 75th and 90th percentile execution time |
| Queue p75 / p90 | 75th and 90th percentile time spent waiting in the queue |
| CPU p75 / p90 | 75th and 90th percentile peak CPU utilization |
| Memory p75 / p90 | 75th and 90th percentile peak memory utilization |
Use the p75 / p90 switch at the top of the page to choose which percentile the table and the chart show.
The time-series chart shows one metric (Duration, Queue time, CPU or Memory) at the selected percentile over time. Each line is one of the five jobs with the most runs in the selected period, so you can see when a job got slower or faster. Click a job in the legend to hide or show its line.
You can filter by repository, workflow, job name, runner label and stack, and you can search jobs.
CPU and memory need Observability to be enabled. Jobs without telemetry show a dash in those columns. Observability only collects metrics and logs for jobs that are longer than about one minute, so very short jobs have duration data but no CPU or memory data.
How do you see the cost of each GitHub Actions job?
The Spend page in Reports shows cost data in four tabs: CI, Docker builders, Cache and Agent runners. Each tab has a daily stacked bar chart of costs, summary cards, a table and filters.
| Tab | Daily chart grouped by | Summary cards | One table row is | Filters |
|---|---|---|---|---|
| CI | Repository or runner label | Total cost, runner cost, snapshot cost, total jobs | One job execution | Repository, runner label, stack, job name, snapshot usage |
| Docker builders | Profile or architecture | Total cost, total sessions | One Docker Builder session | Profile, architecture |
| Cache | Cache type | Total cost, storage cost, operations cost, total entries | One cache billing entry | Cache type (storage, operation-hit, operation-commit) |
| Agent runners | — | Total cost, total agents | One agent run | Label, environment |
The Docker builders tab shows each session with its profile, architecture, duration and cost. The Agent runners tab shows each run with its agent VM, label, environment, session, run time and cost. The CI and Agent runners tabs also support search. Per-minute runner rates are on the pricing page.
Where do you find queue time for a job or a runner?
Queue time is how long a job waits before it starts running. It appears in two places:
- Per job: the Queue column on the Jobs page, at p75 or p90.
- Per runner: open a runner from the Runners page. The Activity card shows Queue time p90 for the selected date range, and the Jobs on this runner table shows Queue p90 for each job.
If queue time is high, GitHub Actions Queue Times and How to Fix Them covers the causes and fixes.
How do Recommendations and Usage help with runner sizing?
The Recommendations page lists jobs that could run faster or cheaper on a different runner. Each row is one job and shows:
- Suggestion: the current runner label and the suggested runner label, with the peak usage that led to the suggestion. To apply it, change
runs-onin the workflow file. - Runs: the number of runs of the job.
- CPU p90 and Memory p90: the 90th percentile CPU and memory usage across the job's runs.
Expand a job to see its past runs, with the runner, start time, CPU, Memory, Disk, Disk I/O and Network for each run. Each run links to its GitHub Actions job run and to its metrics on the Usage page. In the past runs table, CPU, memory and disk values at or above 80% are highlighted as high, and values below 25% are highlighted as low.
The under-provisioned recommendation uses these thresholds:
| Metric | Threshold |
|---|---|
| Max Sustained CPU | >= 80% |
| Max Memory Utilization | >= 80% |
| Max Filesystem Utilization | >= 80% |
| Max Disk I/O | >= 80% of supported throughput |
The Usage page lists the runner instances started for your runners. You can search instances, pick a date range, and filter by Runner and Status, and by Stack when you use BYOC. Open an instance to see its Resource utilization chart and Instance logs, which show both system logs and GitHub Actions logs.
Runner Level Metrics for GitHub Actions Jobs explains how to read each metric and choose a new runner size.
How do you export job analytics and spend data?
Every report supports CSV export from the More actions menu (⋯) at the top of the page. To split CI spend by repository or team, see Attributing GitHub Actions Cost per Repository and Team.
Can you send runner telemetry to your own observability backend?
Yes. Telemetry export in Settings can send runner metrics and logs to your own OTLP backend. Storing data in WarpBuild and exporting it to your backend are independent settings, so you can turn on either one or both. There are presets for providers such as Datadog, Honeycomb, Grafana Cloud, Axiom, New Relic, Dynatrace and Elastic, and a Custom (OTLP) option. Follow the setup steps to pick a provider and add your ingestion key.
FAQ
How do I see which GitHub Actions jobs are slowest?
Open Insights, then Jobs. Each row is one repository, workflow and job name. Pick p75 or p90 with the switch at the top, then sort the table by duration. The chart shows duration over time for the five jobs with the most runs.
How do I track CI costs per repo or job and see which jobs cost the most?
Open the CI tab of the Spend page. The daily cost chart groups cost by repository or runner label. Each table row is one job execution with its runner cost and snapshot cost. Sort the table by cost and filter it by repository, runner label, stack and job name.
Why are CPU and memory empty for some jobs?
CPU and memory need Observability to be enabled, and jobs without telemetry show a dash in those columns. Observability only collects metrics and logs for jobs that are longer than about one minute.
How do I export job or cost data to CSV?
Open the More actions menu at the top of a report and choose Export CSV.
Start with $10 in free credits
Change the runner label in your workflow and keep the rest of your GitHub Actions setup. Runner time is billed per minute.