CloudCostCompare
FR

Cette page n’est pas encore disponible en Français, le texte ci-dessous est donc en anglais. Ouvrir la page en anglais

Guides

How prices are collected, checked and refreshed each week

Par Rohit Athaide · Publié le 3 nov. 2026

A price site is only useful if you can tell how old its numbers are and where they came from. This guide describes what happens behind the pages, so you know how far to trust them.

Sources

Prices come from each vendor’s own public price source, not from third-party aggregators.

Cloud Source
Azure The Retail Prices API
AWS The Price List bulk files
Google Cloud The Cloud Billing Catalog API, which needs a free API key
Oracle Cloud Oracle’s public product price list

AI model prices come from two public price feeds, cross-checked against each other, with the vendor’s own page as the source of truth. Exchange rates come from the European Central Bank’s daily rates. The data status page lists the sources and links to each vendor’s documentation.

A weekly cycle

A scheduled job runs once a week, early on Monday in India. In order:

  1. Fetch. It reads the vendors’ price lists. AWS files can be hundreds of megabytes, so they are streamed and reduced as they arrive.
  2. Match. Each price is matched to a named meter in the service map, which records the exact vendor SKU, unit and conversion for each line. A match that finds nothing, finds several, or finds a changed unit is flagged.
  3. Check. A gate compares the new data with what is published. A refresh is held back if a single price moves too far, if too many price lines disappear, if an exchange rate jumps, or if an example total moves more than expected. Held refreshes open an issue listing the rows, and nothing is published until someone reads it.
  4. Record changes. Differences from last week go into the change log and a short news post.
  5. Propose. The result is opened as a pull request, reviewed by a person, and published when it is merged.

When something fails

  • A price that cannot be refreshed keeps its last good value, marked as carried forward, and is reported in an issue. The price data page lists any.
  • A price that was never fetched shows as unavailable, never as zero.
  • A failed download leaves the previous catalog files in place, and the failure is reported. Nothing partial is written.
  • A refresh that trips the checks does not publish unless a person approves it, and the approval is recorded.

The catalog

The catalog has its own step in the same job. Each shard of the catalog is replaced only if the new list passes the same limits as the rest of the data, and a failed shard keeps the old one. Changes between weeks are recorded on the change log. The first time a category is read there is nothing to compare with, so it adds no entries.

Where to see freshness

  • The status page shows when each cloud’s catalog was last read, how many SKUs it holds and what is not in it yet, and marks a cloud out of date after two weeks.
  • Every SKU row and every estimate line carries the date it was read.
  • The JSON API puts an updated_at date on every response. See using the price API.

What the checks cannot do

They catch large, sudden errors. They cannot tell you that a vendor changed what a SKU means without changing its name or unit, or that a price is right for your contract. The vendor’s own price page is the source of truth, and every line links to it.

The rules that turn these prices into a monthly figure are in how we calculate monthly cloud costs, and the catalog itself is explained in how to use the price catalog.