GitHub Actions'ta kullanılabilirlik bozuldu: hosted runner gecikmeleri CI hatlarını durdurdu

Runner ataması tıkanınca GitHub Actions'ta bozulma

GitHub'ın durum sayfasına göre Actions — şirketin workflow otomasyonu ve sürekli entegrasyon (CI) servisi — 5 Ekim 2026'da, yavaşlayan ve başarısız olan job başlatmaları konusunda yaklaşık doksan dakikalık giderek derinleşen bir incelemenin ardından bozuk kullanılabilirlik durumuna geçti. Olay güncellemelerinde tanımlanan belirti, kuyruktaki job'lara GitHub-hosted runner atanmasındaki gecikme; bu durum workflow başlama sürelerini uzatıyor ve sonraki güncellemelerde doğrudan job hatalarıyla ilişkilendirildi.

Kesinti, UTC ile 21:00'den kısa bir süre sonra Hacker News ana sayfasına ulaşacak kadar ilgi gördü — bu da kaç geliştiricinin etkilendiğinin erken bir sinyali.

Olay nasıl gelişti

Durum sayfasındaki güncellemeler, tablonun yaklaşık bir buçuk saat içinde netleştiğini gösteriyor:

• 19:11 UTC — GitHub, Actions'taki performans bozulması bildirimleri için bir inceleme başlatıyor.
• 19:15 UTC — Şirket, Actions job'larına GitHub-hosted runner atanmasındaki gecikmeleri tespit ediyor ve bazı workflow'lerin farklı runner yapılandırmalarında daha uzun sürede başlayabileceği uyarısında bulunuyor.
• 19:50 UTC — Bir güncelleme, runner atama gecikmelerinin sürdüğünü ve birden fazla runner yapılandırmasında workflow başlama sürelerini etkilediğini, hafletme çalışmalarının devam ettiğini bildiriyor.
• 20:39 UTC — GitHub, runner atama ve workflow başlama sürelerindeki gecikmelere ek olarak job hatalarını da incelediğini açıklıyor.
• 20:47 UTC — Olay resmi olarak bozuk kullanılabilirlik olarak tanımlanıyor ve inceleme sürüyor.

GitHub, olaydan etkilenen tek servisin Actions olduğunu belirtiyor.

Yavaş runner ataması hatlara ne yapıyor

GitHub-hosted runner'lar, Actions'ın her job için talep üzerine sağladığı geçici hesaplama kaynağıdır. Atama katmanı yavaşladığında job'lar mutlaka hemen başarısız olmaz; kuyrukta bekler ve bir hattaki tüm aşağı doğru adımlar onlarla birlikte bekler. Matrix build kullanan depolarda — aynı workflow'ün birçok işletim sistemi, dil sürümü veya yapılandırmaya yayılması — job başına atama gecikmesi tüm matrix boyunca çarpılır; tek bir zamanlama darboğazı bir sürümü uzun süre bekletebilir.

20:39 UTC'de kabul edilen job hataları, en az bazı kullanıcılar için sorunun kuyruk yavaşlığının ötesine geçtiğini düşündürüyor. Durum güncellemeleri kaç job, depo veya kullanıcının etkilendiğini nicelendirmiyor ve ekiplerin etkisini hafletmek için çalıştığına dair genel bir ifadenin ötesinde bir kök neden ya da teknik ayrıntı paylaşılmadı.

Olay sürerken başa çıkma

Durum güncellemeleri özellikle GitHub-hosted runner atamasını adlandırıyor; bu, GitHub'ın kendisinin sağladığı servis katmanı. Self-hosted runner çalıştıran ekipler bu sağlama yolunu atlıyor, ancak olay sayfası self-hosted kurulumların bir etkiden etkilenip etkilenmediğini ayrıştırmıyor. Hosted runner'lara bağımlı depolar için sağlayıcı tarafındaki bir olay sırasında seçenekler sınırlı: kuyruğun geçmesini beklemek, kullanılabilirlik düzeldiğinde başarısız job'ları yeniden denemek ve bir sonraki planlı güncelleme için GitHub durum sayfasını izlemek.

Neden önemli

GitHub Actions, açık kaynak proje CI'sinden kurumsal sürüm hatlarına kadar modern yazılım teslimatının büyük bir bölümünün altında yatıyor. Tek bir zamanlama bileşenindeki — hosted runner atamasındaki — bir bozulma, kullanıcıların kendi tarafında düzeltebileceği hiçbir şey olmaksızın çok sayıda depoda build'leri aynı anda yavaşlatmaya veya engellemeye yeter.

Olay ayrıca CI'daki yoğunlaşma riskini hatırlatıyor. Tek bir sağlayıcının runner filosi bu kadar çok proje için varsayılan olduğunda, kullanılabilirliği daha geniş yazılım ekosistemi için bir bağımlılık haline geliyor. Sorunun tırmanma hızı da dikkat çekiyor: performans bozulmasının ilk bildiriminden olayın doğrulanmış job hatalarıyla birlikte bozuk kullanılabilirlik olarak sınıflandırılmasına kadar yaklaşık 96 dakika geçti. Düzeldikten sonraki soru, bu ölçekte runner atamasında neyin bozulduğu ve GitHub'ın tek bir zamanlama darboğazının global olarak build'leri durdurmasını yeniden önleyip önleyemeyeceği olacak.