ComputeRadar methodology

1. Source data

ComputeRadar uses documented provider APIs wherever available. Each provider is handled by a server-side adapter. API secrets remain on the server and are never shipped to the browser.

2. Common schema

Provider-specific fields are mapped into a common offer model: seller, provider offer ID, compute type, CPU, physical core/thread count or vCPU allocation, RAM, GPU, GPU count, VRAM, storage, location, network, hourly/monthly price, currency, availability, quantity, provider URL and timestamp.

3. Missing data is left missing

If the upstream response does not expose a CPU model, VRAM amount or network speed, ComputeRadar displays “not reported” instead of filling the gap with a guessed specification. A small number of deterministic naming conventions may be decoded when the provider itself documents them.

4. Hourly and monthly normalization

When only hourly or monthly pricing exists, ComputeRadar may derive the other figure using 730 hours per month for comparison. This is an estimate, not a promise of provider billing. Taxes, setup fees, commitments, storage, CPU/RAM add-ons and traffic can change final cost.

5. Availability

Availability reflects the most recent upstream API response. “Available” is not a reservation. Inventory can disappear before checkout, so the provider page is the final source of truth.

6. Sorting and comparisons

The default catalog sort uses listed hourly price when available. Workload pages apply visible hardware constraints; they are discovery tools rather than benchmark rankings.

7. Corrections

Provider APIs change. If a source changes shape, ComputeRadar reports the connector error rather than silently replacing live data with fabricated values. The source status rail exposes this state.