Where GitHub Actually Went Down

Familiar situation: you try to push code or check actions, and get silence or a 500 error in response. You head to the official status page, and everything's glowing green, saying "All Systems Operational". Only half an hour or an hour later does a modest banner about an incident appear.

I've always found it amusing how major platforms know how to "smooth out" uptime statistics. If you trust the official reports, GitHub is almost always available at 99.9%. But developers who use the service every day know: reality is much more prosaic. The github-statuses project is an attempt to set the historical record straight and show how availability really looked for the main code forge.

What This Project Is About

The repository author decided not to take pretty graphs at face value and created the "missing status page". It's an archive that collects data from GitHub's Atom feeds and reconstructs the real chronology of incidents.

The project is interesting because it doesn't just mirror the current state—it stores history. If GitHub deletes an old incident or adjusts its start time (which happens), this repository keeps the original trace. The project has already been noticed by major tech publications like The Register and popular bloggers like Fireship and PrimeTime. It seems the "falling GitHub" topic has been a sore point for many.

How It Works Under the Hood

The foundation is the Flat Data concept. Data is fetched from an external source, processed, and saved directly to the repository as simple text files (JSON, CSV).

An interesting detail: sometimes GitHub "forgets" to specify which components were affected in an incident description. To solve this problem, the author hooked up GLiNER2—a small named entity recognition (NER) model. It analyzes the message text and determines what's being discussed: Actions, Copilot, or API issues.

The tech stack looks like this:

• Python 3.11–3.13 for extraction scripts.
• uv as the package manager (the author strongly recommends it, and I agree—it works lightning fast).
• GitHub Actions for automating data collection.
• A simple static HTML/JS website that visualizes the collected data.

What You Can Extract from the Data

If you clone the repository, the parsed/ folder already contains ready-to-use data. But if you want to play with it yourself, the scripts allow you to:

1. Export all incidents for a specific period in JSONL format.
2. Enrich the data with impact level information—for this, the script goes and parses the specific incident pages.
3. Generate a CSV with downtime windows, which you can easily drop into Excel or Grafana to build your own charts.

Running all of this requires just a couple of commands:

uv venv --python 3.13
uv sync
uv run python scripts/extract_incidents.py --out my_data --enrich-impact

Why This Is Useful for Developers

At first glance, it seems like just a "wall of shame". But the project has quite practical applications.

First, it's a great example of working with unstructured data. Take a look at how the author implemented an ML fallback mechanism when regular HTML parsing fails. In the code, you can see how to configure confidence thresholds for the model and how to filter out false positives.

Second, if you work at a company where GitHub dependency is critical (for example, deploying through Actions every 5 minutes), this data can help justify to the business the need to implement self-hosted runners or a backup airfield on GitLab/Bitbucket. Numbers from an independent source are always more convincing than "well, I think it goes down often".

How to View the Results

The best part is that you don't need to configure anything to view the charts. The repository has a site/ folder. You can simply run a local server:

python -m http.server 8000

And open http://localhost:8000/site/. You'll see timelines, uptime percentages for specific services (Actions, Pages, Copilot), and a detailed breakdown by day.

The github-statuses project isn't just a bug archive. It's a good example of how with Python, a couple of ML libraries, and GitHub Actions, you can create a transparent monitoring system where official sources prefer to stay quiet.

Who should check out the repository:

• Those interested in open data collection and analysis (Open Data).
• Developers who want to try out the uv library in a real project.
• SRE engineers for assessing risks of using cloud services.

The project is alive, data is updated regularly, and the code is written cleanly enough to figure out in an evening. You can even try adapting these scripts to monitor other services that matter to you.