Red Squares zeigt GitHub-Ausfälle als Beiträge
(red-squares.cian.lol)- Red Squares parodiert den Commit-Beitragsgraphen von GitHub und zeigt statt grüner Kästchen rote Kästchen, um Ausfälle der Plattform GitHub.com darzustellen
- Jedes rote Kästchen steht für einen Tag, an dem GitHub einen Ausfall hatte; je dunkler die Farbe, desto länger dauerte der Ausfall an diesem Tag
- Im vergangenen Jahr belief sich die gesamte GitHub-Downtime auf 32,5 Tage
- An 167 Tagen gab es mindestens einen Incident
- Der schlimmste Tag war Donnerstag, der 30. April 2026, mit einer Downtime von 1,0 Tagen
1 Kommentare
Hacker-News-Kommentare
Jedes Mal, wenn so eine Vibe-Coding-Meme-Seite auftaucht, folgen endlos Kommentare, dass die eigentliche Ursache nicht die Last sei, sondern dass das GitHub-Team, der Tech-Stack, Microsoft und Azure miserabel seien.
Vergleicht man die öffentliche GitHub-Statusseite mit der Seite für Enterprise Cloud, sind die Werte auf der Enterprise-Seite deutlich besser, und ich persönlich kann mich nicht erinnern, wann es zuletzt einen Ausfall gab, der meine Arbeit wirklich unmöglich gemacht hätte.
Wenn das Problem nichts mit der Last zu tun hat, müsste man dieselben Verfügbarkeitsprobleme auch beim Enterprise-Produkt sehen.
Besonders bei einem Unternehmen mit mehr Ressourcen als viele Länder und einigen der besten technischen Fachkräfte der Welt ist Systemkritik völlig berechtigt.
Der Tech-Stack von GitHub ist tatsächlich nicht gut, und das wird seit Langem ziemlich arrogant verteidigt.
Azure ist eine schreckliche Plattform, die Teams aufgezwungen wird, und ich habe auch bei der Wahl relationaler Datenbanken oder bei Frontend-Rewrites eine defensive Haltung gesehen.
Wenn man nicht einmal die Website stabil am Laufen halten kann, ist es Zeitverschwendung, die UI neu zu schreiben und AI-Tools zu pushen.
Es geht nicht darum, einzelne Engineers anzugreifen, sondern die Entscheidungen des Managements zu kritisieren, bei einem durch Netzwerkeffekte faktisch monopolistischen System neue Features oder die Zufriedenheit des Eigentümers über das Kernprodukt zu stellen.
Da die Statusseite als Beleg gegen das Unternehmen verwendet werden könnte, ist der Vergleich an sich wenig aussagekräftig.
In der Praxis wird ein Ausfall in Marketing-Sprache oft als „Leistungsbeeinträchtigung“ bezeichnet, und unabhängig betriebene Statusseiten sind viel nützlicher.
Nicht jeden Tag, aber ich kann mich kaum an eine Woche erinnern, in der wir bei der Arbeit keinen Workaround für einen Ausfall gebraucht hätten.
In den meisten Fällen kann man zwar weiter „arbeiten“, aber Dinge, die ohne den Ausfall in derselben Zeit gebaut oder ausgerollt worden wären, verzögern sich, daher bin ich persönlich mindestens einmal pro Woche betroffen.
Andernfalls müsste zumindest oben groß stehen: „Nur für Hobbyzwecke verwenden“.
Auf bestehende Threads kann ich antworten, aber keine neuen erstellen, und auf der Statusseite steht es auch.
Ich verstehe nicht, wie so etwas durchgehen konnte, und ebenso wenig, warum es seit einer Stunde andauert.
Dass der Fix noch weitere 3–4 Stunden dauern soll, ist ja wirklich nett.
Selbst Leistungseinbrüche externer Modelle wie Gemini 2.5 Pro, Grok Code Fast 1 in Copilot oder Claude Opus 4 GitHub anzulasten, wirkt nicht fair.
Ich glaube nicht, dass GitHub da überhaupt etwas tun kann.
Die Schwere wird verwischt, und alles wird zu „GitHub-Ausfall“ oder einem Verfügbarkeitsdiagramm zusammengekürzt.
Ich bin unzufrieden mit den jüngsten großen Ausfällen von GitHub, aber es ist unschön, dass immer mehr Aufmerksamkeitsseiten und Social-Posts die Grenze zwischen kleinen Serviceverschlechterungen und einem kompletten Site-Ausfall verwischen, damit alles dramatischer wirkt und Empfehlungen, Likes, Karma und Aufmerksamkeit sammelt.
Es wirkt, als hätte man das Diagramm nur möglichst rot machen wollen.
Wir betreiben einen viel kleineren Dienst als GitHub, haben aber trotzdem Fallback-Pfade über mehrere Anbieter und mehrere Modelle eingerichtet.
Das Wochenende ist noch unerforschtes Frontier-Land.
Da gibt es noch Spielraum zur Skalierung.
Ausfälle betrafen 62 % der Werktage und 11 % der Wochenendtage, und bei Claude war es ähnlich mit 92,5 % werktags und 97,8 % am Wochenende.
Von Dienstag bis Donnerstag ist die Gefahrenzone, und der Sonntag wirkt praktisch wie ein anderer Dienst.
https://www.aakash.io/tech-chase/github-and-claude-are-down-...
Ich frage mich schon, ob dieses Diagramm überhaupt korrekt ist.
Dort steht „170 Tage mit mindestens einem Ausfall · schlechtester Tag Donnerstag, 20. November 2025, 1,1 Tage“, aber ich verstehe nicht, wie die Summe eines Tages 1,1 Tage sein kann.
Selbst wenn man auf das Datum hovert, sieht man nicht, wie intern gerechnet wird, und ein einzelner Eintrag zeigt 1,3 Stunden an.
Für den 19. November steht ein Ausfalleintrag von 1,3 Tagen, aber die Summe wird als 8,1 Stunden angezeigt.
Für dieses Datum zeigt sie 24 Stunden geringfügige Beeinträchtigung an.
Diese Seite scheint die Downtime aller Dienste über einen Tag zu summieren, und dann könnte der schlechteste Tag über die Hauptkategorien hinweg auf 10 Tage Downtime kommen.
1: https://mrshu.github.io/github-statuses/
Ich habe nicht überprüft, ob es an dem Tag wirklich Downtime gab, aber wenn die Zahlen stimmen, ergibt 1 Tag plus 7,8 Stunden ungefähr 1,3 Tage.
Der Unterschied zwischen der offiziellen Statusseite [0] und der Drittanbieter-Statusseite [1] ist viel zu groß.
Wenn das so weit von der realen Produktnutzung entfernt ist, frage ich mich, wie die Klauseln zu Service Level Agreements überhaupt legal sind.
Ich mag GitHub und den Dienst, aber jedes Mal, wenn in Wirklichkeit etwas kaputt ist und die Statusseite grün bleibt, schreit innerlich etwas in mir.
[0] https://www.githubstatus.com/
[1] https://mrshu.github.io/github-statuses/
Bei meinem letzten Arbeitgeber hatten wir viele GitHub-Ausfälle, die nicht auf der Statusseite auftauchten, und wir hatten sie per Slack-Suche protokolliert.
Danach stritten die Business-Leute mit dem Account-Manager von GitHub und bekamen am Ende einige hundert Dollar an Credits.
Aber sie beschwerten sich, dass diese paar hundert Dollar den Aufwand nicht wert seien, und deshalb geht die geringe Verfügbarkeit von GitHub einfach weiter, ohne dass etwas passiert.
Die Drittanbieter-Seite hingegen zählt selbst Ausfälle oder Probleme eines einzelnen Modells als GitHub-Problem, weshalb sie von der tatsächlichen Nutzung abweichen kann.
Am Wochenende gibt es deutlich weniger Ausfälle.
Perfekt, denn dann habe ich ohnehin nicht vor zu arbeiten.
Diese Idee gibt es schon länger.
Ich habe das im Januar gebaut, um die Verfügbarkeit nach Ausfallkategorien aufzuschlüsseln.
https://isgithubcooked.com
Dass es am Wochenende fast keine Downtime gibt, sieht der Contribution Graph ziemlich ähnlich, und das ist irgendwie witzig.