First off: this is a genuinely useful project. Reconstructing GitHub’s historical reliability from the public status feed is valuable, and the methodology here is far more thoughtful than the usual “scrape the status page and average the percentages” approach.
My concern is not with the underlying work, but with how the headline metric is framed.
The current “GitHub platform uptime” figure is easy to read as “how often GitHub is working”, and I have already seen people interpret it that way, e.g.:
“Wait till you find out GitHub’s currently sitting at 87.96% uptime, which is honestly criminal.”
I do not think that is what the data actually shows, but it is a very natural reading of the current presentation.
As I understand it, the headline number is effectively measuring the fraction of time in which all tracked GitHub components were healthy simultaneously — i.e. an AND across component health states.
That is a valid metric, but it is much stricter than what most readers will interpret as “GitHub uptime”.
Mathematically, this behaves like a joint-availability metric:
$$P(\text{all healthy}) = \prod_i P_i$$
This means the number falls as more independently tracked components are included, even if each component is individually highly reliable.
For example, if each component is 99% available:
- 1 component → 99.0%
- 10 components → 90.4%
- 100 components → 36.6%
That does not mean the platform became broadly unusable. It means only that the probability of every tracked subsystem being simultaneously green becomes smaller as the number of independently reported components grows.
This makes the headline number highly sensitive to:
- how finely GitHub splits services on its status page,
- how incidents are attributed to components,
- how many components are counted.
In other words, the same underlying platform can appear much less reliable simply because it is decomposed into more independently reported status components, even if nothing materially changed for users.
That makes this a poor top-line “GitHub uptime” metric, even though it is still a useful metric.
I do not think the aggregate is wrong. I think it is currently labelled too broadly.
What the site appears to be measuring is something closer to:
- all-systems-green uptime,
- joint component availability,
- perfect platform health,
rather than what most readers will interpret as “GitHub uptime”.
Ideally, the top-line number would be closer to the uptime an average user actually experiences. In practice, that is difficult to define because it depends heavily on usage patterns: a team using Git, PRs and Issues experiences a very different “GitHub uptime” from a team heavily dependent on Actions, Packages, Codespaces or Copilot.
That is probably the real reason a single “GitHub uptime” number is so hard to present honestly: the most meaningful version is user- or workflow-weighted, and there is no single weighting that is universally correct.
It's also likely why GitHub moved away from publishing a simple long-term uptime figure in the first place: once the platform becomes broad enough, a single aggregate number is either too coarse to be useful or too easy to misinterpret.
I think this could be made much clearer by:
- renaming the headline metric to better reflect what it is actually measuring,
- making per-service uptime more prominent,
- optionally adding a narrower “core workflow” aggregate (e.g. Git + API + PRs), which is closer to what most users intuitively mean by “GitHub uptime”.
That would preserve the value of the project while making the headline much harder to misread.
First off: this is a genuinely useful project. Reconstructing GitHub’s historical reliability from the public status feed is valuable, and the methodology here is far more thoughtful than the usual “scrape the status page and average the percentages” approach.
My concern is not with the underlying work, but with how the headline metric is framed.
The current “GitHub platform uptime” figure is easy to read as “how often GitHub is working”, and I have already seen people interpret it that way, e.g.:
I do not think that is what the data actually shows, but it is a very natural reading of the current presentation.
As I understand it, the headline number is effectively measuring the fraction of time in which all tracked GitHub components were healthy simultaneously — i.e. an AND across component health states.
That is a valid metric, but it is much stricter than what most readers will interpret as “GitHub uptime”.
Mathematically, this behaves like a joint-availability metric:
This means the number falls as more independently tracked components are included, even if each component is individually highly reliable.
For example, if each component is 99% available:
That does not mean the platform became broadly unusable. It means only that the probability of every tracked subsystem being simultaneously green becomes smaller as the number of independently reported components grows.
This makes the headline number highly sensitive to:
In other words, the same underlying platform can appear much less reliable simply because it is decomposed into more independently reported status components, even if nothing materially changed for users.
That makes this a poor top-line “GitHub uptime” metric, even though it is still a useful metric.
I do not think the aggregate is wrong. I think it is currently labelled too broadly.
What the site appears to be measuring is something closer to:
rather than what most readers will interpret as “GitHub uptime”.
Ideally, the top-line number would be closer to the uptime an average user actually experiences. In practice, that is difficult to define because it depends heavily on usage patterns: a team using Git, PRs and Issues experiences a very different “GitHub uptime” from a team heavily dependent on Actions, Packages, Codespaces or Copilot.
That is probably the real reason a single “GitHub uptime” number is so hard to present honestly: the most meaningful version is user- or workflow-weighted, and there is no single weighting that is universally correct.
It's also likely why GitHub moved away from publishing a simple long-term uptime figure in the first place: once the platform becomes broad enough, a single aggregate number is either too coarse to be useful or too easy to misinterpret.
I think this could be made much clearer by:
That would preserve the value of the project while making the headline much harder to misread.