Red Squares: A Satirical Look at GitHub Outages as Contributions

GitHub's iconic contribution graph, a grid of green squares marking daily activity, is a familiar sight to developers worldwide. It's a visual testament to consistent effort and engagement. However, a new satirical project, "Red Squares," offers a stark counterpoint: a contribution graph where each red square signifies a day GitHub experienced an outage, with darker shades indicating longer periods of disruption. This clever visualization not only highlights the frequency and duration of GitHub's downtime but also ignites a broader conversation within the developer community about platform reliability, the accuracy of status reporting, and the evolving challenges of maintaining hyperscale services.

The project, created by cianmm, aggregates outage data from mrshu/github-statuses, which in turn reconstructs incident history from githubstatus.com, excluding scheduled maintenance. The initial findings are striking: 35.1 days of GitHub downtime in the last year, spread across 170 days with at least one incident. The worst recorded day saw 1.1 days of disruption on Thursday, November 20, 2025.

The Satirical Visualization: Red Squares Explained

"Red Squares" presents a heatmap where each cell represents a day, mirroring GitHub's own contribution chart. Instead of commits, the intensity of the red color indicates the duration of an outage on that particular day. The darker the red, the longer GitHub was unavailable or degraded. This visual metaphor quickly conveys the extent of the platform's reliability challenges, offering a perspective that many developers find both humorous and concerning.

Data for the visualization is fetched live and relies on a third-party aggregation of GitHub's incident history. The project's creator notes that the heatmap itself is powered by Mantine, a modern React components library.

Key Observations and Patterns in Outage Data

One of the most immediate and frequently discussed patterns observed in the Red Squares graph is the noticeable reduction in outages during weekends.

"Funny how weekends are almost always up!"

"Far fewer outages during the weekends. Perfect, wasn't gonna do any work then anyway."

This observation led to speculation about the underlying causes. Some suggested it could be load-based, with fewer developers actively using the platform during off-peak hours. Others wondered if it correlated with GitHub employee activity, implying that changes or deployments during the work week might contribute to instability.

"double entendre: Is it load based or github-employee based that weekends are sparser. or just a multifactor of both."

While the project states 35.1 days of downtime over 170 incident days, some users questioned the precise calculation of downtime durations, noting discrepancies when hovering over specific days versus the aggregated totals. For instance, a day might show a 1.3-hour incident but contribute to a larger daily total, leading to calls for more transparency in the math behind the scenes.

Community Reactions and Insights

The Red Squares project resonated strongly with the developer community, drawing praise for its creativity and poignant irony.

"This is one of the most creative idea I've seen this year. Tasteful and clever. Bravo!"

"This design is perfect irony. I love it."

Beyond appreciation for the concept, the discussion delved into several critical aspects of GitHub's operations and the broader software development ecosystem.

Data Accuracy and Official vs. Third-Party Status

A significant point of contention was the perceived discrepancy between GitHub's official status page (githubstatus.com) and the data aggregated by third-party services like mrshu/github-statuses.

"Contrast between official [0] and third party status pages [1] is huge. How their terms of service for SLA are legal if they are so different from real world usage of their product? I really like GitHub and their services but every time when it's broken and their status page is green something screams inside me."

This raises questions about how incidents are categorized, reported, and whether the official status accurately reflects the user experience of degraded performance or partial outages.

The Role of AI and External Dependencies

Several comments highlighted the increasing integration of AI services, particularly GitHub Copilot, and their potential impact on overall platform stability. Some incidents listed in the underlying data refer to disruptions with AI models like Gemini 2.5 Pro or Grok Code Fast 1 in Copilot.

"It doesn't seem fair to blame Github for this? There's nothing they can do about it?"

This sparked a debate on whether GitHub should be held accountable for outages stemming from third-party AI dependencies, or if these should be viewed as separate issues. The sentiment was that the rise of AI coding tools might be contributing to the complexity and fragility of the system.

"Guess where AI Coding entered the picture"

Underlying Causes and Hyperscale Challenges

Many users expressed bewilderment at the scale of outages for a company like GitHub, which is owned by Microsoft and operates on Azure infrastructure.

"I don't really understand why this is happening at this scale, it's not like they just became broke and can't afford a proper server... can someone explain?"

Some speculated that the issues might be tied to Azure incidents, while others pointed to the inherent challenges of operating a "hyperscaler" service.

"I wonder how well this corolates with azure incidents. Especially for the US regions."

One perspective suggested that public GitHub's issues might be load-related, contrasting it with the seemingly better uptime of GitHub Enterprise Cloud, which serves a different user base and scale.

"Just compare the GitHub status page for public GitHub vs the enterprise cloud pages. Enterprise has much better numbers and I've personally can't remember the last time there was an outage that prevented me from doing work. If the problems didn't revolve around load, I'd expect to see the same uptime problems reflected on the enterprise offering."

Alternatives and Self-Hosting

The recurring outages also reignited discussions about the merits of self-hosting Git repositories and exploring alternative platforms.

"Another reminder that a self hosted git repository would have more uptime than GitHub and centralizing everything to GitHub was a very bad idea."

Users mentioned successful migrations to self-hosted solutions like Forgejo and pondered comparisons with other platforms such as GitLab, BitBucket, and Codeberg.

Design and Usability Feedback

Beyond the technical and operational discussions, the project's minimalist design received positive feedback, particularly for its clarity and lack of "overused AI-generated animations."

"This site is very readable, very honest and sober. I don't need to sift through buzzwords to figure out tiny details. Thank you, OP!"

However, a suggestion was made to improve accessibility for colorblind users by making more intense outage days brighter rather than darker red.

Conclusion

"Red Squares" serves as a powerful, albeit satirical, commentary on the state of GitHub's reliability. By reframing outages as a form of "contribution," it effectively visualizes the impact of downtime on the developer community. The project has sparked important conversations about data transparency, the complexities of managing hyperscale infrastructure, the influence of integrated AI services, and the ongoing debate between centralized platforms and self-hosted alternatives. As development workflows become increasingly reliant on services like GitHub, the demand for consistent uptime and clear communication during incidents remains paramount.