GitHub'da Issues, Actions ve Git işlemleriyle ilgili kesinti yaşandı

 (githubstatus.com)
1 puan yazan GN⁺ 2026-02-10 | 1 yorum | WhatsApp'ta paylaş
  • GitHub'un Actions, Issues ve Git işlemleri gibi temel hizmetlerinde performans düşüşü ve hatalar bildirildi
  • Etki alanı Webhooks, Pull Requests, Packages, Pages, Codespaces gibi hizmetlere de yayıldı
  • GitHub, hafifletme önlemleri (mitigation) uygulayarak kademeli toparlanma gözlemledi ve ardından tüm hizmetler normale döndü
  • Kesinti, Dependabot ve Copilot gibi bazı hizmetleri de etkiledi ancak sonunda hepsi normal işlem durumuna geri döndü
  • GitHub, kök neden analizi (RCA) raporunu daha sonra yayımlayacağını ve kullanıcılara sabırları ile işbirlikleri için teşekkür ettiğini belirtti

Kesintinin özeti

  • GitHub, Actions, Git Operations ve Issues hizmetlerinde bildirilen performans düşüşünü araştırdığını açıkladı
    • İlk aşamada yavaş yanıtlar ve başarısız istekler ile geciken Actions işleri gözlemlendi
    • Kesinti ilk olarak 9 Şubat 2026 19:01 UTC'de bildirildi

Etkilenen hizmetler

  • Etkilenen bileşenler Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces oldu
    • Daha sonra Dependabot ve Copilot tarafında da sorunlar doğrulandı
    • Her hizmet “degraded performance” durumunda işaretlendi

Müdahale ve toparlanma süreci

  • GitHub, hafifletme önlemleri uyguladıktan sonra toparlanma işaretleri gözlemlediğini bildirdi
    • 19:29 UTC sonrasında kademeli iyileşme başladı
    • 19:54 UTC itibarıyla birçok hizmet toparlandı, ancak bazıları hâlâ inceleniyordu
  • 20:08 UTC'de “tüm hizmetler normal şekilde işleniyor” bilgisi paylaşıldı
    • 20:09 UTC'de durum Resolved olarak güncellendi

Nihai durum ve sonraki adımlar

  • GitHub, tüm hizmetlerin normal çalışma durumuna döndüğünü belirtti
    • Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests, Webhooks tamamen normale döndü
  • Kök neden analizi (Root Cause Analysis) hazır olduğunda paylaşılacak
  • Kullanıcılara sabırları ve anlayışları için teşekkür edildi

Özet

  • Bu kesinti, GitHub'un çekirdek geliştirme iş akışının genelini etkileyen bir olay oldu
  • Toparlanma tamamlandıktan sonra RCA yayımlanacak; bunun benzer kesintileri önlemeye yönelik iyileştirmelere yol açması bekleniyor
  • Aynı gün başka bir kesintinin de bildirilmiş olması, istikrar yönetiminin önemini öne çıkardı

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-10
Hacker News yorumları

  • GitHub’daki süregelen kısmi kesintiler yüzünden tüm şirketi başka bir sağlayıcıya taşımayı düşünüyorlar
    Eskiden sorunsuz çalışan özellikler artık yavaş, Actions da zamanında çalışmıyor
    Copilot güzel olsa da, sonuçta git forge düzgün çalışmıyorsa ayrılmaktan başka çare kalmıyor

    • Kesinlikle katılıyorum. Eskiden harikaydı ama artık temel işlevler bile kararsız
      Basit bir PR diff’ini açmak bile 15 saniyeden uzun sürüyor ve arayüz tekrar tekrar donmuş gibi davranıyor
      Bu tür anormal performans düşüşlerinin normal karşılanması şaşırtıcı
    • “Copilot’tan keyif alıyorum” sözü şaka gibi geliyor
    • İronik biçimde Linus Torvalds, git’i merkeziyetsiz bir yapı için tasarlamıştı
      Sonuçta CI pipeline’ını yerelde de çalıştırabilmek git’in özünde var
      Ben GH’yi sadece senkronizasyon için kullanıyorum
    • Eskiden GitHub sık sık postmortem yayımlardı, ama son zamanlarda neredeyse hiç yok
      Eski yazılara bakınca SQL DB’nin ölçekleme sınırlarına dayandıkları görülüyordu
      OpenAI’ın Postgres ölçeklendirme örneği buna benziyor, ama GitHub bunu o kadar iyi yönetememiş gibi görünüyor
    • “Güvenilir bir ürün beklemek fazla iyimserlik” denilerek bunun Microsoft sorunu olduğu söyleniyor

  • GitHub’ın sık yaşanan kesintileri, aslında deployment pipeline dayanıklılığını test etmek için bir fırsat oluyor
    Çoğu ekip GitHub’a tamamen bağımlı olduğu için kesinti olduğunda dağıtım da duruyor
    Bu yüzden şu alternatifleri deniyorlar

    1. Kritik repo’ları GitLab veya Gitea üzerinde mirror etmek
    2. Build başarısızlıklarını önlemek için dependency caching kullanmak
    3. GitHub Actions olmadan elle deployment yapabilmek için bir runbook hazırlamak
      Resmî durum sayfası hep geç güncellendiğinden artık sadece “eventually consistent” bilgi kaynağı olarak görülüyor

  • GitHub, otomatik geliştirme iş akışlarındaki patlama nedeniyle yük altında olabilir
    Kişisel repo’lardaki commit sayısı patladı ama ücretli kullanıma geçiş neredeyse hiç yok

    • Sorunun Microsoft satın alımından sonra başladığı söyleniyor
      2019’da özel repo’ların ücretsiz olmasıyla gelir fırsatının kaçırıldığı düşünülüyor
    • Aslında sık kesintilerin nedeni AWS’den Azure’a geçiş olabilir
      Ayrıca downtime konusunda yeterli sorumluluk hissi de yok
    • Sonuçta mesele ölçekleme sınırına dayanmış olmak
    • AI ile kod üretimi repo, commit ve veri setlerinde patlamaya yol açıyor
    • Bu durum “AI Agent patlamasıyla yaşa, AI Agent çöküşüyle öl” diye özetleniyor

  • GitLab’ın bir alternatif olduğu savunuluyor
    GitHub artık sadece AI merkezli stratejiye odaklanıyor, platformun kendisi geri planda kalıyor
    Copilot benimsenme oranı da düşük, şirketler daha çok Claude kullanıyor
    Microsoft yön değiştirirse durum daha da kötüleşebilir

    • Copilot’un kendi modeli olup olmadığı soruluyor
    • Ama GitLab da kusursuz değil
      Özellikler yarım yamalak durumda yayımlanıyor ve hızı da yavaş
      Open-core modelinin avantajları da artık eskisi kadar belirgin değil
    • GitLab da AI odaklı hâle geliyor
      Dev → DevOps → DevSecOps → AI DevSecOps diye evrilmiş olsa da
      Her aşamada olgunluk eksik kalıyor ve lisans yükseltmesi zorunluluğu rahatsız ediyor

  • CI/CD ile kod barındırmayı tek bir yapıda birleştirmek başlı başına sorun olarak görülüyor
    Kusursuz çalışsa bile sonunda vendor lock-in kaçınılmaz oluyor
    Eskiden sadece remote’u değiştirmek yeterliydi, şimdi ise PR, wiki gibi şeylerle her yere bağlanmış durumda

    • Hatta bunun hata değil, bilinçli bir kilitleme stratejisi olduğu düşünülüyor
    • forgejo gibi açık kaynak çözümlerle bağımsız bir CI sistemi kullanmanın daha iyi olduğu söyleniyor

  • Artık GitHub kesintileri basit bir SaaS sorunu değil, bulut düzeyinde bir arıza gibi hissettiriyor
    Bu yüzden birçok ekip self-hosted GitLab/Gitea tarafına geçiyor

    • İki startup’ta GitLab’ı başarıyla kullanmışlar
      Büyük bir şirkette güvenlik nedeniyle on-premise GitLab Enterprise kullanılmış,
      kişisel projelerde ise Forgejo tercih ediliyor
      Git, issue, board, wiki hepsi iyi çalışıyor ve scoped label ücretsiz
    • Self-hosted Gitea da iyi bir seçenek. Yeter ki yedeklemeler düzgün yönetilsin
    • GitLab’ın tam sürümünü self-hosted kullanmak, maliyetine göre kesinlikle değer
    • GitLab’ı self-hosted kullanmaktan açıkça memnun olduklarını söylüyorlar

  • GitHub’ın çoklu kesinti geçmişini görselleştiren bir sayfa var
    mrshu.github.io/github-statuses adresinden görülebiliyor

    • updog.ai/status/github da Datadog verilerine dayanıyor
    • Ama güncellemeler durmuş gibi görünüyor (son kayıt 6 Şubat)

  • “GitHub ekibi, ağırdan alabilirsiniz” diye şaka yollu bir yorum da var

  • GitHub’dan ayrılmak istiyorlar ama istikrarlı bir CI ve container registry gerekli
    “Sadece düzgün çalışan” bir çözümse bunun için para ödemeye hazırlar

    • Forgejo + Firecracker VM tabanlı CI sunan Lithus.eu öneriliyor
      Büyük ölçekli iş yükleri için uygun ama başlangıç maliyeti yüksek
    • GitLab CI sade ama güçlü
      Registry yetki yönetimi biraz karmaşık olsa da genel entegrasyon iyi
    • Repo’nun gerçekten CI’dan sorumlu olması gerekip gerekmediği sorgulanıyor
      Unix felsefesinde olduğu gibi tek amaçlı araçlara dönülmesi gerektiği düşünülüyor
    • nix-ci.com önerenler de var
    • CircleCI de hâlâ çalışan bir alternatif olarak anılıyor

  • AI benimsenme oranı ile kesinti sıklığı arasındaki korelasyonu grafikle görmek ilginç olurdu

    • Elbette bunun yanında etkili olan başka faktörler de vardır