github-statuses: reconstructing the status page GitHub never published

A status page reconstructed from the incident feed

github-statuses is described as the missing GitHub status page, a Flat Data attempt at historically documenting GitHub statuses. The about section spells out what it produces: a historical mirror showing actual uptime percentages and incidents across the entire platform, plus per service uptime based on the incident data.

The method is reconstruction rather than scraping. The project rebuilds timelines from the Atom feed history and turns them into structured outputs and a static site. The feed itself is in the repository, as github-status-history.atom, which means the raw input is versioned alongside the code that parses it.

That distinction matters for how you read the numbers. GitHub publishes status updates as a feed of incidents, and this project derives uptime from those updates. A percentage computed from a feed is a reconstruction with the feed's own coverage gaps, and the documentation is careful to present the per service figures as based on the incident data rather than as an official measurement.

The project has found an audience beyond its own repository. The readme lists coverage in The Register of 2026-02-10, which cites the reconstructed page as an unofficial historical source while discussing GitHub's availability, and several video channels that referenced its 90 day uptime and incident counts when discussing outage patterns. For a tool that is mostly a script and a static site, being cited as the historical record is the strongest form of validation available.

The pipeline: feed, extractor, parsed directory, site

The architecture is four stages, and the repository layout maps onto them exactly. There is the Atom feed file at the root, a scripts directory holding the extractor and the experiment runner, a parsed directory holding the structured output, and a site directory holding the static pages that read from it.

The extractor is the core. It parses the incident history and writes structured output, and it takes an output directory, a time window and a set of format and enrichment flags. The output format is JSONL by default, or one file per incident with the split option.

Two enrichment flags matter. The impact enrichment scrapes the incident pages, with the results cached, which is how the severity information is added to a record whose feed entry did not carry it. The component inference flag is the one this project has spent the most effort on, and it is the subject of its own section below.

The output of the extractor is committed to the parsed directory, and the readme is explicit that to view the static site no dependencies are needed, because the parsed directory in the repository contains pre-generated data and you can just serve the repo root with any HTTP server. So the site is a read of committed data, not a query of a live feed.

That is the design of a Flat Data project: the data is extracted on a schedule and frozen into the repository, and everything downstream reads the frozen copy. The automation section says that after each Flat data update, a GitHub Action runs the parser and commits the outputs to the parsed directory.

Running the extractor with uv

The tooling is uv, and the documentation is unusually specific about the Python version, for a good reason.

The extractor depends on onnxruntime, which supports Python 3.11 to 3.13 and not 3.14 or newer, and the readme asks you to check with python --version or python3 --version. If you need a compatible version, uv can install it.

uv python install 3.13

Then the environment is created with that Python and synchronised.

uv venv --python 3.13
uv sync

The readme also covers the failure mode: if uv sync fails with an onnxruntime error, your Python is likely 3.14 or newer, and the fix is to switch to a version in the 3.11 to 3.13 range. That is a specific and useful diagnostic to have in the documentation rather than discovering it from a wheel build error.

With the environment ready, the quick start is two commands.

uv venv
uv sync

And the extractor across all history is one more.

uv run python scripts/extract_incidents.py --out out

The last year is the same command with a window, and the readme gives a UTC example with the since and until flags. Output format is chosen with the incidents format flag, either jsonl or split, and the impact and component inference flags add the enrichment passes.

The GLiNER2 fallback, and what its own evaluation admits

Some incident pages do not list affected components, and for those the project falls back to machine learning.

The mechanism is GLiNER2. The input text is the incident title plus the non-Resolved updates, the labels are the ten GitHub services with short descriptions, the inference is thresholded with a default of 0.75 confidence, and there is a final filter where the label must also appear through explicit service aliases in the text. The design principle is stated clearly: this keeps HTML tags as the source of truth and uses machine learning only to fill gaps.

The project then evaluates its own fallback, which is the part that makes this unusual. An experiment script takes a fixed point in time and produces an audit file with every tagged incident and its text evidence, an evaluation file with metrics and a per label breakdown, and a markdown error analysis with sample errors. The numbers reported as of 2026-01-08, with the alias filter on and non-Resolved text only, are 447 evaluated incidents, 419 predicted non-empty, precision 0.950, recall 0.883, an exact match rate of 0.785, and 51 audited incidents with missing tags.

The per label table is where it gets instructive. Codespaces, Copilot, Pull Requests and Actions score between 0.947 and 0.982 on both measures, while Issues has a precision of 1.000 and a recall of 0.286, which means the fallback finds Issues almost never, and the sample errors show a false negative on an incident whose truth was Git Operations, Visit www and Webhooks.

The summary the project gives is that the fallback is high-precision and mostly conservative, that most errors are false negatives, and that false positives tend to be extra components inferred from multi service incident titles. That is a candid summary, and the sample errors show the same thing in a table with extra and missing components marked.

For a reader deciding whether to trust a per service number, the practical conclusion is that a service with low recall, and Issues is the clear case, will be under-counted rather than over-counted.

Reading the site without installing anything

The static site lives in the site directory and reads data from the parsed directory, with no build step at all. To view it, serve the repository root with any static HTTP server.

python -m http.server 8000
# or: python3 -m http.server 8000

Then you open the site path in your browser. The readme gives the exact URL, which is the site directory under the served root.

This is the part of the project that most people will actually use, and it needs nothing installed. The parsed directory holds pre-generated data committed to the repository, and the site is static files that read it. So a reader who wants to look at the incident history, or at the numbers, can do so with a Python standard library server and nothing else, and the dependency section says exactly that.

The same split applies to the tests, which run through the standard library test runner.

uv run python -m unittest discover -s tests

So the full workflow is: uv and a supported Python for the extractor, and nothing at all for reading what the extractor produced. That separation is what makes the project usable as a reference even by people who have no intention of re-running the extraction.

Where github-statuses is the wrong tool

Four limits, and the first one is about what the numbers can be.

The output is a reconstruction from an Atom feed of status updates, not a measurement of the platform. If the feed is incomplete, truncated, or describes an incident in terms that do not map cleanly onto a service, the derived uptime inherits that. The project is careful about this, describing itself as an attempt and citing its own evaluation, and its mentioned-in list calls it an unofficial historical source. That is the right framing, and it is the framing to keep.

The second is that the per service attribution depends on a machine learning fallback whose measured recall is 0.883 overall and 0.286 for the Issues label. Those are the project's own numbers, published with an error analysis, and they mean that a per service figure for a weakly covered service is systematically low. A report built on the per service numbers needs to carry that caveat.

The third is time. This is a historical record. It says nothing about the current state of the platform, and the readme does not describe any live status check, so it is not a monitoring tool and not a substitute for one.

The fourth is the dependency on the feed continuing. The extractor is fed by a Flat data update, and the raw file is committed to the repository, which is a strength for reproducibility and a limit for currency. If the upstream feed changes shape, the parser has to change with it.

Licence, packaging and the state of the repository

The licence is MIT, with a LICENSE file at the root of the repository, so the data, the scripts and the site can be used, modified and redistributed with the notice kept. This is not legal advice, and a redistributor should check what the upstream status content itself permits, since the code licence and the data licence are not the same thing.

The packaging is worth a look because it explains the Python version constraint. The project metadata declares the name github-statuses, the version 0.1.0, a description of parsing GitHub status history into incident timelines, and a floor of Python 3.11. The dependencies are gliner2 at 1.2.3 or later, and torch pinned to 2.9.1, with a separate CPU build for Linux. The uv configuration sets package to false, because this is an application rather than a library, and it points the Linux torch dependency at a dedicated CPU wheel index, which is how the project keeps the download small for the common case.

On maintenance, the last push was on 2026-10-20 and the repository is not archived, so the work is current, and the repository publishes no GitHub releases, so there is no version history to consult and the version in the metadata is still 0.1.0. The repository also carries a .cache directory and a tagging-experiment directory with the audit and evaluation outputs committed, which means the experiment is reproducible rather than a claim in a blog post.

For a reader, the most useful artefact in the repository is not the site, it is the error analysis file, because it is the part that tells you how far to trust the numbers.

Editorial conclusion

github-statuses is the right tool for a researcher or an engineer who wants to analyse GitHub's availability over time rather than glance at a current status page, and for anyone who needs a per service uptime figure computed from incident data rather than taken on trust. It is the wrong tool if you need the current status, because the input is a historical feed and the output is reconstructed, and it is the wrong tool for a decision that depends on precise per service attribution, because the documented evaluation shows a recall of 0.883 overall and 0.286 for the Issues label. Before using the numbers, read the tagging experiment outputs in tagging-experiment and check which service labels the inference gets wrong for the incidents you care about.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mrshu/github-statuses on GitHub
4. Project website
5. README