# GPU Idle Reports: Separate Waiting, Outages and Reservations

Classify GPU time as external work, ready waiting, owner reservation, maintenance or unavailability before explaining idle time.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-idle-report-state-taxonomy/
Language: en

A GPU idle report should separate waiting for work from owner reservations, maintenance and genuine unavailability. Low GPU utilisation alone cannot identify which of those states applied. Start with a non-overlapping timeline, then explain causes with supporting observations.

This produces a useful operating record without treating every unused hour as lost revenue. Offered availability and actual commercial work remain separate measures.

## Define mutually exclusive states

Choose definitions that fit the resource and reporting period. For example, ready means the required environment and access were available for the agreed task. An owner reservation means external work was not intended, even if the machine was technically healthy.

The following invented day illustrates the classification:

| State | Duration | Meaning |
| --- | --- | --- |
| External work | 8 hours | A defined workload ran |
| Ready without a task | 10 hours | Resource was available |
| Owner reservation | 2 hours | Outside work was excluded |
| Maintenance | 2 hours | Agreed changes were performed |
| Unavailable | 2 hours | Required resource was not ready |

The total is 24 hours because the example's intervals do not overlap. Real reports need that reconciliation before percentages are calculated.

## Combine different observations

NVIDIA DCGM health monitoring and vLLM serving metrics describe different parts of the system. Hardware observations can help investigate a device problem; application metrics can describe request activity. Neither should automatically replace the owner's schedule or maintenance record.

Record the time zone and measurement interval for each source. A short sample showing no GPU work does not establish an entire hour of unavailability. Similarly, a healthy device does not prove that the API or network was ready.

## Keep causes separate from conclusions

Write the observed event first: no queued request, connection failure or a scheduled reservation. Add the confirmed cause when evidence supports it. If the cause remains uncertain, preserve that uncertainty rather than guessing about market demand or a hardware defect.

For overlapping events, apply the agreed classification rule once. Do not count the same interval under maintenance and outage and then report both as separate lost capacity.

## Use the report to improve operation

Reconcile the period total, explain missing intervals and identify a specific improvement. That might be a clearer reservation calendar, a missing application check or a revised support contact. The action should follow the evidence rather than a target utilisation percentage.

A realistic history of waiting, reservations and interruptions helps define a pilot more clearly than one average utilisation figure.

Continue with [Calculate the Cost of Making Your GPU Available](/journal/gpu-availability-cost-per-hour/) and [Keep a Network Outage Log for a GPU Node](/journal/gpu-owner-network-outage-log/).

## Official references

- [NVIDIA — health monitoring](https://docs.nvidia.com/datacenter/dcgm/latest/learn/modules/health-monitoring.html)
- [vLLM — metrics](https://docs.vllm.ai/en/latest/usage/metrics/)