Just adding up the numbers is 487 minutes out of 43200 minutes in June, or 98.87% uptime. The number of minutes an issue was being tracked on our status site i

Just adding up the numbers is 487 minutes out of 43200 minutes in June, or 98.87% uptime. The number of minutes an issue was being tracked on our status site is not the same as the number of minutes things were actually broken. Also, very few incidents affect all apps at any point. And when things are being fixed it's typical to see a long tail, especially for database failures with corrupt volumes. I'm not sure if this was calculated the new way to be more accurate or to avoid the psychologically bad "one nine of uptime". This is the same way we've always done it, but we never explained it before this month. We also couldn't find any other providers explaining how they calculate aggregate availability, so we thought it was worth explaining. The is the most realistic method we're aware of for a distributed platform with millions of apps and non-total failure modes.