GPU Cloud Availability Index — September 2026 (methodology 1.1)

Methodology and limitations

Measure. Reliability is available duration divided by duration with a known signal. limited and unavailable count as known but not available. unknown is missing data and is excluded, never converted to zero.

Intervals. Availability history is change-deduplicated with daily heartbeat records. A stored signal applies until the next record, but for this index it is capped at 30 hours; a longer gap becomes unknown. Results pool configuration-hours across every tracked region for the same provider, GPU and GPU count.

Scope. A configuration (provider, instance type and region) counts for the month only if the provider offered it then: it appeared in the price catalogue at least once in or after the period, or its stock signal was available or limited at least once inside it. A listing that was neither priced nor in stock all month is treated as retired and excluded, not scored as zero. Some catalogues list a region only while it has capacity, so a region with no stock for the entire month is excluded on the same rule; scores therefore describe the places a provider sold from during the month.

Coverage. Rows need at least 48 known hours and 50% of expected configuration-hours to receive a reliability percentage or enter a ranking. Coverage of 80% or more is labelled complete; 50–79.99% is partial. Short-retention providers can therefore appear as insufficient rather than as a misleading zero.

Current availability. The frozen current status uses the best fresh configuration signal. Signals older than six hours are stale. available and limited are provider-reported observations, not reservations or launch guarantees.

Samples. Observation count is the number of stored changes or heartbeats, not the reliability denominator. Coverage hours are the denominator. Providers expose different scopes and region detail, so cross-provider rankings should be read with the coverage fields.