GitHub kesintilerini katkı olarak gösteren Red Squares

• Red Squares, GitHub'ın commit katkı grafiğinin bir parodisi olarak, yeşil kutular yerine GitHub.com platformundaki kesintileri kırmızı kutularla gösteriyor
• Her kırmızı kutu, GitHub'ın kesinti yaşadığı bir günü ifade ediyor; renk koyulaştıkça kesintinin daha uzun sürdüğü günleri gösteriyor
• Son 1 yılda GitHub'ın toplam kesinti süresi 32,5 gün olarak hesaplandı
• En az 1 incident yaşanan gün sayısı 167 gün
• En kötü gün, kesintinin 1,0 güne ulaştığı 30 Nisan 2026 Perşembe oldu

---

GitHub kesintilerine katkı grafiğiyle taşlama

[GN⁺]

Hacker News yorumları

• Bu tür vibe coding meme siteleri her ortaya çıktığında, asıl sebebin yük değil de GitHub ekibinin, teknoloji yığınının, Microsoft'un ve Azure'un berbat olması olduğuna dair bitmek bilmeyen yorumlar geliyor
  GitHub'ın herkese açık durum sayfası ile Enterprise Cloud sayfasını karşılaştırınca Enterprise tarafındaki rakamların çok daha iyi olduğu görülüyor; ayrıca şahsen işi yapamayacak kadar büyük bir kesintiyi en son ne zaman yaşadığımı hatırlamıyorum
  Sorun yükten bağımsızsa, Enterprise ürününde de aynı çalışma süresi sorunlarının görünmesi gerekir diye düşünüyorum

  • Bir hizmeti düzgün verememeyi eleştirmek, bireysel mühendisi suçlamak değil, sistemin başarısızlığını eleştirmektir
    Hele ki birçok ülkeden daha fazla kaynağa ve dünyanın en iyi teknik yeteneklerinden bazılarına sahip bir şirkette, sistemi eleştirmek gayet mümkündür
    GitHub'ın teknoloji yığını gerçekten iyi değil ve bunu uzun süre oldukça kibirli biçimde savundu
    Azure korkunç bir platform ve ekiplere zorla dayatılıyor; ilişkisel veritabanı seçimi ya da frontend'in yeniden yazımı konusunda da savunmacı tavırlar gördüm
    Siteyi istikrarlı biçimde ayakta tutamazken UI'ı yeniden yazmak ve AI araçlarını itmek zaman kaybı
    Burada bireysel mühendisler hedef alınmıyor; ağ etkisiyle fiilî tekele dönüşmüş bir sistemde çekirdek ürün yerine yeni özellikleri ya da sahibini memnun etmeyi önceleyen yönetim tercihleri eleştiriliyor
  • Resmî durum sayfasının hizmet seviyesi sözleşmesi nedeniyle gerçek kesinti süresini olduğu gibi yansıtmadığı yaygın olarak biliniyor
    Durum sayfası şirket aleyhine kanıt olarak kullanılabileceği için, bu karşılaştırmanın pek anlamı yok
    Gerçekte kesinti olan şeylere pazarlama diliyle sık sık “performans düşüşü” deniyor; bağımsız işletilen durum sayfaları çok daha faydalı
  • Görünüşe göre farklı alanlarda çalışıyoruz
    Her gün olmasa da, işte bir haftayı kesintiyi dolanmadan geçirdiğimi neredeyse hiç hatırlamıyorum
    Çoğu durumda “iş” devam edebiliyor, ama kesinti olmasaydı aynı sürede build edilecek ya da deploy edilecek işler geciktiği için şahsen en az haftada bir kez etkileniyorum
  • GitHub küçük bir dükkân değil; 3 trilyon dolarlık bir şirket ise bu yükü kaldırabilmeli
    Ya da en azından üstte büyük bir “yalnızca hobi amaçlı kullanım” uyarısı koymalı
  • İronik biçimde tam şu anda kurum içinde GitHub'daki bir bug yüzünden PR'da yeni thread oluşturulamıyor
    Mevcut thread'lere yanıt verilebiliyor ama yenisi açılamıyor ve bu durum sayfasında da yer alıyor
    Bunun nasıl production'a çıktığını anlamıyorum; neden bir saattir sürdüğünü de anlamak zor
    Üstelik düzeltmenin 3-4 saat daha süreceğini söylemeleri ne kadar nazik

• Harici modellerdeki performans düşüşünü bile, örneğin Copilot içindeki Gemini 2.5 Pro, Grok Code Fast 1, Claude Opus 4'ü GitHub'ın suçuymuş gibi göstermek bana adil gelmiyor
  GitHub'ın yapabileceği bir şey olmayan sorunlar gibi duruyor

  • Son dönemdeki örüntü, tek tek servislerdeki küçük performans düşüşlerini toplayıp hepsini aynı derecede önemliymiş gibi göstermek
    Ciddiyet derecesi silinip her şey “GitHub kesintisi” ya da çalışma süresi grafiğine indirgeniyor
    GitHub'ın son büyük kesintilerinden memnun değilim, ama küçük servis düşüşleriyle tüm site kesintisi arasındaki sınırı bulanıklaştırıp daha dramatik göstermek için öneri, beğeni, karma ve ilgi toplayan ilgi çekme amaçlı siteler ve sosyal gönderilerin artması hoş değil
  • Hyperscaler tarafındaki performans düşüşünü github.com erişilebilirliğiyle birleştirmek pek ilginç değil
    Sanki grafiği olabildiğince kırmızı yapmak istemişler gibi görünüyor
  • GitHub başka servisleri yeniden paketleyip sunuyorsa, GitHub'ı suçlamakta sorun görmüyorum
    Biz GitHub'dan çok daha küçük bir hizmet işletiyoruz ama birden fazla sağlayıcı ve birden fazla model üzerinden yedek yol hazırladık
  • Bu, modeli kimin host ettiğine bağlı

• Hafta sonu hâlâ fethedilmemiş bir frontier
  Hâlâ ölçeklenebilecek alan var

  • Geçen ay analiz ettiğimde GitHub'ın hafta içi çalışma süresi %89,3, hafta sonu ise %96,5 idi
    Kesintiler hafta içinin %62'sine, hafta sonunun %11'ine yayılmıştı; Claude da benzer şekilde hafta içi %92,5, hafta sonu %97,8 idi
    Salı ile Perşembe arası tehlike bölgesi; Pazar ise adeta farklı bir hizmet gibi görünüyor
    https://www.aakash.io/tech-chase/github-and-claude-are-down-...
  • O hâlde en büyük sebep change işlemleri mi?
  • 996 çalışma düzeni başlayana kadar beklemek yeterli

• Önce bu grafiğin doğru olup olmadığından şüpheliyim
  “En az bir kesinti görülen 170 gün · en kötü gün 20 Kasım 2025 Perşembe, 1.1 gün” deniyor ama bir günün toplamının nasıl 1,1 gün olabildiğini anlamıyorum
  O tarihin üstüne gelince içeride nasıl hesaplandığı görünmüyor ve tekil öğe 1,3 saat olarak çıkıyor
  19 Kasım 2025'te 1,3 günlük bir kesinti öğesi var ama toplam 8,1 saat olarak gösteriliyor

  • Eksik durum sayfası [1], sistemin herhangi bir bileşeni çöktüğünde bunu kesinti sayıyor; toplam çalışma süresini çakışmayan zamanlar üzerinden hesaplıyor ve en az bir bireysel kesintiyle çakışan zamanı çifte sayımı önlemek için toplam kesinti olarak alıyor
    O tarihte 24 saatlik hafif bir kesinti olarak işaretlenmiş
    Bu site gün boyunca tüm servislerin kesinti sürelerini topluyor gibi görünüyor; öyleyse en kötü gün, ana kategoriler bazında toplanınca 10 güne kadar kesinti gösterebilir
    1: https://mrshu.github.io/github-statuses/
  • “1,3 günün 1,0 günü” diye bir öğe görünüyor; önceki gün olan 19 Kasım 2025 Çarşamba üzerine gelince de “1,3 günün 7,8 saati” görünüyor
    O gün gerçekten kesinti olup olmadığını doğrulamadım ama sayıların doğru olduğunu varsayarsak, 7,8 saate 1 gün eklendiğinde yaklaşık 1,3 gün ediyor

• Resmî durum sayfası [0] ile üçüncü taraf durum sayfası [1] arasındaki fark fazla büyük
  Gerçek ürün kullanım durumu bundan bu kadar farklıysa, hizmet seviyesi sözleşmesi şartlarının nasıl yasal olduğu merak konusu
  GitHub'ı ve hizmeti seviyorum ama ürün fiilen bozukken durum sayfası yeşil gösterdiğinde içimde bir şeyler çığlık atıyor
  [0] https://www.githubstatus.com/
  [1] https://mrshu.github.io/github-statuses/

  • Bu şartların yasal olmasının sebebi, hizmet seviyesi sözleşmesine göre erişilebilirliği izlemek ve ihlal olursa kredi talep etmekle yükümlü tarafın müşteri olması
    En son çalıştığım yerde durum sayfasına girmeyen çok sayıda GitHub kesintisi yaşadık ve bunları Slack aramasıyla kayda geçirdim
    Sonrasında iş tarafındaki kişiler GitHub hesap yöneticisiyle tartıştı ve birkaç yüz dolarlık kredi aldılar
    Ama verilen birkaç yüz dolarlık kredinin harcanan zamana değmediğinden şikâyet ettiler; böylece GitHub'ın düşük çalışma süresi sürüyor ve hiçbir şey olmuyor
  • İlginç şekilde, dün sorun çıktığında bir iş arkadaşım mrshu sayfasını linkledi ama resmî sayfa Actions sorununu gösterirken o sayfa tamamen yeşildi
  • Hizmet seviyesi sözleşmesi büyük ihtimalle GitHub'ın bazı işlevlerini kapsam dışında bırakıyordur
    Buna karşılık üçüncü taraf sayfa, tek bir modeldeki kesinti ya da sorunu bile GitHub sorunu saydığı için gerçek kullanım deneyiminden sapabilir

• Hafta sonlarında kesinti çok daha az
  Zaten o zaman çalışmayı düşünmediğim için mükemmel

• Bu fikir eskiden de vardı
  Ocak ayında kesinti kategorilerine göre çalışma süresini ayırmaya çalışmak için bunu yapmıştım
  https://isgithubcooked.com

  • “Billing” tamamen yeşil, “Pull Requests” ise tamamen kırmızı

• Hafta sonlarında neredeyse hiç kesinti olmamasının katkı grafiğine epey benzemesi komik