A site tracks GitHub's incidents and asks: is the platform "cooked"?

A site called IsGitHubCooked has become a topic of discussion among developers for doing something simple and uncomfortable: aggregating GitHub's public incident history and allowing filtering by service and severity. The page hit the top of Hacker News and reignited the conversation about the platform's reliability at a time when most Brazilian teams run build, deploy, and code review directly on top of it.

This framing matters because, as the author himself explains on the page, "everybody's reliability narrative is a function of the services they depend on and the 9's they expect." Someone who only uses git push experiences one reality; someone who depends on GitHub Actions for deployment experiences a very different one.

What the numbers show

According to the site, GitHub has accumulated 1,128 incidents since March 2016. Over the past three months, the average was 24 incidents per month (a 5% drop from the previous quarter). The longest streak without incidents was just 8 days, ending on December 31, 2025, and the worst month on record was February 2026, with 37 incidents.

The most relevant data for those building software is availability by service over the past three months. The services that most impact delivery pipelines appear at the bottom of the list:

| Service | Uptime (3 months) | Downtime | |---|---|---| | Copilot | 97.93% | 7d 13h | | Actions | 98.20% | 6d 14h | | Pull Requests | 98.58% | 5d 4h | | Search | 99.11% | 3d 5h | | Webhooks | 99.40% | 2d 4h | | Git Operations | 99.49% | 1d 20h | | Repositories | 99.916% | 7h 24m |

On the other end, Dashboard, Discussions, Docs, and Mobile posted 100% availability during the period. The difference between a git clone (Git Operations, 99.49%) and a deployment pipeline dependent on Actions (98.20%) is exactly what the site's filter tries to make explicit.

As for severity, of the catalogued incidents, 81% were Minor, 16% Major, and just 3% Critical (29 in total). The worst day by count was February 9, 2026, with 7 incidents; the worst by downtime duration was April 16, 2025, with 1 day and 2 hours of downtime.

Why this matters for the workflow of teams in Brazil

The history also includes a breakdown by day of the week: Wednesday (22%), Tuesday (21%), and Thursday (19%) account for most incidents, compared to 4% on Saturday and 2% on Sunday. The obvious reading is that problems concentrate during business hours and high-traffic periods, exactly when teams are pushing code.

For Brazilian developers, the time zone amplifies the problem. GitHub's peak activity window coincides with morning and early afternoon in Brazil, when many local teams are at their peak of commits and deploys. An unstable Actions during that window means stalled builds, blocked releases, and stuck PR reviews right in the middle of the workday. It's worth checking whether critical pipelines have a contingency plan (self-hosted runner, repository mirror, or manual deploy capability) for the moments when Actions goes down.

The caveat about "average uptime"

The number the site displays is an average over the entire period, and the community was quick to point out that this can mask the real experience. In the Hacker News thread, user kevmo raises the central point:

"An important thing to consider is how much of their uptime without incidents is not the normal working hours. Their incident-free uptime on 9-5 EST, Mon-Fri, is probably like 60%."

>

-- kevmo

In other words: 98.20% uptime, adding up overnight hours and weekends, doesn't describe what a team feels on a Wednesday afternoon. Another comment, from bushbaba, was more direct in joking that it "could have been a page with a static 'Yes' and a significant portion of time it'd be accurate."

There were also those who demanded rigor from the site's own numbers. User JeremyHerrman pointed out an arithmetic inconsistency in the description: "1125 incidents / 126 months ≈ 8.9 incidents per month, not 24." The 24 average refers to recent months, not the entire history, which reinforces the importance of checking the time frame before drawing conclusions.

The context: migration to Azure and the AI era

Part of the discussion links recent instability to GitHub's infrastructure migration to Azure and the volume generated by the adoption of AI tools. The most upvoted comment along these lines calls for moderation in the criticism:

"You could justify the jabs when we could all blame any outage on the migration to Azure, but then they shared numbers around the scale they're dealing with now that everyone is constantly building and pushing with AI."

>

-- kashnote

On the other side of the spectrum, user rvz used the case to reaffirm an old criticism of centralization: "they were cooked the moment they got acquired by Microsoft," arguing that concentrating an entire ecosystem on a single platform has always been risky.

What remains open

IsGitHubCooked isn't an official source: it consumes the platform's own public status history and reorganizes it. The numbers are useful as a gauge, but they depend on how each incident was classified and on the time period chosen in the filter. The tool's practical value lies less in the verdict ("cooked" or not) and more in letting each team measure the reliability of the services it actually uses, rather than arguing based on a generic average. For those who depend on Actions or Copilot day to day, the data is a concrete reminder that pipeline redundancy isn't a luxury.