GitHub'daki pull request, Actions ve webhook gecikmelerinin kaynağı event streaming sistemindeki yoğun noktalar oldu

Ne oldu

GitHub, 21 Ekim 2026'da pull request güncellemelerinin, Actions sürekli entegrasyon hizmetinin ve webhook teslimatlarının iki saatten uzun süre gecikmesine yol açan çok hizmetli bir performans sorunu yaşadı. GitHub'ın durum sayfasına göre şirket, kullanıcıların üç hizmette de performans düşüşü bildirmesinin ardından saat 14:52 UTC'de inceleme başlattı. Olay, UTC ile öğleden sonra geç saatlerde ana kullanıcıya yönelik hizmetlerde çözüldü; ancak audit log adlı bir aşağı akış sistemi hâlâ birikmiş işleri işliyordu.

Event hattındaki darboğaz

GitHub'ın güncellemelerine göre sorunun kaynağı tek bir ürün değil, ürünlerin altındaki altyapıydı. Şirket, saat 15:36 UTC'de event streaming platformundaki ek yükün yoğun noktalar oluşturduğunu, trafiği en çok etkilenen bölgelerden uzaklaştırdığını ve ek işleme kapasitesi devreye aldığını duyurdu.

Bu açıklamanın önemi şurada: pull request etkinlikleri, Actions iş akışı durum değişiklikleri ve webhook teslimatlarının tamamı aynı event altyapısını kullanıyor. Paylaşılan bir katmandaki darboğaz, kullanıcının bakışıyla ilgisiz görünen birçok üründe aynı anda gecikme olarak ortaya çıktı.

Olay nasıl gelişti

Actions, saat 15:15 UTC'de açıkça bozuk olarak işaretlendi; 21 dakika sonra streaming platformuyla ilgili kök neden açıklaması geldi. GitHub, saat 15:58 UTC'de platformun toparlanma belirtileri gösterdiğini, ancak müşterilerin hâlâ etkileri hissettiğini bildirdi.

Saat 16:17 UTC ve tekrar 16:25 UTC'de GitHub, event işleme geri dönerken pull request güncellemelerinin ve webhook teslimatlarının toparlandığını, iki şeyin ise geride kaldığını duyurdu: en fazla 100 dakika geciken audit log eventleri ve Actions iş akışı durum güncellemeleri. Pull requestler saat 16:33 UTC'de tamamen çalışır durumda ilan edildi.

Bir dakika sonra gelen güncelleme karışık bir tablo çizdi: diğer hizmetler iyileşirken audit log gecikmeleri yaklaşık 110 dakikaya çıkmıştı ve webhook teslimatları hâlâ birikmiş işleri işliyordu. Actions ve webhooks saat 16:57 UTC'de normal olarak işaretlendi; şirket, saat 16:59 UTC'de kuyruğu işlerken audit log eventlerinin hâlâ yaklaşık 100 dakika geride olduğunu bildirdi.

Toparlanmanın kuyruğu

Saat 17:09 UTC'de yayımlanan son güncelleme, pull request güncellemelerinin, Actions'ın ve webhook teslimatlarının tamamının toparlandığını doğruladı. Audit log eventleri hâlâ yetişiyordu ve GitHub, kalan birikimin yaklaşık iki-üç saat daha süreceğini tahmin ettiğini belirtti.

İlk inceleme duyurusundan itibaren sayıldığında, kullanıcıya yönelik kesinti iki saati biraz aşan bir süre sürdü. Audit loga bel bağlayanlar — genellikle güvenlik ve uyum ekipleri — için ise fiili gecikme bu pencerenin çok ötesine uzandı.

Neden önemli

GitHub, yazılım endüstrisinin büyük bir kısmı için paylaşılan altyapı işlevi gördüğünden, küçük gecikmeler bile hızla yayılır. Yavaş pull request güncellemeleri inceleme ve birleştirme döngülerini durdurur; geciken Actions durum güncellemeleri ekipleri bir derlemenin gerçekten başarılı olup olmadığından emin olamaz hale getirir; geç webhook teslimatları ise deploy tetikleyicilerinden issue takipçilerine ve sohbet bildirimlerine kadar depo eventlerine bağlı tüm aşağı akış otomasyonlarını sessizce yavaşlatır.

Olay ayrıca event odaklı mimarilerin ürünleri birbirine nasıl bağladığının yararlı bir örneği. Tek bir streaming platformunda yoğun noktaların oluşması en az dört sistemi aynı anda bozmaya yetti; benzer hatlar tasarlanırken — ve durum sayfaları okunurken, çünkü "toparlandı" görünen hizmetler hâlâ birikmiş işleri boşaltıyor olabilir — bunu hatırlamaya değer. GitHub webhooklarının tüketicileri, işleyicilerinin bu tür olaylardan sonra geç, sırasız veya yinelenen teslimatlara dayanabildiğinden emin olmak isteyebilir.

Son olarak, audit log gecikmesi başlı başına dikkat edilmeyi hak ediyor. Güvenlik izleme için audit eventleri üzerinden uyarı kuran kuruluşlar fiilen iki saate yaklaşan bir kör pencere yaşadı ve daha sonra bir zaman çizelgesini yeniden oluşturan herkes, kayıtlı zaman damgalarının eylemlerin gerçekte gerçekleştiği anı değil işleme gecikmelerini yansıtabileceğini akılda tutmalı.