How Do I See CPU and Memory Usage for a Job?

Answer

CPU and memory for a GitHub Actions job come from an agent running on the runner machine: the WarpBuild agent emits system metrics in OpenTelemetry format over port 33931, and the observability Usage view draws those metrics against the same job's GitHub Actions log timeline so a spike and the step that caused it sit on one screen. GitHub Actions by itself reports run duration, queue time, job counts, and conclusion (GitHub Actions metrics), which is why the question of whether a machine ran out of RAM has to be answered somewhere other than the run page.

There are three places to read the numbers, and they answer different questions.

All three are documented in the observability reference and the reports reference. CI observability is one part of the WarpBuild product surface, alongside snapshot runners, remote Docker builders, an MCP server, and the Action Debugger.

Detail

What the agent collects

The agent sends three streams: utilization metrics from the machine, system logs from the machine, and the GitHub Actions logs for the job. The third stream is what makes the first two readable, because it puts workflow execution and system behavior on one timeline instead of in two browser tabs.

Five metrics are recorded per instance, and the collection method differs by metric.

The rolling average matters when you read a chart. A 5 second burst of full CPU does not move a 30 second rolling average much, so a chart that never crosses 50 percent can still contain short spikes that stall a step.

The hierarchy the numbers are grouped under

Metrics are aggregated in four levels, and each level is a filter in the Recommendations view.

That ordering is what turns a single bad run into a pattern. One job at 95 percent memory is an anecdote; the same job at 95 percent memory across every instance of warp-ubuntu-latest-x64-4x in ci.yml is a sizing decision. WarpBuild flags an instance as under provisioned when max sustained CPU, max memory utilization, or max filesystem utilization reaches 80 percent, or when max disk I/O reaches 80 percent of supported throughput.

A worked read: memory flat at the ceiling, CPU idle

Round numbers below stand in for your own readings. The shape is what you are looking for, on a job running warp-ubuntu-latest-x64-4x with 4 vCPU and 16 GB of RAM.

A memory line that climbs and then flattens is memory that has nowhere left to go, and flat CPU underneath it says the vCPUs are waiting rather than working. Adding parallelism here makes the job worse, because every extra worker needs its own copy of the fixtures. The move is one step up the same family.

The ladder below is Linux x64 because vCPU and RAM scale together on it at a flat $0.002 per vCPU minute. Rates come from the pricing page, checked on 2026-08-13.

Work the arithmetic before you move. A 22 minute job at 400 runs per month is 8,800 minutes.

• On warp-ubuntu-latest-x64-4x at $0.008 per minute: $70.40 per month.
• On warp-ubuntu-latest-x64-8x at $0.016 per minute: $140.80 per month.
• On warp-ubuntu-latest-x64-2x at $0.004 per minute: $35.20 per month.

The charts decide which of those three lines you are buying. Memory pinned at 95 percent with exit code 137 in the log makes the $70.40 increase a fix. CPU at 12 percent and memory at 22 percent across every run makes the $35.20 line the correct answer and the current spend a refund waiting to happen. Reading the charts costs no runner minutes either way.

More than one run

One run is a sample. The Jobs report aggregates every run of a unique repository, workflow, and job name in the selected period and reports CPU P75, CPU P90, memory P75, and memory P90 beside run count, success rate, duration percentiles, and queue time percentiles. A P90 memory value at 95 percent with a P75 at 60 percent describes a job that only sometimes runs out of room, which is a different problem from one that always does. Every report tab exports CSV with all rows matching the current filters, so the comparison can happen in a spreadsheet.

When there is nothing to read

Four rules explain an empty chart.

• Observability collects metrics and logs only for jobs longer than about 1 minute, so a job that fails in 20 seconds has no series.
• Collection can be paused. When paused, no telemetry is collected from your runners, including system logs and GitHub Actions logs. That control is how a job that must not emit metrics stays silent.
• On pooled instances, data can appear in the UI before a job is allocated. The telemetry agent initializes even while collection is paused, and no data is collected until allocation.
• Port 33931 carries the data to the platform. A restrictive egress policy on a self hosted network path blocks the metrics rather than the job.

No sensitive data is collected through telemetry, all observability data is encrypted in transit, and none of it is used for training. The full list of what the agent reads is in the observability reference.

What looking costs

Full rates by runner type are on the pricing page.

Related Questions

Does GitHub Actions report CPU and memory for a job on its own?

No. The run page and the metrics GitHub publishes cover run duration, queue time, job counts, and conclusion, and none of them read the machine (GitHub Actions metrics). CPU and memory come from an agent on the runner itself. WarpBuild collects them over OpenTelemetry on port 33931 and draws them against the same job's log timeline in the Usage view. The fleet wide version of that picture is GitHub Actions observability.

Why do the CPU and memory columns show a dash for some of my jobs?

Observability collects metrics and logs only for jobs longer than about 1 minute, so a short job has no series to average. The Jobs report also needs Observability enabled for the runner, and it renders a dash in the CPU and memory columns when telemetry is missing while still reporting run count, success rate, duration, and queue time. The column list is in the reports reference, and the guide to runner level metrics walks the same tables end to end.

What does a memory line flat at the ceiling with idle CPU mean?

The job is bound by RAM and the vCPUs are waiting on it. Sizes in the WarpBuild catalog scale vCPU and RAM together, so the move is one step up the same family: warp-ubuntu-latest-x64-4x at 16 GB to warp-ubuntu-latest-x64-8x at 32 GB, which takes the list price from $0.008 to $0.016 per minute. The other four readings, and the threshold that separates a real ceiling from a busy minute, are in the answer on detecting an undersized runner. The term the thresholds apply to is defined in runner utilization.