App platform data health.

Prices being checked

6 of 10 audited prices matched the provider's page, week of 26 Oct; 3 could not be read.

A price that moves 30% or more, or would reach a top three, waits for a second reading at least 12 hours later and is checked against the provider's own page, and so is one that fails a check or that a reader reports. Meanwhile the plan shows its last confirmed price and leads no list. Today 1 differs from the provider's page.

How the numbers are protected

• Only fetched numbers. An adapter throws on anything it does not recognise, and nothing is typed in by hand.
• A broken read is refused. A fetch whose plan count falls below half the last one, or whose median paid monthly price moves more than 2.5 times either way, is rejected and the previous reading kept, so a half-broken parser cannot publish nonsense. Free tiers are left out of that median: a section whose cheapest rows are zero would have a median of zero on a small platform, and the ratio test would mean nothing.
• A changed price waits. A move of 30% or more, or into a top three, shows once a second reading agrees.
• Nothing is derived that nobody published. Two platforms publish no price per gigabyte of transfer at all, one because it meters in its own credits and one because its transfer is included in a flat rate. Dividing a plan price by its allowance would produce a figure that reads like theirs and is ours, so both stay blank.
• One number, whatever the plan. Every price is a month in the provider's own currency converted to dollars. The median paid instance today is $49/mo.
• History on the published number. A currency moving is not a price change.

what moved this week · every platform