Circle Ci kesinti geçmişi

1. 21 Ekim 2026 19:31 UTCidentified

   Bazı kullanıcılar kapasite sorunları nedeniyle gen2 Docker işleri için zaman artış görebilirler.

2. 21 Ekim 2026 20:03 UTCidentified

   Sorunu azaltmaya yardımcı olmak için ek kapasite ekliyoruz. Not: Hala 2xlarge'de gecikmeleri görüyoruz.

3. 21 Ekim 2026 20:22 UTCidentified

   2xlarge docker işleri için zaman bekleyiniz. Kapasite online olarak güncellemeye devam edeceğiz.

4. 21 Ekim 2026 20:35 UTCidentified

   2xlarge docker işleri için zaman beklemek artık 60 saniyenin altında. Diğer kaynak boyutları için zaman beklemek bu olay tarafından etkilenmedi ve 10 saniye altında kaldı.

5. 21 Ekim 2026 20:40 UTCmonitoring

   Docker işleri için zaman dolu bir kurtarma gördük.

6. 21 Ekim 2026 20:54 UTCresolved

   Gen2 Docker işleri için zaman beklemek ve işler normal bekleme zamanlarında çalışıyor.

7. 22 Ekim 2026 23:29 UTCpostmortem

   # # # Özet 21 Ekim'de 15:44'den 20:55 UTC'ye kadar, Gen 2 Docker işleri çalışan müşteriler işlerinin başlaması için bekleme süreleri arttı. Gecikmeler en uzun 2xlarge kaynağı sınıfındaydı, işler 20 dakika bekledi. Olay, özellikle 2xlarge işleri için talep etmek için yapılandırdığımız bulut örneklerinin sınırlı erişilebilirliğine neden oldu. Cevap olarak, mühendislik ekibimiz ek örnek tipler yapılandırdı, ek Gen 2 Docker kümeleri yapılandırdı. 20:55 UTC'ye göre, bekleme süreleri normale döndü ve olay çözüldü. Olay çözüldükten sonra, Gen 2 Docker filosunu ek bulut bölgelerine genişlettik ve gelecekte benzer olayları önlemek için aktif olarak ek bulut bölgeleri tuttuk. Orijinal durum sayfası burada bulunabilir: [ 21 Ekim - Artan Docker gen2 bekleme süresi] (https://status.circleci.com/incidents/5jb50gh55gtj) # # # CircleCI bir Docker işi uygularken, birkaç bulut örneği kümesinden birinde programlıyoruz ve her örnek birden çok izole iş yürütebilir. Bir bulut örneği üzerinde bir iş kurmak klasik bir ["bin paketleme sorunu"] (https://en.wikipedia.org/wiki/Bin packing problem): talep edilen kaynak sınıfına uygun kapasite bulmak, hafıza ve depolama. 2xlarge gibi büyük kaynak sınıfları daha sıkı bir araya getiren daha küçük olanlardan daha uygun. Örnek türlerin sıralanmış listesini kullanarak bulut örneklerini veriyoruz. Eğer bulut sağlayıcı ilk seçimimizi tedarik edemezse, listedeki bir sonraki tipe geri dönüyoruz. Daha fazla minimum filo boyutunu koruyoruz: minimum sayıda örnek çalışıyor, bu yüzden talep düşük olduğunda kapasiteden vazgeçmiyoruz. Bu minimum filo boyutunun üstünde, talep artışı olarak örneklerimizi ekliyoruz. Bir iş yükü uygulamak için yetersiz bir kapasite olduğunda, kapasiteye kadar bu işi sıralıyoruz. # # What Happened \(All times UTC\) 21 Ekim'de 15:44'de başlayan Gen 2 2xlarge kaynağı sınıfı için talep keskin bir şekilde yükseldi ve devam etmek için yeterince hızlı bir şekilde ilave kapasite sağlamadık. Mühendislik ekibimiz araştırmaya başladı. 19:25'e kadar Gen 2 2xlarge kaynağı sınıfı için zaman beklemek 20 dakikaya ulaştı ve diğer kaynak sınıfları için zaman beklemek de arttı. 19:56'a kadar, mühendislik ekibimiz Gen 2 filosuna online olarak daha fazla kapasite elde etmek için ek örnek tipler yapılandırmıştı ve 19:59'a göre bu örnek tipleri garanti ettik. 20:11'de, birkaç ek Gen 2 küme ekledik ve bu kümelerdeki minimum filo boyutunu artırdık. 20:35'e kadar, kuyruk işleri sayısı normal seviyelere geri döndü ve 20:41 tarafından, 2xlarge işlerinin% 95'i 4 saniye içinde başlıyordu. Olayı 20:55'de çözdük. Bu olayı çözdükten sonra, Docker işleri için daha fazla kapasite sağlamak için ek bulut bölgeleri ekledik. ## Future Prevention and Process Improvement Daha fazla yerden kaynak kapasitesi de dahil olmak üzere iş başlangıç zamanlarını geliştirmek için aşağıdaki adımları attık ve büyük kaynak sınıfları için daha fazla kapasiteye sahip olduk. **Docker işleri için ek bölgeleri ekledik.** Son zamanlarda Makine işleri için ek bulut bölgeleri ekledik ve şimdi Docker işleri için aynı şeyi yaptık. ** Her iki Docker ve Machine işleri için aktif olarak ek bulut bölgeleri eklemeye devam edeceğiz**. ** ek Gen 2 kümes** ekledik. İşleri daha hızlı bir şekilde planlamak için birkaç ek Gen 2 kümes yapılandırdık ve mevcut daha fazla toplam kapasite yaratmak için. ** Kullandığımız bulut örnek tiplerini genişlettik ve minimum filo boyutumuzu yükselttik. ** Ek örnek tipler yapılandırdık. Ayrıca, mevcut temel talebi karşılamak için Gen 2 için minimum filo boyutunu da artırdık. ** Daha büyük kaynak sınıflarının zamanlamasına öncelik vermek için iş planlayıcımızı değiştirdik. ** İşlerimizi kaynak sınıflarında daha adil bir şekilde dengelemek için nasıl programladığımızı ve mevcut durumlarda bin paket işleri daha verimli hale getirdik. # # # Sonuç Müşteri deneyimi bizim en önemli önceliğimizdir ve müşterilerimizin içimizde yer aldığı güvenle eşleşmesi için sistemlerimizin güvenilirliğini sürekli olarak geliştirmeye çalışıyoruz. Müşterilerimize sabrı için teşekkür ederiz, ekibimiz bu olayı çözmeye çalıştı. Lütfen destek ekibimize herhangi bir soru veya endişelerle ulaşabilirsiniz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 20 Ekim 2026 15:58 UTCinvestigating

   M4pro.large kaynak sınıfı kullanarak bazı Mac işleri için daha fazla bekleme süreleri görüyoruz. Biz araştırıyoruz ve yakında başka bir güncelleme sağlayacaktır. Sabrınız için teşekkür ederiz.

2. 20 Ekim 2026 16:32 UTCmonitoring

   Mac4pro.large kaynak sınıfı üzerinde çalışan müşteriler hala 30 dakikaya kadar beklenen bazı işlerde artış gösteriyor. Bunu izlemeye devam ediyoruz ve kısa bir süre sonra başka bir güncelleme paylaşacağız.

3. 20 Ekim 2026 17:02 UTCmonitoring

   M4pro.large için zamanlar hala ağır büyük talep nedeniyle yüksektir. Tüm m4pro.medium normal. Aktif olarak izliyoruz, sabrı takdir ediyoruz.

4. 20 Ekim 2026 17:31 UTCmonitoring

   M4pro.large kaynak sınıfı üzerinde MacOS işleri için zaman bekleyin. Xcode 27.0 kullanan işler şimdi zirvede yaklaşık -3.5 dakika bekliyor. Xcode 26.6 ve 26.4.1 kullanarak işler hala açık olan bir backlog aracılığıyla çalışıyor. m4pro.medium'da günler normal. İzlemeye devam ettikçe yakında başka bir güncelleme paylaşacağız.

5. 20 Ekim 2026 18:14 UTCresolved

   M4pro.large kaynak sınıfı üzerindeki MacOS işleri için zaman beklemek normale döndü. Geriloglar temizlenirken sabrınız için teşekkür ederiz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 14 Ekim 2026 14:47 UTCinvestigating

   Yaklaşık 14:00 UTC'den bu yana, Xcode 26.6.0'ı M4 Pro büyük kaynak sınıfında kullanan müşteriler, başlangıç işleri deneyimliyor. Bekle süreleri 30 dakika veya daha fazlasına ulaştı. Mühendislerimiz araştırırken sabrınız için teşekkür ederiz. 15:30 UTC tarafından başka bir güncelleme sağlayacağız.

2. 14 Ekim 2026 15:17 UTCidentified

   Xcode 26.6.0 kullanan Mac işlerinin gecikmeleri geri alındı. Yaklaşık 15:11 UTC'den beri, Xcode 26.4 kullanan Mac işleri, yaklaşık 30 dakika beklemekle başlayan gecikmeler yaşıyor. Sabırınız için teşekkür ederiz, mühendisler bunu çözmek için çalışırken. 15:45 UTC tarafından başka bir güncelleme sağlayacağız.

3. 14 Ekim 2026 16:01 UTCresolved

   14 Ekim'de yaklaşık 14:00 UTC ve 15:51 UTC arasında, Xcode 26.6.0 veya Xcode 26.4 deneyimli gecikmeler iş başında. Yaklaşık 14:00 UTC'den itibaren, Xcode 26.6.0'ı M4 Pro büyük kaynak sınıfında kullanan işler, başlamak için 30 dakika veya daha fazla bekledi ve bu gecikmeler yaklaşık 15:12 UTC'de geri döndü. Yaklaşık 15:11 UTC'den, Xcode 26.4 kullanan işler başlamak için yaklaşık 30 dakika bekledi. Sorun çözüldü ve etkilenen tüm işlevsellik normale döndü. Size sabrınız için teşekkür ederiz, ekibimiz bir düzeltme uygulamak için çalıştı.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 9 Ekim 2026 11:33 UTCidentified

   Veri altyapısımızda gecikmelere neden olan gecikmeler var ve bazı bildirimleri görünür hale geliyor. Bir mitigation üzerinde çalışıyoruz.

2. 9 Ekim 2026 13:00 UTCidentified

   Ne etkilendi: Müşteriler boru hatları tetikliyor ve müşterilere bağlı webhooks ve e-posta ve Slack bildirimleri. Ne bekleyebilirsin 11:15 UTC: - Borular hala bu devam ederken oluşturulur, ancak henüz işlenmez, bu yüzden tekrarlama tekrar boru hatlarıyla sonuçlanabilir. - Outbound webhooks ve işlemsel bildirimleri (Slack ve e-posta) gönderilmez. - Boru durumu görünür olmayabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler duracaktır. Sabırınız için teşekkür ederiz, mühendisler bunu çözmek için çalışırken. Sonraki güncelleme: 13:30 UTC tarafından başka bir güncelleme sağlayacağız.

3. 9 Ekim 2026 13:30 UTCidentified

   11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. Ne etkilendi: Müşteriler boru hatları tetikliyor ve müşterilere bağlı webhooks ve e-posta ve Slack bildirimleri. Ne bekleyebilirsin: - 13:00 UTC'den bu yana, boru hatları tekrar işliyor ve işler başlıyor. Çoğu iş şu anda yaklaşık 4 dakika içinde başlıyor ve bazıları yaklaşık 10 dakika bekliyor. Olay sırasında tetiklenen boru hatları hala işleniyor ve başlamak için daha uzun sürebilir. - Outbound webhooks ve bildirimleri yeniden başladı. - Borular hala arkalogtan işleniyor, bu yüzden tekrar tekrarlama tekrar boru hatlarıyla sonuçlanabilir. Sabırınız için teşekkür ederiz, mühendisler bunu çözmek için çalışırken. Sonraki güncelleme: 14:00 UTC tarafından başka bir güncelleme sağlayacağız.

4. 9 Ekim 2026 14:00 UTCidentified

   11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. What's impacted Müşteriler iş akışlarını ve işlerini çalıştırıyor ve müşteriler Project Use sayfasında kullanım verilerini izliyorlar. Ne bekleyebilirsin - Borular olay sırasında tetiklenenler dahil olmak üzere tekrar işleniyor. - Yaklaşık 13:25 UTC'den bu yana, iş akışları ve işler gerilog aracılığıyla çalıştığımız gibi artan gecikmelerle başlıyor. Çoğu iş şu anda yaklaşık 10 dakika içinde başlıyor ve bazıları yaklaşık 25 dakika bekliyor. - Yaklaşık 14:35 UTC tarafından bu backlog aracılığıyla çalışmayı bekliyoruz. - Olay sırasında tetiklenen boru hatlarından iş akışları hala başlamayı bekliyor, bu yüzden retriggering tekrar iş akışlarına neden olabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabırınız için teşekkür ederiz, mühendisler bunu çözmek için çalışırken. Sonraki güncelleme 14:30 UTC tarafından başka bir güncelleme sağlayacağız.

5. 9 Ekim 2026 14:29 UTCidentified

   11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. What's impacted Müşteriler iş akışlarını ve işlerini çalıştırıyor ve müşteriler Project Use sayfasında kullanım verilerini izliyorlar. Ne bekleyebilirsin - İşlere başlayan gecikmeler ve işler gelişiyor. Çoğu iş şimdi yaklaşık 3 dakika içinde başlıyor, 13:50 UTC'de yaklaşık 10 dakika. - Olay sırasında tetiklenen boru hatlarından bazı iş akışları hala başlamak için yaklaşık 40 dakika bekliyor. - Backlog aracılığıyla çalışmak beklenenden biraz daha uzun sürüyor. Şimdi bunu yaklaşık 14:45 UTC ile temizlemek bekliyoruz. - Olay sırasında tetiklenen boru hatlarından iş akışları hala başlamayı bekliyor, bu yüzden retriggering tekrar iş akışlarına neden olabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabırınız için teşekkür ederiz, mühendisler bunu çözmek için çalışırken. Sonraki güncelleme 1 UTC ile başka bir güncelleme sağlayacağız.

6. 9 Ekim 2026 14:43 UTCidentified

   11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. 13:00 UTC ve 14:40 UTC arasında, iş akışları ve işler arkalog aracılığıyla çalışırken gecikmelerle başladı. What's impacted Müşteriler iş akışlarını ve işlerini çalıştırıyor ve müşteriler Project Use sayfasında kullanım verilerini izliyorlar. Ne bekleyebilirsin - Olay sırasında tetiklenen boru hatlarından geri gelen akışlar yaklaşık 14:40 UTC'de silindi. Çoğu iş şimdi yaklaşık 30 saniye içinde başlıyor ve bazıları yaklaşık 3 dakika bekliyor. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabrınız için teşekkür ederiz, mühendislerimiz alt konu üzerinde çalışmaya devam ederken. Sonraki güncelleme 15:10 UTC tarafından başka bir güncelleme sağlayacağız.

7. 9 Ekim 2026 14:54 UTCmonitoring

   11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. 13:00 UTC ve 14:40 UTC arasında, iş akışları ve işler arkalog aracılığıyla çalışırken gecikmelerle başladı. What's impacted Müşteriler iş akışlarını ve işlerini çalıştırıyor ve müşteriler Project Use sayfasında kullanım verilerini izliyorlar. Ne bekleyebilirsin - Olaydan gelen boru hatlarının ve akışların arka isteği temizlendi. - Yaklaşık 14:45 UTC'den bu yana, çoğu iş ve iş yaklaşık 15 saniye içinde başlıyor ve zaman normale dönmeye devam ediyor. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabrınız için teşekkür ederiz, mühendisler iyileşmeyi izlerken. Sonraki güncelleme 15:20 UTC tarafından başka bir güncelleme sağlayacağız.

8. 9 Ekim 2026 15:32 UTCmonitoring

   11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. 13:00 UTC ve 14:40 UTC arasında, iş akışları ve işler arkalog aracılığıyla çalışırken gecikmelerle başladı. What's impacted Müşteriler, CircleCI UI'de boru hatları, akışları ve işleri izliyor ve müşteriler Proje Kullanımı sayfasındaki kullanım verilerini izliyor. Ne bekleyebilirsin - İş akışları ve işler zamanında çalışıyor. - CircleCI UI yaklaşık 30 dakika geride. Yeni iş akışları ve durum değişiklikleri bu kadar uzun sürebilir. - Mühendislerimiz işlem hızlandırmaya aktif olarak çalışıyorlar, böylece UI yakalayabilir. - Lütfen henüz UI'de görünmeyen akışları abartmaktan kaçının, çünkü bu tekrarlar yaratabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabrınız için teşekkür ederiz, mühendisler bu gecikmeyi azaltmak için çalışırken. Sonraki güncelleme 16:00 UTC tarafından başka bir güncelleme sağlayacağız.

9. 9 Ekim 2026 16:02 UTCmonitoring

   11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. 13:00 UTC ve 14:40 UTC arasında, iş akışları ve işler arkalog aracılığıyla çalışırken gecikmelerle başladı. What's impacted Müşteriler iş akışlarını ve işlerini çalıştırıyor, müşteriler boru hatları, iş akışlarını ve işlerini CircleCI UI'de izliyor ve müşteriler Proje Kullanımı sayfasındaki verileri izliyor. Ne bekleyebilirsin - Yaklaşık 15:15 UTC'den bu yana, iş akışları ve işler artan gecikmelerle başlıyor. Çoğu iş şu anda yaklaşık 4 dakika içinde başlıyor ve bazıları yaklaşık 20 dakika bekliyor. - CircleCI UI ortalama 30 dakika geride kalıyor ve bazı güncellemeler daha uzun sürüyor. Yeni iş akışları ve durum değişiklikleri bu kadar uzun sürebilir. - Lütfen henüz UI'de görünmeyen akışları abartmaktan kaçının, çünkü bu tekrarlar yaratabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabrınız için teşekkür ederiz, mühendisler bu gecikmeleri azaltmak için çalışırken. Sonraki güncelleme 16:30 UTC tarafından başka bir güncelleme sağlayacağız.

10. 9 Ekim 2026 16:32 UTCmonitoring

    11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. 13:00 UTC ve 14:40 UTC arasında, iş akışları ve işler arkalog aracılığıyla çalışırken gecikmelerle başladı. Yaklaşık 15:15 UTC'den bu yana, iş akışları ve işler yine gecikmelerle başlıyor. What's impacted Müşteriler iş akışlarını ve işlerini çalıştırıyor, müşteriler boru hatları, iş akışlarını ve işlerini CircleCI UI'de izliyor ve müşteriler Proje Kullanımı sayfasındaki verileri izliyor. Ne bekleyebilirsin - İşlere başlayan gecikmeler gittikçe arttı ve rahatlatmaya başlıyor. Çoğu iş yaklaşık 4 dakika içinde başlıyor ve bazıları yaklaşık 25 dakika bekliyor. - CircleCI UI şimdi yaklaşık 30 dakika geride, yaklaşık 30 dakikadan aşağı. Yeni iş akışları ve durum değişiklikleri bu kadar uzun sürebilir. - Lütfen henüz UI'de görünmeyen akışları abartmaktan kaçının, çünkü bu tekrarlar yaratabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabrınız için teşekkür ederiz, mühendisler bu gecikmeleri azaltmak için çalışırken. Sonraki güncelleme 17:00 UTC tarafından başka bir güncelleme sağlayacağız.

11. 9 Ekim 2026 17:06 UTCmonitoring

    11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. 13:00 UTC ve 14:40 UTC arasında, iş akışları ve işler arkalog aracılığıyla çalışırken gecikmelerle başladı. Yaklaşık 15:15 UTC'den bu yana, iş akışları ve işler yine gecikmelerle başlıyor. What's impacted Müşteriler iş akışlarını ve işlerini çalıştırıyor, müşteriler boru hatları, iş akışlarını ve işlerini CircleCI UI'de izliyor ve müşteriler Proje Kullanımı sayfasındaki verileri izliyor. Ne bekleyebilirsin - İşlere başlayan gecikmeler istikrarlı tutuyor. Çoğu iş yaklaşık 4 dakika içinde başlıyor ve bazıları yaklaşık 25 dakika içinde yaklaşık 8 dakika bekliyor. - CircleCI UI ortalama 20 dakika geride kalıyor ve bazı güncellemeler daha uzun sürüyor. Yeni iş akışları ve durum değişiklikleri bu kadar uzun sürebilir. - Lütfen henüz UI'de görünmeyen akışları abartmaktan kaçının, çünkü bu tekrarlar yaratabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabrınız için teşekkür ederiz, mühendisler bu gecikmeleri azaltmak için çalışırken. Sonraki güncelleme 17:30 UTC tarafından başka bir güncelleme sağlayacağız.

12. 9 Ekim 2026 17:34 UTCidentified

    11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. 13:00 UTC ve 14:40 UTC arasında, iş akışları ve işler arkalog aracılığıyla çalışırken gecikmelerle başladı. Yaklaşık 15:15 UTC'den bu yana, iş akışları ve işler yine gecikmelerle başlıyor. What's impacted Müşteriler boru hatları ve iş akışlarını tetikliyorlar, müşteriler boru hatları, iş akışlarını ve işlerini CircleCI UI'de izliyor ve müşteriler Project Use sayfasındaki verileri izliyorlar. Ne bekleyebilirsin - 17:00 UTC'den bu yana, gecikmeler önemli ölçüde arttı. Çoğu iş şimdi başlamak için yaklaşık 12 dakika sürüyor ve bazıları yaklaşık 30 dakika bekliyor. - 17:15 UTC'den bu yana, bazı işler başlamaz. - Borular daha yavaş işleniyor, bu yüzden bazıları daha uzun sürebilir. - CircleCI UI bir saat geride. Yeni iş akışları ve durum değişiklikleri bu kadar uzun sürebilir. - Lütfen henüz UI'de görünmeyen akışları abartmaktan kaçının, çünkü bu tekrarlar yaratabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Sabırınız için teşekkür ederiz, mühendisler bunu çözmek için çalışırken. Sonraki güncelleme 18:00 UTC tarafından başka bir güncelleme sağlayacağız.

13. 9 Ekim 2026 18:08 UTCidentified

    11:15 UTC'den bu yana, müşteriler boru hatları ve bildirimler için kesinti yaşadılar. 11:15 UTC ve yaklaşık 13:00 UTC arasında, boru hatları oluşturuldu, ancak işlenmedi ve bağlı webhooks ve işlemsel bildirimler (Slack ve e-posta) gönderilmedi. 13:00 UTC ve 14:40 UTC arasında, iş akışları ve işler arkalog aracılığıyla çalışırken gecikmelerle başladı. Yaklaşık 15:15 UTC'den bu yana, iş akışları ve işler yine gecikmelerle başlıyor. What's impacted Müşteriler boru hatları ve iş akışlarını tetikliyorlar, müşteriler boru hatları, iş akışlarını ve işlerini CircleCI UI'de izliyor ve müşteriler Project Use sayfasındaki verileri izliyorlar. Ne bekleyecek - 17:00 UTC'den bu yana, gecikmelerde bir artış görüyoruz. Çoğu iş şimdi başlamak için yaklaşık 25 dakika sürüyor ve bazıları bir saat kadar bekliyor. - Yaklaşık 17:15 UTC'den beri, bazı in-progress akışları başarısız oldu ve küçük sayıda iş başlamaz. - Yeni boru hatları sıralanıyor ve başlamak için daha uzun sürüyor. - CircleCI UI bir saat geride. Yeni iş akışları ve durum değişiklikleri bu kadar uzun sürebilir. - Lütfen henüz UI'de görünmeyen akışları abartmaktan kaçının, çünkü bu tekrarlar yaratabilir. - Proje Kullanımı sayfasındaki ücretsiz veriler şu anda durmaktadır. Mühendislerimiz sorunu el ele almak için çalışmaya devam ediyor. Sonraki güncelleme 18:30 UTC tarafından başka bir güncelleme sağlayacağız.

14. 9 Ekim 2026 18:32 UTCidentified

    Son güncellememizden beri ne değişti * CircleCI UI bir saat geride ve bazı güncellemeler için yaklaşık 90 dakika. İş akışları ve işler zaten çalıştırılabilir veya çalıştırılabilir, UI onları başlamamış veya hepsini göstermezse bile. * Çalışan olan işler daha hızlı başlıyor. Çoğu şimdi yaklaşık 15 dakika içinde başlıyor, yaklaşık 28 dakikadan aşağı, ancak bazıları hala bir saat boyunca bekliyor. * Yeni boru hatları giderek gecikiyor. * Bazı iş akışları hala başarısız. Zaman içinde işlenemez iş akışları başarısız olarak işaretlenir. * Lütfen henüz UI'de görünmeyen iş akışlarından kaçının, çünkü bu tekrarlar yaratabilir. Hala devam ediyor: Proje Kullanımı sayfasındaki ücretsiz veriler durmaktadır. Sonraki güncelleme 19:00 UTC tarafından başka bir güncelleme sağlayacağız.

15. 9 Ekim 2026 18:57 UTCidentified

    Son güncellememizden beri ne değişti * Jobs daha hızlı başlıyor. Çoğu şimdi yaklaşık 8 dakika içinde başlıyor, yaklaşık 15 dakikadan aşağı ve en uzun beklenmişler yaklaşık 45 dakikaya kadar bir saatten fazla düştü. * CircleCI UI yakalamaya başlıyor, ancak hala geride. İş akışları ve işler zaten çalıştırılabilir veya çalıştırılabilir, UI onları başlamamış veya hepsini göstermezse bile. * Borular daha hızlı işleniyor, ancak yeni boru hatları hala gecikiyor. Hala devam eden hala devam ediyor * Bazı iş akışları ve işler hala başarısız. * Lütfen henüz UI'de görünmeyen iş akışlarından kaçının, çünkü bu tekrarlar yaratabilir. * Proje Kullanımı sayfasındaki kullanım ücreti sabittir. Sonraki güncelleme 19:30 UTC tarafından başka bir güncelleme sağlayacağız.

16. 9 Ekim 2026 19:29 UTCidentified

    Son güncellememizden beri, işler daha hızlı başlıyor: çoğu şimdi yaklaşık 8 dakika içinde başlıyor. CircleCI UI yetişiyor ama hala bir saat geride. Yeni boru hatları var olduğu gibi işleniyor. İşler zaten UI henüz göstermiyorsa bile çalıştırılabilir, bu yüzden lütfen UI'de görünmeyen iş akışlarından kaçının. 20:00 UTC tarafından başka bir güncelleme sağlayacağız.

17. 9 Ekim 2026 20:06 UTCidentified

    İşler daha hızlı başlıyor ve daha az başarısız oluyor: çoğu iş şimdi yaklaşık 6 dakika içinde başlıyor ve en uzun bekleyişler yaklaşık 30 dakikadan 20 dakikaya kadar düştü. Olaydaki daha önceki borular şimdi işleniyor. CircleCI UI hala geridedir ve bazı eski güncellemeler daha uzun görünebilir. İşler zaten UI henüz göstermiyorsa bile çalıştırılabilir, bu yüzden lütfen UI'de görünmeyen iş akışlarından kaçının. 20:30 UTC tarafından başka bir güncelleme sağlayacağız.

18. 9 Ekim 2026 21:22 UTCidentified

    Yaklaşık 20 UTC:48'den beri, yeni iş ve işler başlamaz. Geçici olarak yeni çalışmaya başladık, bu yüzden sistemlerimizin zaten ilerlemede, CircleCI UI ve API'ye gecikmiş güncellemeler de dahil olmak üzere çalışmaya devam edebilir. Yaşlı güncellemeler şimdi UI ve API'de bu backlog açıkları olarak ortaya çıkıyor. Yeni boru hatları hala kabul edilir ve kuyruklanmış Lütfen bu süre zarfında boru hatları veya iş akışlarından kaçının, çünkü bu bir kez iş özgeçmişleri oluşturabilir. 22:00 UTC tarafından başka bir güncelleme sağlayacağız.

19. 9 Ekim 2026 22:09 UTCidentified

    Son güncellememizden beri, olayda daha önce gecikmiş olan boru hatlarının çoğu şimdi işlendi ve onların iş akışları başlamak için sıralanıyor. Yeni akışlar ve işler güvenli bir şekilde çalışmaya hazırlanırken duraklanır. Gecikmiş güncellemeler CircleCI UI ve API'de görünmeye devam ediyor. Lütfen boru hatları veya iş akışlarından kaçınmaya devam edin, çünkü bu bir kez iş özgeçmişleri oluşturabilir. 22:30 UTC tarafından başka bir güncelleme sağlayacağız.

20. 9 Ekim 2026 22:28 UTCidentified

    Son güncellememizden bu yana, yavaş yavaş yavaş çalışmaya başladık ve bazı kuyruk akışlar ve işler tekrar başlıyor. Çoğu kuyruklı iş hala bekliyor ve başlangıçtaki işler bir saat boyunca bekleyebilir. Sistemimizi aşırılaştırmaktan kaçınmak için oranı dikkatle artırıyoruz. Gecikmiş güncellemeler CircleCI UI ve API'de görünmeye devam ediyor. Lütfen boru hatları veya iş akışlarından kaçınmaya devam edin, çünkü bu kuyruklı iş özgeçmişleri olarak tekrarlar yaratabilir. 23:00 UTC tarafından başka bir güncelleme sağlayacağız.

21. 9 Ekim 2026 23:00 UTCidentified

    Çok sayıda kuyruklı iş ve iş başladı ve CircleCI UI ve API yakalandı ve normalde birkaç gecikme ile güncelleme gösteriyor. Kalan kuyruk işleriyle çalışmaya devam ediyoruz. kuyruktan gelen işler bir saat veya daha başlamak için bekleyebilir ve bazı Linux işleri kapasite için yaklaşık 10 dakika bekliyor. Lütfen kuyruklı iş işleme devam ederken yeniden beslenmekten kaçınmaya devam edin. 23:30 UTC tarafından başka bir güncelleme sağlayacağız.

22. 9 Ekim 2026 23:38 UTCidentified

    Hala önemli bir kuyruk akışları ve işleri hakkında çalışıyoruz. Bekle süreleri gelişiyor ama normalden daha uzun kalıyorlar ve bazı işler bir saat boyunca beklediler. CircleCI UI ve API bugüne kadar kalıyor. Lütfen arkalog açıkken boru hatları veya iş akışlarından kaçının, çünkü bu tekrarlar yaratabilir. 00:00 UTC tarafından başka bir güncelleme sağlayacağız.

23. 9 Ekim 2026 23:59 UTCidentified

    Son güncellememizden bu yana, kuyruklı akışlar ve işler gerilog yaklaşık 23:47 UTC olarak temizlendi. İş akışları ve işler şimdi saniyeler içinde başlıyor ve CircleCI UI ve API güncel. Sistemlerimizi istikrarlı olduklarından emin olmak için yakından izliyoruz. 00:30 UTC tarafından başka bir güncelleme sağlayacağız.

24. 10 Ekim 2026 00:45 UTCidentified

    İş akışları ve işler normalde başlamaya devam etti, saniyeler içinde ve CircleCI UI ve API bugüne kadar kaldı. Slack ve e-posta bildirimleri daha önce olayda gecikmiştir. Proje Kullanımı sayfasındaki ücretsiz veriler durmaktadır. Sistemlerimizi yakından izlemeye devam ediyoruz ve 01:15 UTC tarafından başka bir güncelleme sağlayacaktır.

25. 10 Ekim 2026 01:23 UTCmonitoring

    İş akışları ve işler normal olarak başlıyor ve çalışıyor ve CircleCI UI ve API güncel. Sistemlerimizi istikrarlı olduklarından emin olmaya devam ediyoruz. 02:00 UTC tarafından başka bir güncelleme sağlayacağız.

26. 10 Ekim 2026 02:08 UTCresolved

    9 Ekim'de 11:15 UTC ve 23:47 UTC arasında, müşteriler boru hatları, iş akışları ve işlerde gecikmeler yaşadılar, CircleCI UI, API ve bildirimler. 11:15'ten yaklaşık 13:00 UTC'ye kadar, boru hatları oluşturuldu, ancak işlenmedi ve webhooks ve Slack ve e-posta bildirimleri gönderilmedi. Yaklaşık 13:00'dan 14:40 UTC'ye kadar, iş akışları ve işler gerilog aracılığıyla çalışırken gecikmelerle başladı. Yaklaşık 15:15'ten 20:48 UTC'ye kadar, iş akışları ve işler bir saat kadar gecikmelerle başladı ve CircleCI UI ve API yaklaşık 2 saate kadar geride kaldı. Bu süre zarfında, bazı işler başlamadı ve bazı in-progress akışları başarısız oldu. 20:48'den yaklaşık 22:10 UTC'ye kadar, geçici olarak yeni akışlar ve işlere başlıyoruz, böylece sistemlerimiz kurtarılabilir. Yeni boru hatları bu süre zarfında kabul edildi ve kuyruklandı. Yaklaşık 22:10'dan 23:47 UTC'ye kadar, kuyruklı akışlar ve işler yeniden başladı ve işlendi. Bazıları yaklaşık 2 saat bekledi. Sorun çözüldü ve etkilenen tüm işlevsellik normale döndü. Proje Kullanımı sayfasındaki ücretsiz veriler henüz güncel değildir ve veri depolarımız tamamlandıktan sonra güncellenecektir. Bu pencere sırasında başarısız olan müşteriler etkilenen işleri geri alabilir. Sizin sabrınız için teşekkür ederiz, mühendislerimiz bir düzeltme uygulamakta çalışırken.

27. 12 Ekim 2026 22:32 UTCpostmortem

    ## Summary Between 11:15 UTC and 23:47 UTC on October 9, CircleCI customers experienced hours-long delays and failures across pipelines, workflows and jobs, along with delays in the CircleCI UI, API and notifications. * From 11:15 to 13:00 UTC, pipelines were created but not processed, and outbound webhooks and Slack and email notifications were not sent. * From 13:00 to 14:40 UTC, workflows and jobs started with delays while we worked through the backlog. * From 15:15 to 20:48 UTC, workflows and jobs started with increasing delays, of up to about an hour, and the CircleCI UI and API fell behind by up to about 2 hours. During this time, some jobs failed to start and some in-progress workflows failed. * From 20:48 to 22:10 UTC, we temporarily paused starting new workflows and jobs so our systems could recover. New pipelines were accepted and queued during this time. * From 22:10 to 23:47 UTC, queued workflows and jobs resumed and were successfully processed. Some of them had waited up to about 2 hours. * By 23:47, the incident was mitigated. The status page for this incident can be found at [October 9 - Delay in data appearing in UI and API](https://status.circleci.com/incidents/6cfhhlr4rmm0). Customers experienced a similar incident earlier in the week at [October 6 - Delays in pipelines, workflows, UI data, and notifications](https://status.circleci.com/incidents/z4hbq8h49j8c). Multiple CircleCI services use Temporal backed by Postgres as a reliable queueing mechanism, and both incidents had the same cause: the rate of writes to Temporal's Postgres instance were faster than Postgres’s transaction log could archive those writes. In both cases, this caused multi-hour delays in processing both pipelines and status notifications. We evaluated several mitigations, then paused new workflow starts so the system could recover safely, and ramped back up gradually. We then throttled work back up until our systems returned to normal. To permanently resolve the bottleneck, we have split work across multiple Temporal instances, each with its own independent database and worker clusters, and we load-balance across them. We had already scheduled infrastructure work starting the week of October 12 that would have removed this exact bottleneck and prevented these incidents. So starting 19:11 on October 9 our engineering team implemented, tested, and rolled out a simpler version of these changes within a few hours. We further added new alerting and tuned the underlying databases for better performance under high load. Customers whose jobs failed during this window may rerun them. ## Background To run customer jobs, CircleCI executes a series of steps: we accept customer pipelines; we assign jobs for those pipelines to workers; we deliver status updates for those pipelines and jobs; and we charge customers for the credits those jobs consume. Each of these steps is implemented by an independent service, with reliable queues in between. Historically we have implemented these reliable queues with RabbitMQ on top of durable storage, with exponential backoff and dead letter queues for reliability. Over the last year, we have increasingly reimplemented our reliable queues on [Temporal](https://temporal.io/), which provides far better durability and reliability guarantees over a simpler and more powerful programming model. Our build service \(which turns a pipeline config into an executable plan\), our workflow orchestrator service \(which distributes tasks onto workers\), our notification service \(which delivers status updates\), and our charging service \(which charges customers for credits\) all now use Temporal. Temporal stores the state for its workflows and activities \(called “history”\) in a database, and this is the only component in a Temporal instance that is synchronous and stateful. As a consequence, a Temporal instance’s ability to accept and execute workflows is dependent on the write rate of its backing database. We have also configured Temporal to delete completed workflows and activities from its history 3 days after they complete. At the time of this incident, we used a single clustered Temporal instance backed by a Multi-AZ Postgres RDS instance for all of these reliable queues. While a Multi-AZ RDS instance is resilient to zone failures, it maintains database consistency via a single write-ahead-log \(WAL\). At the time we had configured our Postgres instance to store its WAL on a Dedicated Log Volume \(DLV\) so log writes did not compete with data writes. The database archives the log continuously to backup storage, and it can only reuse space on the volume after the log has been archived. If the database writes logs faster than it archives, the volume fills and Postgres has no space to the write its WAL log. Then the database stops accepting incoming writes and goes entirely read-only. An RDS DLV is limited to 1TB of storage and 3000 IOPS and per AWS these limits are hardcoded and cannot be increased. ## What Happened _\(All times UTC\)_ One of the contributing factors to the October 6 incident was that we were processing a high rate of Temporal history deletions at the same time as incoming work, which in turn put pressure on the backing database. To resolve the October 6 incident, we changed cleanup settings on Temporal’s largest tables and moved the transaction log back to its dedicated volume. These changes eliminated the major source of transaction log writes, but did not consider the additional log writes from scheduled deletions. Because we have configured Temporal to delete completed workflows and activities from its history 3 days after they complete, the October 6 history was scheduled to be deleted on October 9. Starting at 08:00 on October 9, Temporal began processing those scheduled deletions, and as a consequence free space on the Postgres DLV began dropping precipitously, from 0.8TB at 08:00 to 0.1TB by 10:10. Our monitoring alerted at 10:28 and we declared an incident at 10:31. While our infrastructure team was investigating, at 11:15 the DLV ran out of space and the Postgres instance went read-only. This stopped all Temporal processing in its tracks. At 11:42, we restarted Postgres to move the WAL log from the DLV onto the data volume and use the spare disk space and IOPS there. This maneuver had mitigated the incident on October 6, and we knew it would take roughly 60 minutes. While the database was restarting, we began implementing several load-shedding techniques upstream of Temporal: * We began investigating whether we should shed incoming workloads altogether to keep the rest moving, but ultimately decided that this would provide no value. * At 12:29, we flagged off credit charging updates, which represented 12% of Temporal activities. This left the Pipeline Usage page with stale charging data, until we would backfill it, but would not lose data or prevent pipelines from running. At 12:59, the database was back up and began processing work that had queued since 11:15 and by 14:40, this backlog had cleared and jobs were starting on time. However, by 15:15, delays returned as database’s routing cleanup had fallen far behind on the tables Temporal uses to track queued and scheduled work. Those tables normally hold tens of thousands of deleted rows awaiting cleanup, but by late afternoon, they held tens of millions of rows. Every Temporal operation had to read past those rows, so the database spent much more processing time on each one and Temporal ran slower. This resulted in customers continuing to see hour-long delays in starting pipelines and in status updates. For the next several hours we attempted various mitigations, including: * Manipulating Temporal configuration values to reduce database pressure. This had minimal effect. * Running manual vacuum jobs to clean up dead rows in Postgres. This ended up competing for CPU with queries themselves, and was ultimately counterproductive. We cancelled them at 17:45 to relieve the pressure on the database load. * We began trying to move all of the notification usecases to a separate Temporal instance. This represented 18% of Temporal activities. We successfully finished moving notifications by 17:07. * At 17:16, we successfully implemented an optimization in our representation of pipeline state, which reduced it by 5%. That in turn reduced the size of database writes and therefore data pressure on the Postgres WAL log. None of these fully mitigated the issue. By 20:48, we realized that Postgres was now thrashing on database CPU and was no longer bottlenecked on log writes. We further realized that our upstream systems were both submitting new work and also retrying work that had earlier been submitted and failed. Recognizing that we were in a classic retry storm, we paused all incoming and retry work and let it queue up, in order to allow the database to fully complete in-process work. We then slowly throttled up queued work from 22:07 to keep the database at a sustainable load. This fully succeeded by 23:47 when all queued work had started, and we closed the incident at 02:08 on October 10. ## Future Prevention and Process Improvement ### Multiple Temporal Instances In parallel with incident mitigation and resolution, starting at 19:11 on October 9, we also began standing up multiple sharded Temporal instances and implementing the ability to load-balance incoming work between them. Each of the multiple Temporal instances maintains its own independent database and worker clusters, and so is isolated from the others. As a postmortem action item from the October 6 incident, we had already scheduled infrastructure work that would have removed the bottleneck of a single Temporal instance and Postgres database, starting October 12 and expecting to take 2 weeks. On October 9, we realized that this work simply could not wait, so our engineering team implemented, tested, and rolled out a simpler version of the planned changes within a few hours. These changes completed successfully at 01:45 on October 10. **In addition, we are changing how we store and monitor transaction logs.** Our Temporal database no longer uses the fixed-size log volume. We are adding alerts on how far log archiving falls behind and how fast the database writes logs, so we can act hours earlier than we did on October 9. **We are also revisiting the Temporal's deletion schedule.** Temporal deletes finished work a few days after it runs, so a busy day returns as database load later in the week. We are changing when and how quickly those deletions run. **We are changing how our systems retry when Temporal is slow.** On October 9, our systems retried failed work against Temporal and added to its load. As we committed after the October 6 incident, we are changing our systems to wait for Temporal to recover so work is not dropped. ## Conclusion Customer experience is our top priority, and we commit to continually improving the reliability of our systems to match the trust that our customers place in us. We thank our customers for their patience while our team worked to resolve these incidents. Please reach out to our support team with any questions or concerns.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 8 Ekim 2026 13:00 UTCidentified

   Müşteriler makine işleri için yüksek bekleme süreleri yaşayabilirler. Bunu çözmek için çalışıyoruz.

2. 8 Ekim 2026 13:34 UTCidentified

   Linux makine işlerini kullanan müşteriler, yaklaşık 11 dakika boyunca, orta, kol.medim ve kol.large kaynak sınıflarında 30 dakikayı aşan en uzun bekleyişlerle dolu. Mühendislerimiz sorunu tespit ettiler ve bir düzeltme üzerinde çalışıyorlar. 14:00 UTC tarafından başka bir güncelleme sağlayacağız.

3. 8 Ekim 2026 14:04 UTCidentified

   Linux makine işlerini kullanan müşteriler, yaklaşık 40 dakika boyunca, en uzun bekleyişleri 50 dakikadan fazla sürüyor. Çoğu Linux makinesi kaynak sınıfları, orta, büyük, xlarge, 2xlarge ve Arm eşdeğerleri dahil olmak üzere etkilenir. Mühendislerimiz sorunu tespit ettiler ve bir düzeltme üzerinde çalışıyorlar. 14:30 UTC tarafından başka bir güncelleme sağlayacağız.

4. 8 Ekim 2026 14:37 UTCidentified

   Linux makine işlerini ve uzaktan Docker kullanan müşteriler yüksek bekleme zamanlarını deneyimliyor. Bekle süreleri azalmaya başladı ve şimdi yaklaşık 20 dakika, bazı kaynak sınıflarında 40 dakikadan fazla bekleyerek. Mühendislerimiz sorunu tespit ettiler ve bir düzeltme üzerinde çalışıyorlar. 1 UTC ile başka bir güncelleme sağlayacağız.

5. 8 Ekim 2026 15:01 UTCidentified

   Bir düzeltme dağıtıldı ve bekleme süreleri azaldı, ancak Linux makine işlerini kullanan müşteriler ve Uzaktan Docker hala gecikmeler yaşıyor. Şu anda ortalama 11 dakika bekleyin, en uzun beklemeler bazı kaynak sınıflarında 35 dakikadan fazla. Mümkün olduğunca çabuk kapasite eklemek için çalışıyoruz. 15:30 UTC tarafından başka bir güncelleme sağlayacağız.

6. 8 Ekim 2026 15:31 UTCidentified

   Bekleme süreleri azalmaya devam eder, ancak Linux makine işlerini kullanan müşteriler ve uzaktan Docker hala gecikmeler yaşıyor. Şu anda ortalama 6 dakika bekleyin. En uzun beklemeler, yaklaşık 20 dakika kadar, 2xlarge, kol.2xlarge ve gpu.nvidia'da. Küçük kaynak sınıfları. Mümkün olduğunca çabuk kapasite eklemek için çalışıyoruz. 16:00 UTC tarafından başka bir güncelleme sağlayacağız.

7. 8 Ekim 2026 15:59 UTCidentified

   Bekleme süreleri azalmaya devam eder, ancak Linux makine işlerini kullanan müşteriler ve uzaktan Docker hala gecikmeler yaşıyor. Şu anda yaklaşık 90 saniye bekleyin, en uzun beklemeler bazı kaynak sınıflarında yaklaşık 6 dakika. Mümkün olduğunca çabuk kapasite eklemek için çalışıyoruz. 16:30 UTC tarafından başka bir güncelleme sağlayacağız.

8. 8 Ekim 2026 16:09 UTCmonitoring

   Linux makine işlerini kullanan müşteriler için zaman bekleyin ve uzaktan Docker normale döndü. Bekleme zamanını doğrulamayı izlemek kapasite eklemeye devam ederken istikrarlı kalırız. 16:30 UTC tarafından başka bir güncelleme sağlayacağız.

9. 8 Ekim 2026 16:35 UTCresolved

   8 Ekim'de 12:40 UTC ve 16:00 UTC arasında, Linux makine işlerini ve uzaktan Docker kullanan müşteriler yüksek bekleme süreleri yaşadı. Sorun çözüldü ve bekleme süreleri normale döndü. Size sabrınız için teşekkür ederiz, ekibimiz bir düzeltme uygulamak için çalıştı.

10. 8 Ekim 2026 17:54 UTCpostmortem

    # # # Özet 1 Ekim'den bu yana, CircleCI müşterileri müşteri boru yürütmesinde gecikmelere ve başarısızlıklara neden olan çok sayıda olay yaşadı. İki \(un related\) nedeni vardır, her ikisi de CircleCI mühendisliği ekibi aktif olarak azaltılmasıdır: * Mevcut Bulut Bilişim Kapasitesi * İç Altyapı ## available Cloud Computing Kapasite * **Problem **: Yüksek performanslı bulut örnekleri için talep, müşteri işlerini yürütmek için kullandığımız bulut sağlayıcı örnek türlerine son derece hızlı ilerliyor. * **Incidents**: * [Elevated wait times for machine jobs](https://status.circleci.com/incidents/jn756xtsy4xg) * [Increased task wait times for Docker Gen2](https://status.circleci.com/incidents/39rfrjmk5pvd) * [Elevated level of infra doesn on client jobs](https://status.circleci.com/incidents/0z31ldjd8m5v) * [Başlangıçta Machine Job Tasks](https://status.circleci.com/incidents/tj6wdnfjwr64) * [Delays Gen 2 Docker Jobs'a başlıyor] (https://status.circleci.com/incidents/22mrv46g6n7g) * **Mitigations and Decisions**: * Mevcut yüksek performanslı örneklerle ek bölgeleri içerecek bulut bilişim bölgelerimizi genişletiyoruz. * Mevcut bölgelerimizde bulut bilişim ortaklarımızdan daha fazla garantili kapasite sağlamak için de çalışıyoruz. * Müşterilere sunabileceğimiz örnek türlerin setini daha da genişletiyoruz. * 9 Ekim 2026'da bu olaylar hakkında ayrıntılı bir olay raporu yayınlayacağız. # # # İç Altyapı * **Problem **: Müşteri iş akış orkestrası aracılığıyla birden fazla işlem sağlayıcı üzerinde müşteri iş akışlarını tayin ediyoruz. Bu hizmet şu anda tek bir veritabanının yazarı tarafından kontrol ediliyor. * **Incidents:** * [ Boru hatları, akışlar, UI verileri ve bildirimleri] (https://status.circleci.com/incidents/z4hbq8h49j8c) * [Emergency Infrastructure Bakım] (https://status.circleci.com/incidents/g60yc9bvvkmx) * **Mitigations and Decisions**: * 23 Ekim 2026'da, her biri kendi veritabanı olan birden fazla red dışı iş akış orkestrası işletmesini uygulamayı planlıyoruz, bu da orkestrayı aralarında bölmemizi sağlayacaktır. # # # Our Commitment Şüpheden kaçınmak için, * Bu özel olaylar Github'da devam eden kesintilerle ilgili değildir * Şu anda altyapımızı veya hizmetlerimizi taklit etmiyoruz * Şu anda siber saldırı altında değiliz Müşteri deneyimi bizim en önemli önceliğimizdir ve müşterilerimizin içimizde yer aldığı güvenle eşleşmesi için sistemlerimizin güvenilirliğini sürekli olarak geliştirmeye çalışıyoruz. Müşterilerimize sabrı için teşekkür ederiz, ekibimiz bu olayları çözmeye çalışırken ve gelecekteki olayları önlemek için çalışıyoruz. Lütfen destek ekibimize herhangi bir soru veya endişelerle ulaşabilirsiniz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 7 Ekim 2026 18:54 UTCidentified

   Docker Gen2 üzerinde işler için artan bir bekleme süresi var.

2. 7 Ekim 2026 19:00 UTCidentified

   Not: gecikmeler, Docker “xlarge” ve yukarıda çalışan insanlar için daha belirgin olacaktır.

3. 7 Ekim 2026 19:52 UTCmonitoring

   Hala görevde artışları görüyoruz, ancak ortalama bekleme süreleri tüm Docker Gen2 için daha iyi görünüyor.

4. 7 Ekim 2026 20:05 UTCresolved

   Bu olay çözüldü.

5. 8 Ekim 2026 17:54 UTCpostmortem

   # **Summary** 1 Ekim ve 8 Ekim 2026 arasında, CircleCI müşterileri, hangi işlerin başlamak için normalden daha uzun süre beklediği beş ayrı olay yaşadı veya başlamadı. Olayların üçü, bulut sağlayıcımızdan sınırlı örnek kullanılabilirlik tarafından yönlendirildi. Biri, zamanlama altyapısımızda bir yapılandırma konusu tarafından ve olay sırasında büyüttüğümüz bir iç hizmette bellek sınırları tarafından kaynaklandı. * ** 1 Ekim 07:57 ila 10:24 UTC:** Docker Gen 2 işleri başlamak için 30 dakika bekledi. Bir yapılandırma konusu, Gen 2 zamanlama sunucularını yüksek performanslı yerel disklerini kullanarak engelledi. Trafikte bir patlama sırasında, geri dönüş diskleri doygun ve iş yerleştirme yavaşladı. * ** 7 Ekim 13:27 - 14:06 UTC:** Makine işleri normalden daha uzun bekledi çünkü bulut sağlayıcımızdan yeterince sanal makine elde edemedik. * ** 7 Ekim 14:24 15:21 UTC:** Bazı işler bir altyapı hatasıyla başarısız oldu ve iş akışları gecikti. Her işi başlangıçtaki yapılandırmasını sağlayan hizmet hafızadan çıktı ve yeniden başladı. * ** 7 Ekim 18:49 - 20:05 UTC:** Docker Gen 2 işleri normalden daha uzun bekledi çünkü bulut sağlayıcımızdan yeterince örnek alamadık. * ** 8 Ekim 12:48 to 16:00 UTC:** Linux makinesi işleri ve uzaktan Docker işleri başlamak için 50 dakika bekledi. Bulut sağlayıcımız, talep ettiğimiz örnek türünden yeterince sahip değildi ve farklı bir örnek türü seçmek bizi alternatifleri kullanarak tuttu. Bu olaylar sırasında bekleyen işler gecikti, kaybolmadı. İşleri 7 Ekim'de bir altyapı hatasıyla başarısız olan müşteriler 14:24'den 15:21 UTC'ye geri dönebilirler. Orijinal statü sayfaları aşağıda bulunabilir: * [1 Ekim - Gen 2 Docker Jobs'a başlayan gecikmeler] (https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 Ekim - Makine İş Görevleri Üzerine Gecikme] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 Ekim - Elevated level of infra failing on müşteri işleri] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 Ekim - Docker Gen2 için artan bir görev bekleme süreleri] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 Ekim - Elevated wait times for machine jobs](https://status.circleci.com/incidents/jn756xtsy4xg) # **Background** CircleCI üzerinde çalışan her iş hesaplamaya ihtiyaç duyar. Bu hesaplama nereden geliyor executor. Docker işleri, zamanlamanın belirli bir filo üzerinde çalıştığı sunucu kümeleri üzerinde çalışır. Programcı, hangi örneği her işi yürüten bu sunuculardaki yazılımdır. Gen 2 Docker işleri, 1 Ekim olayında böyle bir kümede koştu. Gen 1 Docker işleri birkaç kümeye yayılmıştır. Uzak Docker işleri de dahil olmak üzere makine işleri, özel bir sanal makine almak. Uzak Docker işi, bir Linux makinesi işi olarak düzenleme yoluyla yapılır. Makine düzenleme hizmetimiz, normalde makine işleri için kullandığımız iki bölgeden birinde bulut sağlayıcımızdan her makine talep eder. Sağlayıcı, talep ettiğimiz örnek türü tedarik edemezse, hizmet geri düşer: farklı bir örnek türü veya farklı bir bölgeye, koruduğumuz bir listeden. Bir makine mevcut olana kadar bir iş bekler. Herhangi bir iş başladığında, yapılandırması için bir iş yapılandırma hizmeti sorar. Bu hizmet aynı programın küçük kopyaları olan pods seti olarak çalışır. Çok fazla pods dursa, kalan pods daha fazla yük taşır ve işler servis geri dönene kadar başlayabilir. Bu yollar üç tür kapasiteye bağlıdır: zamanlama sistemlerimizin yönlendirmesi, bulut sağlayıcımızdan örnek tedariki ve işe başlayan hizmetlerin hafıza ve sayısı. Bunlardan herhangi birinde kısa bir düşüş, iş bekleyen veya başarısız olur. # ** What Happened** \(All times UTC\) ## ** Ekim 1: Docker Gen 2 işleri 30 dakikaya kadar gecikti** 07:44'te, Gen 2 Docker işlerini yapan sunucularda disk aktivitesi kapasitenin %90'ına yükseldi ve orada kaldı. 07:57'te, Docker işlerinin sayısı büyümeye başladı ve onunla birlikte gül bekliyordu. Otomatik bir uyarı sayfası 08:08'de on-call mühendisini buldu. 08:42'de bir olayı ilan ettik. 08:43'te, mühendisler zamanlama sunucuları üzerinde yüksek disk gecikme tespit etti. İlk olarak disklerin yük için çok yavaş olduğuna inandılar, bu yüzden daha hızlı bir disk türüne bir değişiklik hazırladılar. 09:01'de ekip iki iş akışlarında anlaştı: sunucuları daha hızlı disklere taşıdı ve ikinci bir Gen 2 küme ekledi, böylece işler iki küme arasında bölündü. 09:41'te mühendisler kök nedenini buldular. Her zamanlama sunucusu doğrudan ona eklenmiş hızlı disklere sahiptir ve programcı, çalışma verilerini orada tutmak anlamına gelir. Bu sunucular bir güvenlik korumalı işletim sistemi görüntüsü üzerinde çalışır ve bu görüntüde hızlı diskler kullanılmamıştır. Programcı verileri daha yavaş ağ tabanlı disklere yazdı. Hızlı diskleri oluşturan senaryo bir hata olmadan başarısız oldu ve bu sunucularda giriş sırasında bir boşluk başarısızlık sakladı. Gen 2 trafiği de giderek daha fazla patlamaya başlamıştı. Bu patlamalar sırasında yavaş diskler doymuş ve programcı geride kaldı. Gen 2 orta kaynak sınıfındaki işler 30 dakikaya kadar beklendiğinde, 09:54'de zaman zirveye çıktı. 09:55 yılında, mühendisler hızlı diskleri doğru bir şekilde oluşturan bir düzeltme uyguladılar. 10:11'de, programcı işleri daha hızlı dağıtmaya başladı, bu da sunucuların yeni işlerle devam edebileceğini doğruladı. Gen 2 ortamı için zaman beklemek 10:17'de 13 dakikaya düştü ve 10:20'de 1 dakika 30 saniye. 10:24'de izlemek için statü sayfasını taşıdık ve olayı 10:45'te çözdük. 11:20'de ikinci Gen 2 küme iş koşmaya başladı. ## ** 7 Ekim 13:27 to 14:06: Elevated makine işleri için zaman bekliyor Yüksek kuyruk ve bekleme sürelerini gördükten sonra 13:27'de bir olayı ilan ettik. 13:31'de durum sayfasına gönderildik. 13:31'de, mühendisler makine işleri için sanal makineleri elde etmek için mücadele ettiğimizi gördü ve başlamak için bekleyen iş sayısı ağırlıklı olarak makine işleri için yüksekti. 13:34'te, bekleme süreleri executors arasında yükseldi. 13:48'de, bekleme süreleri daha fazla makine olarak iyileşmeye başladı ve olayı 14:06'de çözdük. ## ** 7 Ekim 14:24 to 15:21: İş başarısızlıkları ve iş akış gecikmeleri** Daha önceki olayın çözülmesinden kısa bir süre sonra, infaz sistemlerimize sunulan iş sayısına keskin bir düşüş nedeniyle 14:24'te yeni bir olay ilan ettik. 14:26 yılında, mühendisler iş yapılandırma servisinin podslarının yeniden başlatıldığını gördü. Tekrarlanan Pods, taleplere cevap vermek için hizmetin daha az kopyasını terk eder ve tekrarlanan girişimlerden sonra konfigürasyonlarını alamayan işler altyapı hatasıyla başarısız olur. Zaten çalışan iş akışları, başlamamış olan işlerden güncelleştirmeler için bekledi. 14:35'te mühendisler mevcut hafıza miktarını pods'a yükseltti ve yükü paylaşmak için daha fazla kopya verdi. Ayrıca mevcut iş tekliflerinin miktarı iyileşmeye başladı ve iş akışı sistemimiz aracılığıyla akan mesajlar sayısı normal seviyelere döndü. 14:44 yılında, durumu izlemek için taşıdık. İş yapılandırma servisindeki Pods hafıza sınırlarına ulaştı ve yeniden başladı. hafıza tahsislerini ve pod sayılarını artırdık ve hizmet iyileşti. 15:13'te, Gen 2 Docker kümelerindeki vaka sayısını artırdık, böylece işleri hızlı bir şekilde beklemeye çalıştık. Olayı 15:21'de çözdük. ## ** 7 Ekim 18:49 to 20:05: Docker Gen 2 iş için bekleme süreleri * Docker Gen 2'den sonra 18:49'da yeni bir olay ilan ettik. 18:51'de mühendisler, mevcut örneklerin eksikliğinin bizi yeterince satın almadan koruduğunu doğruladılar, ki bu da bekleme süreleri yükseltti. Zamanlar kaynak sınıfı büyüklüğü tarafından farklılık gösterir. 19:52'te, ortalama bekleme süreleri daha fazla kapasite mevcut olduğu bir saatten daha düşüktü, ancak kısa çatlaklar devam etti ve durumu izlemek için değiştirdik. Olayı 20:05'te çözdük. ## ** 8 Ekim: Linux makinesi ve uzaktan Docker işleri 50 dakikaya kadar bekler Makine ve uzaktan Docker işleri için çok sayıda iş gördükten sonra 12:48'de bir olay ilan ettik. 12:49'da mühendisler, bulut sağlayıcımızın yeterince örnek oluşturamayacağını gördü. Gecikmeler araştırdığımız gibi tırmanmaya devam etti. 13:13'te, ilk seçimimiz kullanılamadığında farklı bir örnek türü veya bölgeyi seçen mantığı incelemeye başladık. 13:24'te, bu mantıkta bir hatanın bizi birincil bölgemizde başka örnek tiplerini kullanmaktan alıkoyduğundan şüphelendik, bu yüzden geri çekilme bölgemizi devre dışı bıraktık ve kusurların nedenini doğruladık. Mühendisler bir düzeltme üzerinde çalışmaya başladı ve 14:49'da kullandı. Servis diğer örnek tiplerini talep etmeye başladı ve büyük sayılarda makinelere başladı. 14:58'de, bir makine için bekleyen işlerin kuyruğu sürekli düştü. Kaynakların sınıflarındaki ortalama bekleme süreleri bir sonraki saat boyunca bekleme işleri hakkında çalıştık. 16:00'da, bir makine için bekleyen işlerin kuyruğu temizlendi ve bekleyen işlerin sayısı normale döndü. 16:09'da izleme ve olayı 16:35'te çözdük. # **Future Prevention and Process Improvement** İş direncini güçlendirmek için aşağıdaki adımları atıyoruz, çeşitlendirme, geri dönüşüm mantığı ve daha önceki algılama dahil. ** Hesap bölgelerimizi genişletiyoruz. ** 7 Ekim ve 8 Ekim olaylarında, bulut sağlayıcımız kullandığımız bölgelerde yeterince örnek veremezdi. Yeni bölgeleri, tercih bölgelerimizi dışarı çıkarmak için geri çekilme mantığımıza ekliyoruz. ** Farklı bir örnek türü seçtiği mantığı düzeltiyoruz.** 8 Ekim'de, bir hata aynı bölgede diğer örnek tiplerini kullanmaktan makine düzenleme hizmeti tuttu. Olay sırasında bir düzeltme yaptık ve şimdi bu mantığı bir bütün olarak gözden geçiriyoruz, testlerle, bu yüzden bir örnek türün eksikliği başka bir işe yaramıyor. **Ek kapasiteyi teklif ettiğimiz ve garanti ettiğimiz örnek türleri genişletiyoruz.** Mevcut bölgelerimizde ek kapasiteyi rezerve etmek için bulut sağlayıcımızla çalışıyoruz ve işlerin çalıştırabileceği örnek tipler ekliyoruz. Yüksek performanslı hesaplama için endüstri talebi büyüyor. Nerede ve nasıl kaynaklandığımızı çeşitlemekteyiz, böylece müşterilerimiz tedarik varyasyonundan vazgeçiliyor. **İkinci bir Gen 2 Docker kümesi ekledik, böylece trafik patlamaları iki küme arasında dağıtılıyor. ** Ayrıca sunucu disk saturasyon konusunda uyarılar ekliyoruz ve programcı yerlerin ne kadar hızlı çalıştığını ve bir sunucunun kullanımında hızlı diskler olmadan başladığı zaman yangınların ne kadar hızlı başladığı konusunda uyarı ekliyoruz. Disk kurulum senaryosu bir hatayla başarısız oldu ve bu sunuculardan günlük gönderimi geri aldık, böylece benzer bir problem daha erken görünür. Müşteri deneyimi bizim en önemli önceliğimizdir ve müşterilerimizin içimizde yer aldığı güvenle eşleşmesi için sistemlerimizin güvenilirliğini sürekli olarak geliştirmeye çalışıyoruz. Müşterilerimize sabrı için teşekkür ederiz, ekibimiz bu olayları çözmeye çalıştı. Lütfen destek ekibimize herhangi bir soru veya endişelerle ulaşabilirsiniz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 7 Ekim 2026 14:27 UTCinvestigating

   Infra'daki bir artışın müşteri işleri için başarısız olduğunu araştırıyoruz.

2. 7 Ekim 2026 14:44 UTCmonitoring

   Kurtarma belirtileri görüyoruz. Docker Gen2 bekleme süreleri biraz yüksek ve takip ediyoruz.

3. 7 Ekim 2026 15:21 UTCresolved

   Bu olay çözüldü.

4. 8 Ekim 2026 17:55 UTCpostmortem

   # **Summary** 1 Ekim ve 8 Ekim 2026 arasında, CircleCI müşterileri, hangi işlerin başlamak için normalden daha uzun süre beklediği beş ayrı olay yaşadı veya başlamadı. Olayların üçü, bulut sağlayıcımızdan sınırlı örnek kullanılabilirlik tarafından yönlendirildi. Biri, zamanlama altyapısımızda bir yapılandırma konusu tarafından ve olay sırasında büyüttüğümüz bir iç hizmette bellek sınırları tarafından kaynaklandı. * ** 1 Ekim 07:57 ila 10:24 UTC:** Docker Gen 2 işleri başlamak için 30 dakika bekledi. Bir yapılandırma konusu, Gen 2 zamanlama sunucularını yüksek performanslı yerel disklerini kullanarak engelledi. Trafikte bir patlama sırasında, geri dönüş diskleri doygun ve iş yerleştirme yavaşladı. * ** 7 Ekim 13:27 - 14:06 UTC:** Makine işleri normalden daha uzun bekledi çünkü bulut sağlayıcımızdan yeterince sanal makine elde edemedik. * ** 7 Ekim 14:24 15:21 UTC:** Bazı işler bir altyapı hatasıyla başarısız oldu ve iş akışları gecikti. Her işi başlangıçtaki yapılandırmasını sağlayan hizmet hafızadan çıktı ve yeniden başladı. * ** 7 Ekim 18:49 - 20:05 UTC:** Docker Gen 2 işleri normalden daha uzun bekledi çünkü bulut sağlayıcımızdan yeterince örnek alamadık. * ** 8 Ekim 12:48 to 16:00 UTC:** Linux makinesi işleri ve uzaktan Docker işleri başlamak için 50 dakika bekledi. Bulut sağlayıcımız, talep ettiğimiz örnek türünden yeterince sahip değildi ve farklı bir örnek türü seçmek bizi alternatifleri kullanarak tuttu. Bu olaylar sırasında bekleyen işler gecikti, kaybolmadı. İşleri 7 Ekim'de bir altyapı hatasıyla başarısız olan müşteriler 14:24'den 15:21 UTC'ye geri dönebilirler. Orijinal statü sayfaları aşağıda bulunabilir: * [1 Ekim - Gen 2 Docker Jobs'a başlayan gecikmeler] (https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 Ekim - Makine İş Görevleri Üzerine Gecikme] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 Ekim - Elevated level of infra failing on müşteri işleri] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 Ekim - Docker Gen2 için artan bir görev bekleme süreleri] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 Ekim - Elevated wait times for machine jobs](https://status.circleci.com/incidents/jn756xtsy4xg) # **Background** CircleCI üzerinde çalışan her iş hesaplamaya ihtiyaç duyar. Bu hesaplama nereden geliyor executor. Docker işleri, zamanlamanın belirli bir filo üzerinde çalıştığı sunucu kümeleri üzerinde çalışır. Programcı, hangi örneği her işi yürüten bu sunuculardaki yazılımdır. Gen 2 Docker işleri, 1 Ekim olayında böyle bir kümede koştu. Gen 1 Docker işleri birkaç kümeye yayılmıştır. Uzak Docker işleri de dahil olmak üzere makine işleri, özel bir sanal makine almak. Uzak Docker işi, bir Linux makinesi işi olarak düzenleme yoluyla yapılır. Makine düzenleme hizmetimiz, normalde makine işleri için kullandığımız iki bölgeden birinde bulut sağlayıcımızdan her makine talep eder. Sağlayıcı, talep ettiğimiz örnek türü tedarik edemezse, hizmet geri düşer: farklı bir örnek türü veya farklı bir bölgeye, koruduğumuz bir listeden. Bir makine mevcut olana kadar bir iş bekler. Herhangi bir iş başladığında, yapılandırması için bir iş yapılandırma hizmeti sorar. Bu hizmet aynı programın küçük kopyaları olan pods seti olarak çalışır. Çok fazla pods dursa, kalan pods daha fazla yük taşır ve işler servis geri dönene kadar başlayabilir. Bu yollar üç tür kapasiteye bağlıdır: zamanlama sistemlerimizin yönlendirmesi, bulut sağlayıcımızdan örnek tedariki ve işe başlayan hizmetlerin hafıza ve sayısı. Bunlardan herhangi birinde kısa bir düşüş, iş bekleyen veya başarısız olur. # ** What Happened** \(All times UTC\) ## ** Ekim 1: Docker Gen 2 işleri 30 dakikaya kadar gecikti** 07:44'te, Gen 2 Docker işlerini yapan sunucularda disk aktivitesi kapasitenin %90'ına yükseldi ve orada kaldı. 07:57'te, Docker işlerinin sayısı büyümeye başladı ve onunla birlikte gül bekliyordu. Otomatik bir uyarı sayfası 08:08'de on-call mühendisini buldu. 08:42'de bir olayı ilan ettik. 08:43'te, mühendisler zamanlama sunucuları üzerinde yüksek disk gecikme tespit etti. İlk olarak disklerin yük için çok yavaş olduğuna inandılar, bu yüzden daha hızlı bir disk türüne bir değişiklik hazırladılar. 09:01'de ekip iki iş akışlarında anlaştı: sunucuları daha hızlı disklere taşıdı ve ikinci bir Gen 2 küme ekledi, böylece işler iki küme arasında bölündü. 09:41'te mühendisler kök nedenini buldular. Her zamanlama sunucusu doğrudan ona eklenmiş hızlı disklere sahiptir ve programcı, çalışma verilerini orada tutmak anlamına gelir. Bu sunucular bir güvenlik korumalı işletim sistemi görüntüsü üzerinde çalışır ve bu görüntüde hızlı diskler kullanılmamıştır. Programcı verileri daha yavaş ağ tabanlı disklere yazdı. Hızlı diskleri oluşturan senaryo bir hata olmadan başarısız oldu ve bu sunucularda giriş sırasında bir boşluk başarısızlık sakladı. Gen 2 trafiği de giderek daha fazla patlamaya başlamıştı. Bu patlamalar sırasında yavaş diskler doymuş ve programcı geride kaldı. Gen 2 orta kaynak sınıfındaki işler 30 dakikaya kadar beklendiğinde, 09:54'de zaman zirveye çıktı. 09:55 yılında, mühendisler hızlı diskleri doğru bir şekilde oluşturan bir düzeltme uyguladılar. 10:11'de, programcı işleri daha hızlı dağıtmaya başladı, bu da sunucuların yeni işlerle devam edebileceğini doğruladı. Gen 2 ortamı için zaman beklemek 10:17'de 13 dakikaya düştü ve 10:20'de 1 dakika 30 saniye. 10:24'de izlemek için statü sayfasını taşıdık ve olayı 10:45'te çözdük. 11:20'de ikinci Gen 2 küme iş koşmaya başladı. ## ** 7 Ekim 13:27 to 14:06: Elevated makine işleri için zaman bekliyor Yüksek kuyruk ve bekleme sürelerini gördükten sonra 13:27'de bir olayı ilan ettik. 13:31'de durum sayfasına gönderildik. 13:31'de, mühendisler makine işleri için sanal makineleri elde etmek için mücadele ettiğimizi gördü ve başlamak için bekleyen iş sayısı ağırlıklı olarak makine işleri için yüksekti. 13:34'te, bekleme süreleri executors arasında yükseldi. 13:48'de, bekleme süreleri daha fazla makine olarak iyileşmeye başladı ve olayı 14:06'de çözdük. ## ** 7 Ekim 14:24 to 15:21: İş başarısızlıkları ve iş akış gecikmeleri** Daha önceki olayın çözülmesinden kısa bir süre sonra, infaz sistemlerimize sunulan iş sayısına keskin bir düşüş nedeniyle 14:24'te yeni bir olay ilan ettik. 14:26 yılında, mühendisler iş yapılandırma servisinin podslarının yeniden başlatıldığını gördü. Tekrarlanan Pods, taleplere cevap vermek için hizmetin daha az kopyasını terk eder ve tekrarlanan girişimlerden sonra konfigürasyonlarını alamayan işler altyapı hatasıyla başarısız olur. Zaten çalışan iş akışları, başlamamış olan işlerden güncelleştirmeler için bekledi. 14:35'te mühendisler mevcut hafıza miktarını pods'a yükseltti ve yükü paylaşmak için daha fazla kopya verdi. Ayrıca mevcut iş tekliflerinin miktarı iyileşmeye başladı ve iş akışı sistemimiz aracılığıyla akan mesajlar sayısı normal seviyelere döndü. 14:44 yılında, durumu izlemek için taşıdık. İş yapılandırma servisindeki Pods hafıza sınırlarına ulaştı ve yeniden başladı. hafıza tahsislerini ve pod sayılarını artırdık ve hizmet iyileşti. 15:13'te, Gen 2 Docker kümelerindeki vaka sayısını artırdık, böylece işleri hızlı bir şekilde beklemeye çalıştık. Olayı 15:21'de çözdük. ## ** 7 Ekim 18:49 to 20:05: Docker Gen 2 iş için bekleme süreleri * Docker Gen 2'den sonra 18:49'da yeni bir olay ilan ettik. 18:51'de mühendisler, mevcut örneklerin eksikliğinin bizi yeterince satın almadan koruduğunu doğruladılar, ki bu da bekleme süreleri yükseltti. Zamanlar kaynak sınıfı büyüklüğü tarafından farklılık gösterir. 19:52'te, ortalama bekleme süreleri daha fazla kapasite mevcut olduğu bir saatten daha düşüktü, ancak kısa çatlaklar devam etti ve durumu izlemek için değiştirdik. Olayı 20:05'te çözdük. ## ** 8 Ekim: Linux makinesi ve uzaktan Docker işleri 50 dakikaya kadar bekler Makine ve uzaktan Docker işleri için çok sayıda iş gördükten sonra 12:48'de bir olay ilan ettik. 12:49'da mühendisler, bulut sağlayıcımızın yeterince örnek oluşturamayacağını gördü. Gecikmeler araştırdığımız gibi tırmanmaya devam etti. 13:13'te, ilk seçimimiz kullanılamadığında farklı bir örnek türü veya bölgeyi seçen mantığı incelemeye başladık. 13:24'te, bu mantıkta bir hatanın bizi birincil bölgemizde başka örnek tiplerini kullanmaktan alıkoyduğundan şüphelendik, bu yüzden geri çekilme bölgemizi devre dışı bıraktık ve kusurların nedenini doğruladık. Mühendisler bir düzeltme üzerinde çalışmaya başladı ve 14:49'da kullandı. Servis diğer örnek tiplerini talep etmeye başladı ve büyük sayılarda makinelere başladı. 14:58'de, bir makine için bekleyen işlerin kuyruğu sürekli düştü. Kaynakların sınıflarındaki ortalama bekleme süreleri bir sonraki saat boyunca bekleme işleri hakkında çalıştık. 16:00'da, bir makine için bekleyen işlerin kuyruğu temizlendi ve bekleyen işlerin sayısı normale döndü. 16:09'da izleme ve olayı 16:35'te çözdük. # **Future Prevention and Process Improvement** İş direncini güçlendirmek için aşağıdaki adımları atıyoruz, çeşitlendirme, geri dönüşüm mantığı ve daha önceki algılama dahil. ** Hesap bölgelerimizi genişletiyoruz. ** 7 Ekim ve 8 Ekim olaylarında, bulut sağlayıcımız kullandığımız bölgelerde yeterince örnek veremezdi. Yeni bölgeleri, tercih bölgelerimizi dışarı çıkarmak için geri çekilme mantığımıza ekliyoruz. ** Farklı bir örnek türü seçtiği mantığı düzeltiyoruz.** 8 Ekim'de, bir hata aynı bölgede diğer örnek tiplerini kullanmaktan makine düzenleme hizmeti tuttu. Olay sırasında bir düzeltme yaptık ve şimdi bu mantığı bir bütün olarak gözden geçiriyoruz, testlerle, bu yüzden bir örnek türün eksikliği başka bir işe yaramıyor. **Ek kapasiteyi teklif ettiğimiz ve garanti ettiğimiz örnek türleri genişletiyoruz.** Mevcut bölgelerimizde ek kapasiteyi rezerve etmek için bulut sağlayıcımızla çalışıyoruz ve işlerin çalıştırabileceği örnek tipler ekliyoruz. Yüksek performanslı hesaplama için endüstri talebi büyüyor. Nerede ve nasıl kaynaklandığımızı çeşitlemekteyiz, böylece müşterilerimiz tedarik varyasyonundan vazgeçiliyor. **İkinci bir Gen 2 Docker kümesi ekledik, böylece trafik patlamaları iki küme arasında dağıtılıyor. ** Ayrıca sunucu disk saturasyon konusunda uyarılar ekliyoruz ve programcı yerlerin ne kadar hızlı çalıştığını ve bir sunucunun kullanımında hızlı diskler olmadan başladığı zaman yangınların ne kadar hızlı başladığı konusunda uyarı ekliyoruz. Disk kurulum senaryosu bir hatayla başarısız oldu ve bu sunuculardan günlük gönderimi geri aldık, böylece benzer bir problem daha erken görünür. Müşteri deneyimi bizim en önemli önceliğimizdir ve müşterilerimizin içimizde yer aldığı güvenle eşleşmesi için sistemlerimizin güvenilirliğini sürekli olarak geliştirmeye çalışıyoruz. Müşterilerimize sabrı için teşekkür ederiz, ekibimiz bu olayları çözmeye çalıştı. Lütfen destek ekibimize herhangi bir soru veya endişelerle ulaşabilirsiniz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 7 Ekim 2026 13:40 UTCinvestigating

   Müşteriler Makine İş Görevleri için yüksek bekleme süreleri yaşayabilir, kök nedenini araştırıyoruz ve daha fazla bildiğimizde güncelleyeceğiz.

2. 7 Ekim 2026 13:52 UTCmonitoring

   Kurtarma belirtileri görüyoruz ve durumu takip ediyoruz.

3. 7 Ekim 2026 14:06 UTCresolved

   Olay çözüldü. Sabrınız için teşekkür ederiz

4. 8 Ekim 2026 17:55 UTCpostmortem

   # **Summary** 1 Ekim ve 8 Ekim 2026 arasında, CircleCI müşterileri, hangi işlerin başlamak için normalden daha uzun süre beklediği beş ayrı olay yaşadı veya başlamadı. Olayların üçü, bulut sağlayıcımızdan sınırlı örnek kullanılabilirlik tarafından yönlendirildi. Biri, zamanlama altyapısımızda bir yapılandırma konusu tarafından ve olay sırasında büyüttüğümüz bir iç hizmette bellek sınırları tarafından kaynaklandı. * ** 1 Ekim 07:57 ila 10:24 UTC:** Docker Gen 2 işleri başlamak için 30 dakika bekledi. Bir yapılandırma konusu, Gen 2 zamanlama sunucularını yüksek performanslı yerel disklerini kullanarak engelledi. Trafikte bir patlama sırasında, geri dönüş diskleri doygun ve iş yerleştirme yavaşladı. * ** 7 Ekim 13:27 - 14:06 UTC:** Makine işleri normalden daha uzun bekledi çünkü bulut sağlayıcımızdan yeterince sanal makine elde edemedik. * ** 7 Ekim 14:24 15:21 UTC:** Bazı işler bir altyapı hatasıyla başarısız oldu ve iş akışları gecikti. Her işi başlangıçtaki yapılandırmasını sağlayan hizmet hafızadan çıktı ve yeniden başladı. * ** 7 Ekim 18:49 - 20:05 UTC:** Docker Gen 2 işleri normalden daha uzun bekledi çünkü bulut sağlayıcımızdan yeterince örnek alamadık. * ** 8 Ekim 12:48 to 16:00 UTC:** Linux makinesi işleri ve uzaktan Docker işleri başlamak için 50 dakika bekledi. Bulut sağlayıcımız, talep ettiğimiz örnek türünden yeterince sahip değildi ve farklı bir örnek türü seçmek bizi alternatifleri kullanarak tuttu. Bu olaylar sırasında bekleyen işler gecikti, kaybolmadı. İşleri 7 Ekim'de bir altyapı hatasıyla başarısız olan müşteriler 14:24'den 15:21 UTC'ye geri dönebilirler. Orijinal statü sayfaları aşağıda bulunabilir: * [1 Ekim - Gen 2 Docker Jobs'a başlayan gecikmeler] (https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 Ekim - Makine İş Görevleri Üzerine Gecikme] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 Ekim - Elevated level of infra failing on müşteri işleri] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 Ekim - Docker Gen2 için artan bir görev bekleme süreleri] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 Ekim - Elevated wait times for machine jobs](https://status.circleci.com/incidents/jn756xtsy4xg) # **Background** CircleCI üzerinde çalışan her iş hesaplamaya ihtiyaç duyar. Bu hesaplama nereden geliyor executor. Docker işleri, zamanlamanın belirli bir filo üzerinde çalıştığı sunucu kümeleri üzerinde çalışır. Programcı, hangi örneği her işi yürüten bu sunuculardaki yazılımdır. Gen 2 Docker işleri, 1 Ekim olayında böyle bir kümede koştu. Gen 1 Docker işleri birkaç kümeye yayılmıştır. Uzak Docker işleri de dahil olmak üzere makine işleri, özel bir sanal makine almak. Uzak Docker işi, bir Linux makinesi işi olarak düzenleme yoluyla yapılır. Makine düzenleme hizmetimiz, normalde makine işleri için kullandığımız iki bölgeden birinde bulut sağlayıcımızdan her makine talep eder. Sağlayıcı, talep ettiğimiz örnek türü tedarik edemezse, hizmet geri düşer: farklı bir örnek türü veya farklı bir bölgeye, koruduğumuz bir listeden. Bir makine mevcut olana kadar bir iş bekler. Herhangi bir iş başladığında, yapılandırması için bir iş yapılandırma hizmeti sorar. Bu hizmet aynı programın küçük kopyaları olan pods seti olarak çalışır. Çok fazla pods dursa, kalan pods daha fazla yük taşır ve işler servis geri dönene kadar başlayabilir. Bu yollar üç tür kapasiteye bağlıdır: zamanlama sistemlerimizin yönlendirmesi, bulut sağlayıcımızdan örnek tedariki ve işe başlayan hizmetlerin hafıza ve sayısı. Bunlardan herhangi birinde kısa bir düşüş, iş bekleyen veya başarısız olur. # ** What Happened** \(All times UTC\) ## ** Ekim 1: Docker Gen 2 işleri 30 dakikaya kadar gecikti** 07:44'te, Gen 2 Docker işlerini yapan sunucularda disk aktivitesi kapasitenin %90'ına yükseldi ve orada kaldı. 07:57'te, Docker işlerinin sayısı büyümeye başladı ve onunla birlikte gül bekliyordu. Otomatik bir uyarı sayfası 08:08'de on-call mühendisini buldu. 08:42'de bir olayı ilan ettik. 08:43'te, mühendisler zamanlama sunucuları üzerinde yüksek disk gecikme tespit etti. İlk olarak disklerin yük için çok yavaş olduğuna inandılar, bu yüzden daha hızlı bir disk türüne bir değişiklik hazırladılar. 09:01'de ekip iki iş akışlarında anlaştı: sunucuları daha hızlı disklere taşıdı ve ikinci bir Gen 2 küme ekledi, böylece işler iki küme arasında bölündü. 09:41'te mühendisler kök nedenini buldular. Her zamanlama sunucusu doğrudan ona eklenmiş hızlı disklere sahiptir ve programcı, çalışma verilerini orada tutmak anlamına gelir. Bu sunucular bir güvenlik korumalı işletim sistemi görüntüsü üzerinde çalışır ve bu görüntüde hızlı diskler kullanılmamıştır. Programcı verileri daha yavaş ağ tabanlı disklere yazdı. Hızlı diskleri oluşturan senaryo bir hata olmadan başarısız oldu ve bu sunucularda giriş sırasında bir boşluk başarısızlık sakladı. Gen 2 trafiği de giderek daha fazla patlamaya başlamıştı. Bu patlamalar sırasında yavaş diskler doymuş ve programcı geride kaldı. Gen 2 orta kaynak sınıfındaki işler 30 dakikaya kadar beklendiğinde, 09:54'de zaman zirveye çıktı. 09:55 yılında, mühendisler hızlı diskleri doğru bir şekilde oluşturan bir düzeltme uyguladılar. 10:11'de, programcı işleri daha hızlı dağıtmaya başladı, bu da sunucuların yeni işlerle devam edebileceğini doğruladı. Gen 2 ortamı için zaman beklemek 10:17'de 13 dakikaya düştü ve 10:20'de 1 dakika 30 saniye. 10:24'de izlemek için statü sayfasını taşıdık ve olayı 10:45'te çözdük. 11:20'de ikinci Gen 2 küme iş koşmaya başladı. ## ** 7 Ekim 13:27 to 14:06: Elevated makine işleri için zaman bekliyor Yüksek kuyruk ve bekleme sürelerini gördükten sonra 13:27'de bir olayı ilan ettik. 13:31'de durum sayfasına gönderildik. 13:31'de, mühendisler makine işleri için sanal makineleri elde etmek için mücadele ettiğimizi gördü ve başlamak için bekleyen iş sayısı ağırlıklı olarak makine işleri için yüksekti. 13:34'te, bekleme süreleri executors arasında yükseldi. 13:48'de, bekleme süreleri daha fazla makine olarak iyileşmeye başladı ve olayı 14:06'de çözdük. ## ** 7 Ekim 14:24 to 15:21: İş başarısızlıkları ve iş akış gecikmeleri** Daha önceki olayın çözülmesinden kısa bir süre sonra, infaz sistemlerimize sunulan iş sayısına keskin bir düşüş nedeniyle 14:24'te yeni bir olay ilan ettik. 14:26 yılında, mühendisler iş yapılandırma servisinin podslarının yeniden başlatıldığını gördü. Tekrarlanan Pods, taleplere cevap vermek için hizmetin daha az kopyasını terk eder ve tekrarlanan girişimlerden sonra konfigürasyonlarını alamayan işler altyapı hatasıyla başarısız olur. Zaten çalışan iş akışları, başlamamış olan işlerden güncelleştirmeler için bekledi. 14:35'te mühendisler mevcut hafıza miktarını pods'a yükseltti ve yükü paylaşmak için daha fazla kopya verdi. Ayrıca mevcut iş tekliflerinin miktarı iyileşmeye başladı ve iş akışı sistemimiz aracılığıyla akan mesajlar sayısı normal seviyelere döndü. 14:44 yılında, durumu izlemek için taşıdık. İş yapılandırma servisindeki Pods hafıza sınırlarına ulaştı ve yeniden başladı. hafıza tahsislerini ve pod sayılarını artırdık ve hizmet iyileşti. 15:13'te, Gen 2 Docker kümelerindeki vaka sayısını artırdık, böylece işleri hızlı bir şekilde beklemeye çalıştık. Olayı 15:21'de çözdük. ## ** 7 Ekim 18:49 to 20:05: Docker Gen 2 iş için bekleme süreleri * Docker Gen 2'den sonra 18:49'da yeni bir olay ilan ettik. 18:51'de mühendisler, mevcut örneklerin eksikliğinin bizi yeterince satın almadan koruduğunu doğruladılar, ki bu da bekleme süreleri yükseltti. Zamanlar kaynak sınıfı büyüklüğü tarafından farklılık gösterir. 19:52'te, ortalama bekleme süreleri daha fazla kapasite mevcut olduğu bir saatten daha düşüktü, ancak kısa çatlaklar devam etti ve durumu izlemek için değiştirdik. Olayı 20:05'te çözdük. ## ** 8 Ekim: Linux makinesi ve uzaktan Docker işleri 50 dakikaya kadar bekler Makine ve uzaktan Docker işleri için çok sayıda iş gördükten sonra 12:48'de bir olay ilan ettik. 12:49'da mühendisler, bulut sağlayıcımızın yeterince örnek oluşturamayacağını gördü. Gecikmeler araştırdığımız gibi tırmanmaya devam etti. 13:13'te, ilk seçimimiz kullanılamadığında farklı bir örnek türü veya bölgeyi seçen mantığı incelemeye başladık. 13:24'te, bu mantıkta bir hatanın bizi birincil bölgemizde başka örnek tiplerini kullanmaktan alıkoyduğundan şüphelendik, bu yüzden geri çekilme bölgemizi devre dışı bıraktık ve kusurların nedenini doğruladık. Mühendisler bir düzeltme üzerinde çalışmaya başladı ve 14:49'da kullandı. Servis diğer örnek tiplerini talep etmeye başladı ve büyük sayılarda makinelere başladı. 14:58'de, bir makine için bekleyen işlerin kuyruğu sürekli düştü. Kaynakların sınıflarındaki ortalama bekleme süreleri bir sonraki saat boyunca bekleme işleri hakkında çalıştık. 16:00'da, bir makine için bekleyen işlerin kuyruğu temizlendi ve bekleyen işlerin sayısı normale döndü. 16:09'da izleme ve olayı 16:35'te çözdük. # **Future Prevention and Process Improvement** İş direncini güçlendirmek için aşağıdaki adımları atıyoruz, çeşitlendirme, geri dönüşüm mantığı ve daha önceki algılama dahil. ** Hesap bölgelerimizi genişletiyoruz. ** 7 Ekim ve 8 Ekim olaylarında, bulut sağlayıcımız kullandığımız bölgelerde yeterince örnek veremezdi. Yeni bölgeleri, tercih bölgelerimizi dışarı çıkarmak için geri çekilme mantığımıza ekliyoruz. ** Farklı bir örnek türü seçtiği mantığı düzeltiyoruz.** 8 Ekim'de, bir hata aynı bölgede diğer örnek tiplerini kullanmaktan makine düzenleme hizmeti tuttu. Olay sırasında bir düzeltme yaptık ve şimdi bu mantığı bir bütün olarak gözden geçiriyoruz, testlerle, bu yüzden bir örnek türün eksikliği başka bir işe yaramıyor. **Ek kapasiteyi teklif ettiğimiz ve garanti ettiğimiz örnek türleri genişletiyoruz.** Mevcut bölgelerimizde ek kapasiteyi rezerve etmek için bulut sağlayıcımızla çalışıyoruz ve işlerin çalıştırabileceği örnek tipler ekliyoruz. Yüksek performanslı hesaplama için endüstri talebi büyüyor. Nerede ve nasıl kaynaklandığımızı çeşitlemekteyiz, böylece müşterilerimiz tedarik varyasyonundan vazgeçiliyor. **İkinci bir Gen 2 Docker kümesi ekledik, böylece trafik patlamaları iki küme arasında dağıtılıyor. ** Ayrıca sunucu disk saturasyon konusunda uyarılar ekliyoruz ve programcı yerlerin ne kadar hızlı çalıştığını ve bir sunucunun kullanımında hızlı diskler olmadan başladığı zaman yangınların ne kadar hızlı başladığı konusunda uyarı ekliyoruz. Disk kurulum senaryosu bir hatayla başarısız oldu ve bu sunuculardan günlük gönderimi geri aldık, böylece benzer bir problem daha erken görünür. Müşteri deneyimi bizim en önemli önceliğimizdir ve müşterilerimizin içimizde yer aldığı güvenle eşleşmesi için sistemlerimizin güvenilirliğini sürekli olarak geliştirmeye çalışıyoruz. Müşterilerimize sabrı için teşekkür ederiz, ekibimiz bu olayları çözmeye çalıştı. Lütfen destek ekibimize herhangi bir soru veya endişelerle ulaşabilirsiniz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 6 Ekim 2026 16:00 UTCinvestigating

   What's impacted UI veri ekranı, outbound bildirimleri ve dışa dönük webho.oks dahil olmak üzere, CircleCI boru hatları ve iş akışlarını kullanan müşteriler. Ne bekleyebilirsin Boru hatlarındaki gecikmeler oluşturulmakta ve başlangıçta iş akışlarında ve işlerde. İş, iş akışı ve boru hattı verileri UI'de görünmek için 15 dakika sürebilir. Outbound bildirimleri ve webhookslar 1 dakikaya kadar ertelenir. Sonraki güncelleme 30 dakika içinde başka bir güncelleme yapacağız ya da paylaşmak için daha fazla bilgimiz var.

2. 6 Ekim 2026 16:10 UTCinvestigating

   15:47 UTC'den bu yana, müşteriler daha önce bildirilen gecikmelere ek olarak başarısız işler de görebilirler. Mühendislerimiz konuyu araştırmaya ve azaltmaya devam ediyorlar.

3. 6 Ekim 2026 16:31 UTCidentified

   16:02 UTC olarak, boru hatları tamamen başarısız oluyor, bu noktada yeni iş veya iş yok. Bu daha önce bildirilen gecikmelere ek olarak. Mühendislerimiz sorunu azaltmak için çalışmaya devam ediyor ve sahip olduğumuz kadar yakında daha fazla bilgi paylaşacağız.

4. 6 Ekim 2026 16:42 UTCidentified

   16:39 UTC olarak, yeni boru hatları ve iş akışları için kurtarma görmeye başlıyoruz ve işler tekrar çalışmaya başlıyor. Mühendislerimiz kurtarma üzerinde çalışmaya devam ediyor ve sahip olduğumuz anda daha fazla bilgi paylaşacağız.

5. 6 Ekim 2026 17:21 UTCidentified

   Borular, iş akışları ve işler tekrar çalışıyor olsa da, müşteriler bir iş akışında iş arasında normal gecikmelerden daha uzun sürmeye devam edebilir ve gelen bildirimlerin yaklaşık 1 dakika ertelendiği bildirilir. Versiyon kontrol sisteminize bildirim ve durum güncellemeleri tekrar dışarı çıkmaya başlıyor. Mühendislerimiz tam bir kurtarmaya devam ediyorlar.

6. 6 Ekim 2026 18:04 UTCidentified

   Müşteriler, bir iş arasında iş arasında normal gecikmelerden daha uzun deneyimlemeye devam ediyorlar, ayrıca aşırı bildirimde gecikmeler. Size sabrınız için teşekkür ederiz, mühendislerimiz konuyu araştırmaya ve incelemeye devam ederken. Önümüzdeki 30 dakika içinde başka bir güncelleme paylaşacağız ya da daha fazla bilgi mevcut olursa er.

7. 6 Ekim 2026 18:55 UTCidentified

   Müşteriler, iş ve iş başlamadan önce normal gecikmelerden daha uzun deneyimlemeye devam ediyor, bazı durumlarda yaklaşık 30 dakika. Bu olayda daha önce geliştirilir, ancak gecikmeler kalır. Gecikmiş bildirimlerin gecikmeleri gelişmiştir. Sizin sabrınız için teşekkür ederiz, mühendislerimiz normal işi geri yüklemeye devam ederken çalışmaya devam ederler. Önümüzdeki 30 dakika içinde başka bir güncelleme paylaşacağız ya da daha fazla bilgi mevcut olursa er.

8. 6 Ekim 2026 19:16 UTCidentified

   Müşteriler gecikmeleri yaşamaya devam ediyorlar. Çoğu şimdi yaklaşık 20 dakika içinde başlıyor, olayda yaklaşık 40 dakikadan daha erken geliştirildi. Çok az sayıda iş akışı 1 saatten fazla bekleyebilir. Mühendislerimiz hizmet istikrarını gelişmiş değişiklikler yaptılar ve geri kalan gecikme, olay sırasında inşa edilen bir geri çalışmadan kaynaklanıyor. Arkalog azalır ve daha hızlı açıklığa odaklanırız. İlerleme devam ettikçe daha fazla bilgi paylaşacağız. Sizin sabrınız için teşekkür ederiz, mühendisler arkalog aracılığıyla çalışırken. Önümüzdeki 30 dakika içinde başka bir güncelleme paylaşacağız ya da daha fazla bilgi mevcut olursa er.

9. 6 Ekim 2026 19:51 UTCidentified

   Başlamak için iş ve iş için gecikmeler azalmaya devam ediyor. Çoğu şimdi yaklaşık 10 dakika içinde başlıyor, olayda yaklaşık 40 dakikadan daha erken geliştirildi. Çok az sayıda iş akışı 1 saatten fazla bekleyebilir. İşiniz başlamazsa, lütfen işi yeniden çalıştırın. Gecikmiş bildirimlerin gecikmeleri gelişmiştir. Kalan gecikme, olay sırasında inşa edilen bir geri çalışmadan kaynaklanıyor ve bu gerilog yarıdan fazla azaltıldı. Arkalogun yaklaşık 15 dakika içinde temizlenmesini bekliyoruz. Bir sonraki 30 dakika içinde temizlendikten sonra başka bir güncelleme paylaşacağız.

10. 6 Ekim 2026 20:13 UTCidentified

    Gecikmiş çalışmanın backlogu temizlendi ve iş akışları bildirimde gecikmelerle tekrar başlıyor. Bununla birlikte, Docker ve Linux işlerini çok sayıda kaynak sınıflarında kullanan müşteriler, orta, büyük ve 2xlarge gen2 dahil olmak üzere, şimdi başlangıçlarından birkaç dakika önce bekleyen işleri görebilirler. Mühendislerimiz bu sorunu azaltmak için çalışmaya devam ediyorlar. İşiniz başlamazsa, lütfen işi yeniden çalıştırın. Sizin sabrınız için teşekkür ederiz, mühendislerimiz bu konuda çalışırken. Önümüzdeki 30 dakika içinde başka bir güncelleme paylaşacağız ya da daha fazla bilgi mevcut olursa er.

11. 6 Ekim 2026 20:31 UTCmonitoring

    İş akışları ve işler normalde başlıyor ve Docker ve Linux işleri için zaman beklemek normale döndü. Mühendislerimiz bu konuyu izlemeye devam ediyorlar. İşiniz başlamazsa, lütfen işi yeniden çalıştırın. Sizin sabrınız için teşekkür ederiz, mühendislerimiz bu konuda çalışırken. Önümüzdeki 30 dakika içinde başka bir güncelleme paylaşacağız ya da daha fazla bilgi mevcut olursa er.

12. 6 Ekim 2026 21:18 UTCresolved

    6 Ekim'de yaklaşık 15:30 UTC ve 20:30 UTC arasında, 2026, müşteriler boru hatları, iş akışları ve işleri etkileyen gecikmeler yaşadı. Yaklaşık 16:02 UTC'den 16:39 UTC'ye kadar, boru hatları başarısız oldu ve yeni akışlar veya işler başlayabilirdi. Servis başladıktan sonra, iş akışları ve işler yaklaşık 20:00 UTC'ye kadar gecikmelerle başlamaya devam etti. Zamanları zirvelerinde yaklaşık 40 dakikaya kadar sürdü ve çok az sayıda iş akışı 1 saatten fazla bekledi. Outbound bildirimleri ve webhooks da yaklaşık 19:00 UTC'ye kadar ertelendi, genellikle bir dakika. Gecikmiş çalışmanın arkalogu temizlendikçe, uygulama kapasitesimize yerleştirilen baskıyı talep eden artış, Docker ve Linux işleri için daha fazla gecikmeye neden oldu. Yaklaşık 19:45 UTC'den 20:30 UTC'ye kadar, bu işler başlamadan önce kuyrukta bekledi. zirvede, yaklaşık 20:05 UTC, 2xlarge gen2 için yaklaşık 8 dakikaya ulaştı, xlarge gen2 için 6 dakika ve birkaç başka kaynak dersi için 5 dakikadan daha az. Sorun çözüldü ve etkilenen tüm işlevsellik normale döndü. Bu pencere sırasında başarısız olan müşteriler etkilenen işleri geri alabilir. Size sabrınız için teşekkür ederiz, ekibimiz bir düzeltme uygulamak için çalıştı.

13. 7 Ekim 2026 22:08 UTCpostmortem

    # # # Özet 6 Ekim 2026'da, 15:30'dan 20:30'a kadar, CircleCI müşterileri boru hatları ve iş akışları yaratma gecikmeleri yaşadı. 15:48'den 16:38 UTC'ye kadar, hiçbir iş veya iş başladı ve 16:02 UTC'den kaynaklanan boru hatları başarısız oldu. Kısa, aralıklı gecikmeler daha önce başladı, 13:30 UTC. CircleCI UI'deki veriler, bildirimler ve sürüm kontrol sağlayıcıları için durum güncellemeleri de gecikti. Olay, iş akış orkestrası servisimizin arkasındaki veritabanında başladı, bu da her boru hattını, CircleCI'de iş koordine ediyor. Veritabanının en büyük masalarında Routine bakımı, veritabanının onları arşivleyebileceğinden daha hızlı işlem günlerini yazdı ve depolama hacminin onlar için bir kenara çıkmasını sağladı. Veritabanı sadece okumaktan alıkoymak için, mühendisler veritabanının ana depolama hacmine girişleri taşıdılar. Bu hareket 50 dakika boyunca veritabanı çevrimdışı aldı. Veritabanı geri geldiğinde, mühendislerimiz 18:19 UTC'de bir veritabanını değiştirinceye kadar normal oranını yaklaşık yarısı işledi. Daha sonra backlog aracılığıyla çalıştık ve iş zamanları 20:30 UTC tarafından normale döndü. Bu pencere sırasında başarısız olan müşteriler onları yeniden çalıştırabilir. Orijinal statü sayfası [burada] (https://status.circleci.com/incidents/z4hbq8h49j8c). # # # Bir boru hattını tetiklediğiniz zaman, CircleCI onu bir iş akışı orkestrası hizmetine elleştirir. Bu hizmet her iş akışını ve işin durumunu izler, her işin koşmaya hazır olduğunda karar verir ve uygulama filosumuza hazır işleri geçer. Ayrıca UI'de ve bildirimde gördüğünüz iş verilerini ve iş bittiği zaman gönderdiğimiz statüleri de etkiliyor. orkestra hizmeti, devletini bir veritabanında saklar. Veritabanı, uygulamadan önce bir işlem gününe her değişikliği yazar ve bu günlükleri özel bir depolama hacmine tutar. Kayıtları sürekli olarak arşivler, böylece bu alanı yeniden kullanabilir. Eğer arşivleme geride kalır ve hacim doldurursa, veritabanı yazar kabul etmeyi bırakır ve yeni bir iş ileri gidemez. Veritabanı ayrıca her masada iç kayıtları zamanında geçerli tutmak için periyodik bir bakım süreci \(autovacuums\) yürütüyor. Çok büyük bir masada, bu süreç masanın her sayfasını okur ve büyük bir işlem günlüklerini yazıyor. # # What Happened \(All times UTC\) 6 Ekim'de 10:02'den itibaren, izlememiz orkestration servisindeki hatalar hakkında kısa ömürlü uyarılar yükseltti. Her uyarı yaklaşık 15 dakika içinde kendi başına temizlendi. Mühendislerimiz daha önce benzer kısa uyarıları görmüştü ve sistem stresin başka bir belirtisi göstermedi, bu yüzden her seferinde runbook'u takip ettiler ve her uyarıyı kendi tarafında temizlediler ve ayrıca uyarıları daha az hassas hale getirmeye başladılar. Yaklaşık 12:40, kendi işlem loglarını üreten düzenli iş yükü ile birlikte, veritabanının en büyük masalarının birkaçı üzerinde bakım süreci, veritabanının onları arşivleyebileceğinden daha hızlı yazmaya başladı ve günlük hacmi doldurmaya başladı. 13:30'da, orkestratasyon servisi yavaşlamaya başladı. 15:30'da, bazı boru hatları ve işler daha uzun sürdü, kısa patlamalarda. 13:35'te, izlememiz tekrar uyarılandı, bu sefer diğer birkaç hizmetten ilgili uyarılarla birlikte. Altyapı Mühendisleri uyarı yayın kitaplarını takip ettiler, bazı uyarıları açıklayın. Uyarılar yaklaşık 14:30'da tekrar döndü ve daha sonra 14:54'te bir olay ilan ettik. Uyarıların kombinasyonlarını daha önce tanımalıyız ve aşağıda nasıl düzelteceğimizi ele aldık. Olayı ilan ettikten sonra, mühendisler bakım sürecine yavaşlamayı izlediler (anti-wrap around autovacuum\). Veritabanı bu süreci otomatik olarak iptal edilirse yeniden başlatır, bu yüzden mühendislerimiz daha hızlı bitirmek için ayarlarını değiştirdi. 15:30'a kadar gecikmeler sürekli oldu ve bazı işler başarısız olmaya başladı. 15:43'te, işlem günlük hacmi tam olarak yakındı. Eğer doluysa, veritabanı yazarı kabul etmeyi bırakacaktır ve hiçbir iş çalıştıramaz. Mühendislerimiz işlem günlerini veritabanının ana depolama hacmine taşımaya karar verdi, ki bu çok sayıda ücretsiz alana sahipti. Hareket, veritabanının çevrimdışı olmasını gerektiriyordu ve bunun ne kadar süreceğini önceden tahmin edemiyorduk. Hareket 15:47'de başladı. 15:48'den 16:38'e kadar, orkestratasyon hizmeti herhangi bir iş yapamazdı. Müşteriler hala boru hatları tetikleyebilir, ancak hiçbir iş veya iş başladı ve 16:02 yeni tetiklenen boru hatları başarısız oldu. 15:58'de durumu sayfamıza gönderildik ve 16:20'de büyük bir kesintiye yükselttik. Veritabanı çevrimdışı olsa da, mühendislerimiz bir geri dönüş veritabanı hazırladı. Orijinal veritabanı ilk olarak geri döndü, bu yüzden bunu hizmette tuttuk. 16:38'de, veritabanı online geri döndü ve tekrar akmaya başladı. İşlem logları ve düzenli veriler şimdi aynı depolamayı paylaşıyor, veritabanı daha önce daha yavaş koştu. 16:38'den 18:19'a kadar, orkestration servisi normal oranının yarısını işledi ve işler başlamak için on dakika bekledi, en uzun süre yaklaşık 50 dakika bekledi. Bu süre zarfında, veritabanı, onları özel bir hacime geri döndürebilmeden önce geri işlem günlüklerini arşivlemek zorunda kaldı. Ayrıca, daha fazla bakım çalışmasını durdurmak için birkaç veritabanı parametre değişikliği de araştırdık, hizmete ulaşma çalışmalarını azaltmak için başlangıç ve hazır yollar. Yedek veritabanı ile birlikte, bu süre boyunca hizmetin tam bir yığınını hazırladık, böylece veri kaybı riski altında hareket edebilir ve bu harekete karşı tercih ederiz. 18:19 yılında, mühendislerimiz her yaz depolamayı bekleyen bir veritabanını kesmek için bir veritabanı değiştirdi. İşleme hızı iyileşti ve backlog açıklığa başladı. Daha hızlı temizlemek için, uygulama filomuza el işi olan sistemlere veritabanı ve sunucu kapasitesi ekledik. Yaklaşık 19:55'e kadar, yeni işler tekrar zamanında başlıyordu. Arkalog daha sonra yürütme filosumıza ulaştı. 19:49'dan 20:30'a kadar, daha büyük kaynak sınıflarında bazı Docker işleri kapasite ölçeklendikçe başlamak için yaklaşık 10 dakika bekledi. 20:30'a kadar, işler normale geri döndü. 20:32'de izlemek için statü sayfasını taşıdık ve olayı 21:19'da çözdük. Olay sırasında yaklaşık 3,500 iş başlamadı. Müşteriler bu işleri yeniden çalıştırabilirler. CircleCI'nin bir kereden daha fazla iş oynadığına dair hiçbir kanıt bulamadık. Orijinal koşmanın devam ettiği bir iş akışı yeniden satın alan müşteriler her ikisini de tam olarak görebilirler. Yıllık plan müşterileri, hesap ekibiyle yeniden kullanım için çalışabilirler. ## Future Prevention and Process Improvement Bir recurrence önlemek ve cevabımızı geliştirmek için aşağıdaki adımları alıyoruz: **Bu olayın sebep olduğu koşullarda uyarı ekliyoruz. ** İzlememiz yavaşlamayı yakaladı, ancak işlem günlük hacminin ne kadar dolu olduğunu ya da ne kadar arşivlemenin geride kaldığı konusunda hiçbir uyarımız yoktu. Her ikisinde de uyarılar ekliyoruz, onları yönlendiren veritabanı bakımı konusunda uyarılar yapıyoruz, bu yüzden daha önce hareket edebiliriz. Ayrıca, gürültülü veya hassas uyarıların gerçek sorunları saklamamasını sağlamak için tüm uyarılarımızı tekrarlıyoruz. ** bakım sürecinin (autovacuum\) veritabanımızda nasıl çalıştığını ayarlıyoruz. ** Otovacuumların veritabanımızda çalıştığı frekansı ve saldırganlığı arıyoruz. Ayrıca bu tabloların boyutunu zamanında takip ediyoruz, böylece güvenli sınırlar içinde kalıyorlar. **Tek işlem log şişeneck kaldırıldık.** Tüm orkestration servisinin şu anda tek bir veritabanı ve bir işlem logu aracılığıyla gittiğini yazıyor, bu yüzden o gün geride kaldığı zaman, her boru hattı, iş akışı ve işi onunla yavaşladı. İki yaklaşımı değerlendiriyoruz: Birden fazla veritabanı örneği ile hizmeti bölmek, her biri kendi işlem günlüğü ile ve birçok düğümde yazmaya inşa edilen dağıtılmış bir veritabanına taşımak. Ya yaklaşım, iş yükünün bir parçası için bir backlog etkisini sınırlayacaktır. **Sistemlerimizi kurtarmak için orkestration servisi için bekliyoruz.** Olay sırasında, bazı işler başarısız oldu çünkü sistemimiz yeniden denemeden sonra vazgeçti. Bu davranışı değiştirmek üzerinde çalışıyoruz. ** Uzun olaylar sırasında durum sayfa güncellemelerimizi geliştiriyoruz. ** Müşteriler bize erken güncellemelerimiz yeterince detay vermedi. Rehberimizi güncelliyoruz, böylece güncellemeler belirli etki ve zamanlamayı daha erken içerir. Müşteri deneyimi bizim en önemli önceliğimizdir ve müşterilerimizin içimizde yer aldığı güvenle eşleşmesi için sistemlerimizin güvenilirliğini sürekli olarak geliştirmeye çalışıyoruz. Müşterilerimize sabrı için teşekkür ederiz, ekibimiz bu olayı çözmeye çalıştı. Lütfen destek ekibimize herhangi bir soru veya endişelerle ulaşabilirsiniz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 1 Ekim 2026 09:06 UTCinvestigating

   Müşteriler, Docker Gen 2 Jobs'a başlayan gecikmeleri yaşayabilirler. Sistemin throughputunu bunu anmak için çalışıyoruz.

2. 1 Ekim 2026 09:47 UTCidentified

   Kök nedenini tespit ettik ve aktif olarak bir düzeltme üzerinde çalışıyoruz. Sabrınız için teşekkür ederiz.

3. 1 Ekim 2026 10:13 UTCidentified

   Bir düzeltme yapıldı ve kurtarmayı gözlemlemeye başlıyoruz.

4. 1 Ekim 2026 10:24 UTCmonitoring

   Kuyruk zamanlarını normal seviyelere geri görüyoruz ve izlemeye devam ediyoruz.

5. 1 Ekim 2026 10:45 UTCresolved

   Bu olay çözüldü.

6. 9 Ekim 2026 22:36 UTCpostmortem

   # **Summary** 1 Ekim ve 8 Ekim 2026 arasında, CircleCI müşterileri, hangi işlerin başlamak için normalden daha uzun süre beklediği beş ayrı olay yaşadı veya başlamadı. Olayların üçü, bulut sağlayıcımızdan sınırlı örnek kullanılabilirlik tarafından yönlendirildi. Biri, zamanlama altyapısımızda bir yapılandırma konusu tarafından ve olay sırasında büyüttüğümüz bir iç hizmette bellek sınırları tarafından kaynaklandı. * ** 1 Ekim 07:57 ila 10:24 UTC:** Docker Gen 2 işleri başlamak için 30 dakika bekledi. Bir yapılandırma konusu, Gen 2 zamanlama sunucularını yüksek performanslı yerel disklerini kullanarak engelledi. Trafikte bir patlama sırasında, geri dönüş diskleri doygun ve iş yerleştirme yavaşladı. * ** 7 Ekim 13:27 - 14:06 UTC:** Makine işleri normalden daha uzun bekledi çünkü bulut sağlayıcımızdan yeterince sanal makine elde edemedik. * ** 7 Ekim 14:24 15:21 UTC:** Bazı işler bir altyapı hatasıyla başarısız oldu ve iş akışları gecikti. Her işi başlangıçtaki yapılandırmasını sağlayan hizmet hafızadan çıktı ve yeniden başladı. * ** 7 Ekim 18:49 - 20:05 UTC:** Docker Gen 2 işleri normalden daha uzun bekledi çünkü bulut sağlayıcımızdan yeterince örnek alamadık. * ** 8 Ekim 12:48 to 16:00 UTC:** Linux makinesi işleri ve uzaktan Docker işleri başlamak için 50 dakika bekledi. Bulut sağlayıcımız, talep ettiğimiz örnek türünden yeterince sahip değildi ve farklı bir örnek türü seçmek bizi alternatifleri kullanarak tuttu. Bu olaylar sırasında bekleyen işler gecikti, kaybolmadı. İşleri 7 Ekim'de bir altyapı hatasıyla başarısız olan müşteriler 14:24'den 15:21 UTC'ye geri dönebilirler. Orijinal statü sayfaları aşağıda bulunabilir: * [1 Ekim - Gen 2 Docker Jobs'a başlayan gecikmeler] (https://status.circleci.com/incidents/22mrv46g6n7g) * [ 7 Ekim - Makine İş Görevleri Üzerine Gecikme] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [ 7 Ekim - Elevated level of infra failing on müşteri işleri] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [ 7 Ekim - Docker Gen2 için artan bir görev bekleme süreleri] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [ 8 Ekim - Elevated wait times for machine jobs](https://status.circleci.com/incidents/jn756xtsy4xg) # **Background** CircleCI üzerinde çalışan her iş hesaplamaya ihtiyaç duyar. Bu hesaplama nereden geliyor executor. Docker işleri, zamanlamanın belirli bir filo üzerinde çalıştığı sunucu kümeleri üzerinde çalışır. Programcı, hangi örneği her işi yürüten bu sunuculardaki yazılımdır. Gen 2 Docker işleri, 1 Ekim olayında böyle bir kümede koştu. Gen 1 Docker işleri birkaç kümeye yayılmıştır. Uzak Docker işleri de dahil olmak üzere makine işleri, özel bir sanal makine almak. Uzak Docker işi, bir Linux makinesi işi olarak düzenleme yoluyla yapılır. Makine düzenleme hizmetimiz, normalde makine işleri için kullandığımız iki bölgeden birinde bulut sağlayıcımızdan her makine talep eder. Sağlayıcı, talep ettiğimiz örnek türü tedarik edemezse, hizmet geri düşer: farklı bir örnek türü veya farklı bir bölgeye, koruduğumuz bir listeden. Bir makine mevcut olana kadar bir iş bekler. Herhangi bir iş başladığında, yapılandırması için bir iş yapılandırma hizmeti sorar. Bu hizmet aynı programın küçük kopyaları olan pods seti olarak çalışır. Çok fazla pods dursa, kalan pods daha fazla yük taşır ve işler servis geri dönene kadar başlayabilir. Bu yollar üç tür kapasiteye bağlıdır: zamanlama sistemlerimizin yönlendirmesi, bulut sağlayıcımızdan örnek tedariki ve işe başlayan hizmetlerin hafıza ve sayısı. Bunlardan herhangi birinde kısa bir düşüş, iş bekleyen veya başarısız olur. # ** What Happened** \(All times UTC\) ## ** Ekim 1: Docker Gen 2 işleri 30 dakikaya kadar gecikti** 07:44'te, Gen 2 Docker işlerini yapan sunucularda disk aktivitesi kapasitenin %90'ına yükseldi ve orada kaldı. 07:57'te, Docker işlerinin sayısı büyümeye başladı ve onunla birlikte gül bekliyordu. Otomatik bir uyarı sayfası 08:08'de on-call mühendisini buldu. 08:42'de bir olayı ilan ettik. 08:43'te, mühendisler zamanlama sunucuları üzerinde yüksek disk gecikme tespit etti. İlk olarak disklerin yük için çok yavaş olduğuna inandılar, bu yüzden daha hızlı bir disk türüne bir değişiklik hazırladılar. 09:01'de ekip iki iş akışlarında anlaştı: sunucuları daha hızlı disklere taşıdı ve ikinci bir Gen 2 küme ekledi, böylece işler iki küme arasında bölündü. 09:41'te mühendisler kök nedenini buldular. Her zamanlama sunucusu doğrudan ona eklenmiş hızlı disklere sahiptir ve programcı, çalışma verilerini orada tutmak anlamına gelir. Bu sunucular bir güvenlik korumalı işletim sistemi görüntüsü üzerinde çalışır ve bu görüntüde hızlı diskler kullanılmamıştır. Programcı verileri daha yavaş ağ tabanlı disklere yazdı. Hızlı diskleri oluşturan senaryo bir hata olmadan başarısız oldu ve bu sunucularda giriş sırasında bir boşluk başarısızlık sakladı. Gen 2 trafiği de giderek daha fazla patlamaya başlamıştı. Bu patlamalar sırasında yavaş diskler doymuş ve programcı geride kaldı. Gen 2 orta kaynak sınıfındaki işler 30 dakikaya kadar beklendiğinde, 09:54'de zaman zirveye çıktı. 09:55 yılında, mühendisler hızlı diskleri doğru bir şekilde oluşturan bir düzeltme uyguladılar. 10:11'de, programcı işleri daha hızlı dağıtmaya başladı, bu da sunucuların yeni işlerle devam edebileceğini doğruladı. Gen 2 ortamı için zaman beklemek 10:17'de 13 dakikaya düştü ve 10:20'de 1 dakika 30 saniye. 10:24'de izlemek için statü sayfasını taşıdık ve olayı 10:45'te çözdük. 11:20'de ikinci Gen 2 küme iş koşmaya başladı. ## ** 7 Ekim 13:27 to 14:06: Elevated makine işleri için zaman bekliyor Yüksek kuyruk ve bekleme sürelerini gördükten sonra 13:27'de bir olayı ilan ettik. 13:31'de durum sayfasına gönderildik. 13:31'de, mühendisler makine işleri için sanal makineleri elde etmek için mücadele ettiğimizi gördü ve başlamak için bekleyen iş sayısı ağırlıklı olarak makine işleri için yüksekti. 13:34'te, bekleme süreleri executors arasında yükseldi. 13:48'de, bekleme süreleri daha fazla makine olarak iyileşmeye başladı ve olayı 14:06'de çözdük. ## ** 7 Ekim 14:24 to 15:21: İş başarısızlıkları ve iş akış gecikmeleri** Daha önceki olayın çözülmesinden kısa bir süre sonra, infaz sistemlerimize sunulan iş sayısına keskin bir düşüş nedeniyle 14:24'te yeni bir olay ilan ettik. 14:26 yılında, mühendisler iş yapılandırma servisinin podslarının yeniden başlatıldığını gördü. Tekrarlanan Pods, taleplere cevap vermek için hizmetin daha az kopyasını terk eder ve tekrarlanan girişimlerden sonra konfigürasyonlarını alamayan işler altyapı hatasıyla başarısız olur. Zaten çalışan iş akışları, başlamamış olan işlerden güncelleştirmeler için bekledi. 14:35'te mühendisler mevcut hafıza miktarını pods'a yükseltti ve yükü paylaşmak için daha fazla kopya verdi. Ayrıca mevcut iş tekliflerinin miktarı iyileşmeye başladı ve iş akışı sistemimiz aracılığıyla akan mesajlar sayısı normal seviyelere döndü. 14:44 yılında, durumu izlemek için taşıdık. İş yapılandırma servisindeki Pods hafıza sınırlarına ulaştı ve yeniden başladı. hafıza tahsislerini ve pod sayılarını artırdık ve hizmet iyileşti. 15:13'te, Gen 2 Docker kümelerindeki vaka sayısını artırdık, böylece işleri hızlı bir şekilde beklemeye çalıştık. Olayı 15:21'de çözdük. ## ** 7 Ekim 18:49 to 20:05: Docker Gen 2 iş için bekleme süreleri * Docker Gen 2'den sonra 18:49'da yeni bir olay ilan ettik. 18:51'de mühendisler, mevcut örneklerin eksikliğinin bizi yeterince satın almadan koruduğunu doğruladılar, ki bu da bekleme süreleri yükseltti. Zamanlar kaynak sınıfı büyüklüğü tarafından farklılık gösterir. 19:52'te, ortalama bekleme süreleri daha fazla kapasite mevcut olduğu bir saatten daha düşüktü, ancak kısa çatlaklar devam etti ve durumu izlemek için değiştirdik. Olayı 20:05'te çözdük. ## ** 8 Ekim: Linux makinesi ve uzaktan Docker işleri 50 dakikaya kadar bekler Makine ve uzaktan Docker işleri için çok sayıda iş gördükten sonra 12:48'de bir olay ilan ettik. 12:49'da mühendisler, bulut sağlayıcımızın yeterince örnek oluşturamayacağını gördü. Gecikmeler araştırdığımız gibi tırmanmaya devam etti. 13:13'te, ilk seçimimiz kullanılamadığında farklı bir örnek türü veya bölgeyi seçen mantığı incelemeye başladık. 13:24'te, bu mantıkta bir hatanın bizi birincil bölgemizde başka örnek tiplerini kullanmaktan alıkoyduğundan şüphelendik, bu yüzden geri çekilme bölgemizi devre dışı bıraktık ve kusurların nedenini doğruladık. Mühendisler bir düzeltme üzerinde çalışmaya başladı ve 14:49'da kullandı. Servis diğer örnek tiplerini talep etmeye başladı ve büyük sayılarda makinelere başladı. 14:58'de, bir makine için bekleyen işlerin kuyruğu sürekli düştü. Kaynakların sınıflarındaki ortalama bekleme süreleri bir sonraki saat boyunca bekleme işleri hakkında çalıştık. 16:00'da, bir makine için bekleyen işlerin kuyruğu temizlendi ve bekleyen işlerin sayısı normale döndü. 16:09'da izleme ve olayı 16:35'te çözdük. # **Future Prevention and Process Improvement** İş direncini güçlendirmek için aşağıdaki adımları atıyoruz, çeşitlendirme, geri dönüşüm mantığı ve daha önceki algılama dahil. ** Hesap bölgelerimizi genişletiyoruz. ** 7 Ekim ve 8 Ekim olaylarında, bulut sağlayıcımız kullandığımız bölgelerde yeterince örnek veremezdi. Yeni bölgeleri, tercih bölgelerimizi dışarı çıkarmak için geri çekilme mantığımıza ekliyoruz. ** Farklı bir örnek türü seçtiği mantığı düzeltiyoruz.** 8 Ekim'de, bir hata aynı bölgede diğer örnek tiplerini kullanmaktan makine düzenleme hizmeti tuttu. Olay sırasında bir düzeltme yaptık ve şimdi bu mantığı bir bütün olarak gözden geçiriyoruz, testlerle, bu yüzden bir örnek türün eksikliği başka bir işe yaramıyor. **Ek kapasiteyi teklif ettiğimiz ve garanti ettiğimiz örnek türleri genişletiyoruz.** Mevcut bölgelerimizde ek kapasiteyi rezerve etmek için bulut sağlayıcımızla çalışıyoruz ve işlerin çalıştırabileceği örnek tipler ekliyoruz. Yüksek performanslı hesaplama için endüstri talebi büyüyor. Nerede ve nasıl kaynaklandığımızı çeşitlemekteyiz, böylece müşterilerimiz tedarik varyasyonundan vazgeçiliyor. **İkinci bir Gen 2 Docker kümesi ekledik, böylece trafik patlamaları iki küme arasında dağıtılıyor. ** Ayrıca sunucu disk saturasyon konusunda uyarılar ekliyoruz ve programcı yerlerin ne kadar hızlı çalıştığını ve bir sunucunun kullanımında hızlı diskler olmadan başladığı zaman yangınların ne kadar hızlı başladığı konusunda uyarı ekliyoruz. Disk kurulum senaryosu bir hatayla başarısız oldu ve bu sunuculardan günlük gönderimi geri aldık, böylece benzer bir problem daha erken görünür. Müşteri deneyimi bizim en önemli önceliğimizdir ve müşterilerimizin içimizde yer aldığı güvenle eşleşmesi için sistemlerimizin güvenilirliğini sürekli olarak geliştirmeye çalışıyoruz. Müşterilerimize sabrı için teşekkür ederiz, ekibimiz bu olayları çözmeye çalıştı. Lütfen destek ekibimize herhangi bir soru veya endişelerle ulaşabilirsiniz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 23 Eylül 2026 18:13 UTCidentified

   Müşteriler, hesaplarına yansıyan yeni işaret ve plan değişikliklerinde gecikmeler yaşayabilirler.

2. 23 Eylül 2026 20:06 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 21 Eylül 2026 16:22 UTCinvestigating

   Müşteriler Linux Machine'deki işe başlamakta gecikme yaşayabilirler. araştırıyoruz.

2. 21 Eylül 2026 16:48 UTCmonitoring

   Linux Machine için görev süreleri normale dönüyor.

3. 21 Eylül 2026 17:09 UTCresolved

   This incident has been resolved.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 16 Eylül 2026 14:55 UTCinvestigating

   Boru hattı verilerinde gecikmeyi araştırıyoruz. Boru hatları hala çalışıyor, ancak bunlar hakkında veriler UI veya API'de gecikebilir.

2. 16 Eylül 2026 15:29 UTCidentified

   Sorunu tespit ettik ve bir remediasyon üzerinde çalışıyoruz. Sabrınız için teşekkür ederiz.

3. 16 Eylül 2026 17:34 UTCidentified

   Boru hattı verileri artık normal olarak mevcuttur, test sonuçları hariç, bu hala gecikebilir. Bu konuda çalışmaya devam ediyoruz, sabrınız için teşekkür ederiz.

4. 16 Eylül 2026 18:22 UTCmonitoring

   Tüm boru hatları verileri artık normal olarak mevcuttur. Kurtarmayı izlemeye devam edeceğiz.

5. 16 Eylül 2026 19:30 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 15 Eylül 2026 14:42 UTCinvestigating

   Şu anda UI'deki boru hatlarında gecikme görüyoruz.

2. 15 Eylül 2026 15:14 UTCidentified

   Bazı kurtarma görmeye başlıyoruz.

3. 15 Eylül 2026 17:02 UTCresolved

   UI'deki boru hattı verilerini etkileyen olay şimdi çözüldü. Mühendislerimiz gecikmeleri azaltmaya çalışırken sabrınız için teşekkür ederiz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 14 Eylül 2026 11:59 UTCinvestigating

   Artan ağ hataları ve latencies nedeniyle, MacOS işleri için daha fazla bekleme süresi görüyoruz. Bunu Mac hosting sağlayıcımızla araştırıyoruz.

2. 14 Eylül 2026 12:36 UTCinvestigating

   MacOS işleri için zaman beklemek azalır ve araştırmaya devam ediyoruz.

3. 14 Eylül 2026 12:48 UTCmonitoring

   Mac hosting sağlayıcımız bir mitigation uyguluyor ve gelişmiş latencies gördük. İzlemeye devam edeceğiz.

4. 14 Eylül 2026 12:59 UTCresolved

   MacOS işleri için zaman beklemek normale geri döndü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 10 Eylül 2026 20:25 UTCidentified

   Küçük sayıda müşteri hataları görebilir veya boru hatlarının sayfalarını, klasik boru hatları görüşünü kullanırken yükleyemez. Yeni boru hatlarındaki müşteriler etkilenmez. Nedeni tespit ettik ve bir düzeltme kurduk.

2. 10 Eylül 2026 20:25 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

3. 10 Eylül 2026 20:26 UTCresolved

   Bu olay çözüldü. 18:53 UTC ve 19:24 UTC arasında boru hatları oluşturan küçük bir müşteri sayısı, önceden belirlenmiş yapılandırma sözlüğü kullanılarak yapılandırılan yapılandırıcı işlerinin başlamayacağını görecek. İş veya boru hatları başarısız olan müşteriler onları yeniden çalıştırabilir.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 4 Eylül 2026 15:16 UTCinvestigating

   Mac altyapımızı etkileyen ağ sorunlarını tespit ettik. Biz araştırıyoruz ve kısa bir süre içinde güncelleştirmeler sağlayacaktır. Müşteriler bu süre zarfında queuing yaşayabilirler.

2. 4 Eylül 2026 15:43 UTCidentified

   Mac altyapı sağlayıcımızla ağ sorununu tespit ettik ve sorunu çözmek için onlarla çalışıyoruz. Bazı kurtarmayı görmeye başlıyoruz, ancak müşteriler hala bazı kuyrukları görebilir. Daha kısa bir süre içinde güncelleyeceğiz.

3. 4 Eylül 2026 16:19 UTCmonitoring

   Mac altyapı sağlayıcımız bu ağ konusu için bir düzeltme uyguladı ve kuyruk zamanlarını normale geri görüyoruz. Daha uzun süre şeylere göz atmaya devam edeceğiz. Daha kısa bir süre içinde güncelleyeceğiz.

4. 4 Eylül 2026 16:55 UTCresolved

   Zamanlara daha fazla etki görmedik ve her şey normale döndü. Bu sorunu çözmek ve izlemek için çalışırken sabrınızı takdir ediyoruz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 26 Ağustos 2026 15:43 UTCidentified

   Müşteriler, plan kullanımını takip ederken intermittent hatalarını deneyimleyebilir veya API'leri çağırabilir. Sorunu tespit ettik ve bu hataları azaltmak için aktif olarak çalışıyoruz.

2. 26 Ağustos 2026 16:04 UTCmonitoring

   Sorunu plan kullanımı API'leri ve UI'deki ilgili sayfaları doğru bir şekilde yükleriz.

3. 26 Ağustos 2026 16:10 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 25 Ağustos 2026 23:20 UTCresolved

   25 Ağustos'ta 19:49 UTC ve 21:07 UTC arasında 2026, müşteriler GitHub'ı kullanarak CircleCI'ye giriş yapmaya çalışıyorlardı ve çağrı URL'nin geçersiz olduğunu söyleyen GitHub'dan bir hata aldı. Zaten giriş yapan müşteriler etkilenmedi. Sorun çözüldü ve GitHub login normal olarak çalışıyor. Size sabrınız için teşekkür ederiz, ekibimiz bir düzeltme uygulamak için çalıştı.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 17 Ağustos 2026 21:06 UTCidentified

   Sorunun nedeni tespit edilmiştir ve bunu düzeltiyoruz.

2. 17 Ağustos 2026 21:36 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

3. 17 Ağustos 2026 21:37 UTCresolved

   İçgörü verileri bir kez daha iyidir. Sabrınız için teşekkür ederiz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.