Red Squares: GitHub Outages Visualized as Contribution Commits

Every GitHub outage could appear as a red square on your contribution graph. That's the idea behind Red Squares. It scrapes GitHub's status page and plots downtime data into a familiar heatmap of squares—green for commits, red for outages. The result is a documentation project that doubles as a joke.

How Red Squares Visualizes GitHub Outages and Went Viral

The tool, built by a solo developer, pulls data from GitHub's Status API and renders each incident as a red square on a calendar heatmap. If a day had any downtime, it gets a red square; the shade of red indicates severity. The original Hacker News post quickly gained traction for its creativity. One commenter called it "one of the most creative ideas this year," while another highlighted a humorous data point: "For 30th April 2026 it shows it was down 1.0 days of 2.6 days (minor incident)."

The Accuracy Debate

Not everyone was sold. A commenter pointed out a discrepancy: "Across 170 days with at least one incident — worst day Thu, Nov 20, 2025 (1.1 days) ... 1.1 days total how is that possible?" A day cannot have more than 24 hours of downtime. The tool may be summing durations incorrectly, perhaps double-counting overlapping incidents or mixing hours and days. This sparked a discussion about data aggregation and visualization accuracy.

What I Think

Red Squares repurposes a familiar visual metaphor to make infrastructure glitches feel personal. Your contributions represent your work; outages show the platform's failures. That emotional hook is why it resonated. But the accuracy concerns matter. If you use a quantitative visualization, the math must be correct. The developer could improve it by showing raw incident data alongside the aggregate. Still, the inaccuracies don't kill the idea. Red Squares is more art project than reliability dashboard—a memento of imperfection, not an SRE tool.

Lessons for Builders

This project demonstrates a few things:

• Data as humor: Turning dry status pages into something playful humanizes infrastructure. Consider adding whimsy to operational dashboards.
• Visualization pitfalls: Aggregating data introduces misrepresentation risk. Always validate your math, especially when mapping continuous incidents onto discrete days. Can a single day show more than 24 hours of downtime?
• API scraping: The tool uses GitHub's public status API. Here's a minimal snippet to fetch and process incident data:

import requests
from datetime import datetime, timezone

response = requests.get('https://www.githubstatus.com/api/v2/incidents/unresolved.json')
response.raise_for_status()

def parse_status_time(value):
    return datetime.fromisoformat(value.replace('Z', '+00:00'))

data = response.json()
now = datetime.now(timezone.utc)
for incident in data['incidents']:
    start = parse_status_time(incident['created_at'])
    resolved_at = incident.get('resolved_at')
    end = parse_status_time(resolved_at) if resolved_at else now
    duration_hours = (end - start).total_seconds() / 3600
    print(f"{incident['name']}: {duration_hours:.1f} hours")

This is simplified; a full tool would handle unresolved and overlapping incidents and cache historical data.

Should You Explore It?

If you build with GitHub or rely on its availability, Red Squares is a fun conversation piece but not a serious monitoring tool. Check it out for the creativity alone. If you're a data visualization enthusiast, take it as a reminder to double-check your aggregations. And if you're tired of seeing green squares everywhere, this will make you smile. Otherwise, your uptime is probably fine.