GitHub: Git işlemlerinde kesinti

• 18 Kasım 2025'te (UTC) GitHub'da tüm Git işlemlerinin başarısız olması sorunu yaşandı; SSH·HTTP istemcileri ve ham dosya erişimi kesintiye uğradı
• Sorunun nedeninin, dahili servisler arası iletişimde kullanılan TLS sertifikasının süresinin dolması olduğu doğrulandı
• GitHub, süresi dolan sertifikayı değiştirip etkilenen servisleri yeniden başlatarak tam normalleşmeyi sağladı
• Ardından sertifika süresi dolumu izleme uyarılarını güçlendirme ve manuel yönetilen sertifikaları kaldırmak için otomasyona geçiş çalışmaları yürütüyor
• Bu kesinti GitHub'ın Git Operations ve Codespaces hizmetlerini etkiledi; kurtarma sonrasında tüm servisler normal duruma döndü

---

Git işlemleri kesinti raporu

• 18 Kasım 2025 20:30~21:34 UTC arasında GitHub'da tüm Git işlemleri başarısız oldu

  • SSH ve HTTP Git istemci etkileşimleri ile ham dosya erişiminin tamamı etkilendi
  • Git işlemlerine bağlı ürünler de aynı şekilde kesinti yaşadı

• Nedenin, dahili servisler arası iletişimde kullanılan süresi dolmuş TLS sertifikası olduğu belirlendi

  • GitHub, sertifikayı değiştirip etkilenen servisleri yeniden başlatarak sorunu çözdü
  • Servisler yeniden başlatıldıktan sonra tam kurtarma sağlandı

• GitHub, gelecekte aynı sorunun yaşanmasını önlemek için sertifika süresi dolumu uyarı sistemini güçlendiriyor

  • İlgili alanlardaki diğer sertifikalar için de izleme ve otomasyon kontrolleri yürütülüyor
  • Kalan manuel yönetilen sertifikaların kaldırılması ve otomatik servisler arası iletişim yapısının kurulması hızlandırılıyor

Kesintinin ilerleyişi ve kurtarma aşamaları

• 20:39 UTC: Git işlemleri ve Codespaces'te erişilebilirlikte düşüş bildirildi
• 20:52 UTC: Bazı Git HTTP işlemlerinde başarısızlık doğrulandı
• 21:11 UTC: Tüm Git işlemlerinin başarısız olduğu doğrulandı
• 21:25 UTC: Codespaces'te erişilebilirlik düşüşü devam etti
• 21:27 UTC: Kök neden belirlendi, düzeltme çalışması başlatıldı
• 21:36 UTC: Düzeltme dağıtımının ardından kısmi toparlanma başladı
• 21:55 UTC: Tüm servisler normale döndü, Codespaces kurtarıldı
• 21:56 UTC: Git işlemlerinin normal çalıştığı doğrulandı
• 21:59 UTC: Olay kapatıldı ve rapor yayımlandı

Etkilenen servisler

• Git Operations
  • SSH ve HTTP tabanlı Git işlemlerinin geneli
• Codespaces
  • Geçici erişilebilirlik düşüşü yaşandı

Sonraki adımlar

• Sertifika süresi dolumu izleme ve otomasyonun güçlendirilmesi
  • Süre dolmadan önce uyarı veren alarm yapısının oluşturulması
  • Tüm dahili sertifikaların otomatik yenileme süreçlerinin gözden geçirilmesi
• Güvenlik ve operasyon otomasyonunun genişletilmesi
  • Manuel sertifika yönetiminin kaldırılması
  • Güncel güvenlik uygulamalarıyla uyumlu otomatik servisler arası iletişimin kurulması

[GN⁺]

Hacker News yorumları

• Son zamanlarda büyük yazılım sistemi kesintilerinin fazla sık yaşanıyor gibi görünmesi endişe verici
  Geçen yıl işi etkileyen sadece dört kesinti olmuştu, bu çeyrekte ise bu şimdiden dördüncüsü
  Ağ yazılımlarındaki dayanıklılık (resiliency) giderek ortadan kalkıyormuş gibi hissettiriyor
  Bizim ekip monolitik bir yapıda ama Redis, S3, harici entegrasyon servisleri gibi çok sayıda bağımlılığı var
  Bu yüzden kesinti koşullarını dokümante etmek, test ve dağıtım otomasyonunu güçlendirmek ve bulut yerine VPS'e taşınmak gibi sadeleştirmeler yaptık
  Sonuç olarak sistem çok daha kararlı ve öngörülebilir hale geldi
  Böyle sıkıcı ama zorunlu işler yapılmasaydı sadece karmaşıklık artar ve sistem daha kırılgan olurdu
  Son dönemde yaşadığımız kesintiler AWS us-east-1, Azure Front Door, Cloudflare ve GitHub kesintileriydi

  • Sonuçta sorunun para olduğunu düşünüyorum
    Müşteriler dayanıklılığa ya da yedekli altyapıya para harcamak istemiyor
    2008'den beri 10'dan fazla projede çalıştım ama çoğunda yaklaşım “şansa bırakalım gitsin” oldu
  • Katılıyorum. Maliyet kısmak sonunda “kesinti geldiğinde ayakta kalabilen sistem kurmayı unutmak” gibi bir sonuca yol açıyor
  • Kasıtlı olarak biraz kışkırtıcı konuşursam, LLM kullanımındaki artışın da bu duruma katkıda bulunduğunu düşünüyorum

• Git bir dağıtık sürüm kontrol sistemi, yani GitHub olmasa da çalışmak mümkün
  GitHub sadece kullanışlı bir merkez

  • Ama GitHub Actions'a tamamen bağımlı bir şirketseniz şu anda gerçekten tamamen tıkanmış durumdasınız
  • Bu biraz “Bu yürüyen merdiven geçici olarak merdivene dönüşmüştür. Verdiğimiz rahatsızlıktan dolayı özür dileriz” durumu gibi
  • Sorunun özü GitHub'ın çökmesi, git'in kendisinin çökmesi değil
  • GitHub olmadan başkalarıyla iş birliği merkezi işlevini kaybediyorsunuz
  • Şu anda Hacker News'te olmamızın sebebi, çalışamıyor olmamız

• GitHub'ın güvenilirlik eksikliği ciddi görünüyor
  CI/CD'ye bağımlı olanlar için ölümcül
  İçeride bu durum sadece “bizim ekibin CI/CD'si bozuldu” seviyesinde algılanıyor, “dünyanın yarısı durdu” perspektifi eksik
  Bu silo kültürü ve “bizim sorunumuz değil” tavrı güvenilirliğin düşmesine yol açıyor
  Üstelik tekel benzeri konumu sayesinde müşteriler de mecburen katlanıyor
  Eskiden Verio ve Verisign'da gördüğümüz “nasıl olsa başka yere gidemezsin” tavrıyla aynı

• Bugünlerde bulut/SaaS kesintileri gerçekten daha sık mı yaşanıyor diye merak ediyorum
  Sadece daha çok haber oluyor da olabilir, gerçekten sıklık artmış da olabilir
  Acaba sebep bütçe kesintileri, işten çıkarmalar, yapay zeka kullanımı ya da aşırı büyüme mi?

  • Microsoft sanki GitHub'ı Azure'a taşırsa bunun çözüleceğine inanıyor gibi
  • Uzun süredir kullanan biri olarak kesinti sıklığındaki artışı kesinlikle hissediyorum
    Eskiden yılda bir iki kez olurdu, şimdi neredeyse her ay, son dönemde ise her hafta seviyesinde
  • Birisi Cloudflare kesintisi sırasında “AI destekli kodlama kültürü”nün bu sorunları büyüttüğünü söylemişti
    Küçük AI kod parçaları domino etkili kesintilere yol açabiliyor olabilir
  • Techrights yazısında belirtildiği gibi,
    büyük çaplı işten çıkarmaların güvenilirlikteki düşüşü etkilediğini düşünüyorum
  • Yapay zekâ kaynaklı FOMO (geri kalma korkusu) yüzünden proje takvimleri daha da sıkışıyor,
    bunun sonucunda da istikrar için gereken son %10'luk çalışma göz ardı ediliyor gibi

• Push atılamayınca önce sorunun bende olduğunu sandım
  Bugünlük bırakıp yarın tekrar denemeye karar verdim

  • Kimlik doğrulama çalışıyor ama push olmuyordu; gerçekten saç baş yolduran bir deneyimdi
  • SSH anahtarını yeniden eklemek de işe yaramadı. Önce garip hatalar çıktı, sonunda “upstream unhealthy” mesajı geldi
  • Ben de neredeyse ortamı sıfırdan yeniden kuracaktım

• Zaten bugün çalışmak istemiyordum; Cloudflare'den sonra GitHub'ın da patlaması, sanki biraz dinlenmem gerektiğine dair bir işaret gibi

  • ABD merkezli merkezileşmiş teknoloji bağımlılığı sorunlu
    Daha fazla teknolojik egemenlik ve dağıtıklık gerekiyor

• Son 5 yılda kullandığım servisler arasında GitHub en istikrarsız olanıydı
  GitLab daha mı iyi diye merak ediyorum. Artık GitHub'a güvenim neredeyse sıfır

  • Şirketimiz GitLab'ı self-hosted kullanıyor ama Gitaly sunucusu sık sık çöküyor
    Muhtemelen büyük mono repo ortamı yüzünden ama ölçeklenebilirlik sorunu olduğu kesin
  • GitLab'ın çok özelliği var ama entegrasyonu dağınık ve genel olgunluğu düşük
    Yine de depo, CI/CD, issue ve wiki'yi tek yerde tutabilmek bir avantaj
  • Hem GitHub.com hem de self-hosted GitLab kullanıyorum;
    GitHub bulut kesintilerine açık, GitLab ise otomatik yükseltmelerin bozulmasına yatkın
    İkisinin de artıları ve eksileri var
  • GitLab'ın sorunu yavaş ve ağır olması
    Birkaç MB'lık JS yüklediği için yavaş ağlarda sayfa neredeyse hiç açılmıyor
  • On-premise çalıştırıldığında istenildiği kadar güvenilirlik sağlamak mümkün

• Acil durumlarda dosyalar GitHub web arayüzünden doğrudan düzenlenebilir
  Ancak GH Actions'taki actions/checkout@v4 şu anda git sorunu yüzünden çalışmıyor

  • Aslında SSH erişimi olan herhangi bir host üzerinden git push/pull yapılabilir
  • Biz de prod hotfix geçiyorduk ama tıkandık. Son zamanlarda internette neler oluyor bilmiyorum
  • CircleCI de GitHub SSH anahtarlarını tanıma sorunu yüzünden git işlemlerinde başarısız oluyor
  • Bu kez GitHub AI'nın githubstatus.com'a bakmamı söylemesi beklenmedik şekilde faydalı oldu
  • GitHub arayüzünden branch oluşturmak mümkün mü diye merak ediyorum

• Son 10 yılda büyük şirketlerle startup'lar arasında gidip gelirken gördüğüm ortak bir örüntü var
  Startup → kurumsal müşteri taleplerine uyum → karmaşık yeniden tasarım → idealizm → kâr odaklılık → ürünün şişmesi → kilit mühendislerin ayrılması → kalite düşüşü
  Bu döngü bulut devlerinde de (AWS, Cloudflare, GCP vb.) tekrar ediyor
  İçeride de her servis küçük bir iş birimi gibi bölünmüş durumda ve kâr odaklı hareket ediyor
  Sonuçta temel altyapı bile kârlılık baskısı yüzünden zayıflıyor
  “AWS ya da GCP çok büyük, nasıl olsa batmaz” inancının tehlikeli olduğunu düşünüyorum

  • Katılıyorum. Kurumsal müşterilere uyum sürecinde ürünün karmaşıklaşıp hantallaşması kaçınılmaz
    Ama erken dönem startup'ların teknik borcu ve güvenlik sorunları da ciddiydi
    Sonuçta büyük ölçekli büyüme sürecinde sistemdeki çatlakların ortaya çıkması doğal

• GitHub durum sayfasında yine “bazı kullanıcılar sorun yaşıyor olabilir” ifadesi çıktı
  Oysa gerçekte sadece HTTPS değil, SSH push da tamamen başarısız durumda

  • Durum sayfasını yönetenler “bazı kullanıcılar” ifadesinin dışına çıkamıyor gibi görünüyor
    PR tarzı yumuşatılmış dil yerine şeffaf bilgi paylaşımı güveni artırırdı
    Üstelik durum sayfası güncellemeleri de çoğu zaman gecikiyor
  • Bir arkadaşım push işleminin kısa süreliğine çalıştığını söyledi ama çoğu kişi hâlâ fatal hata alıyor