Cycode kesinti geçmişi

1. 27 Ekim 2026 10:06 UTCinvestigating

   **Summary** Bitbucket'in kimlik doğrulama servisi 27 Ekim 2026'da, 03:45 UTC'de OAuth'u kullanan bazı Bitbucket Cloud entegrasyonları. **Impact** Etkilenen entegrasyonlar için Cycode Bitbucket'e erişemez. Scans, repository senkronizasyonlar ve entegrasyon tekrar yetkilendirilmiş olana kadar bu çalışma alanları için statüler işlemektedir. Uygulama şifrelerini kullanan entegrasyonlar, API jetleri veya çalışma alanı erişim jetleri etkilenmez. **Latest update** Araştırmamız Bitbucket'in bu entegrasyonlar için yeni bilgiler yayınladığını gösteriyor, ancak onları Cycode'a teslim etmedi, çünkü hizmeti bir hataya geri döndü. Bitbucket artık önceki bilgileri kabul etmiyor, bu yüzden entegrasyonlar otomatik olarak geri kazanamaz. Biz konuyu Atlassian’a rapor ediyoruz. **Action gereklidir** Bitbucket entegrasyonunuz, Cycode konsolunda tekrar yazarsa [Settings > Integrations > Bitbucket]. Cycode nerede durdu ve başka bir değişiklik gerekli değildir. Daha fazla bilgimiz olduğunda bir güncelleme yayınlayacağız.

2. 27 Ekim 2026 10:46 UTCmonitoring

   Her etkilenen entegrasyonu tespit ettik ve şimdi kullanıcıları doğrudan temasa geçiyoruz. Bir entegrasyon, kullanıcının onu [Settings > Entegrasyonlar > Bitbucket] altındaki Cycode konsolunda tekrar yazmaya başlar. Bitbucket hatasını Atlassian'a bildirdik ve daha fazla bilgimiz olduğunda bir güncelleme yayınlayacağız.

3. 27 Ekim 2026 12:51 UTCresolved

   Etkilenen Bitbucket Bulut entegrasyonları tespit edildi ve kullanıcıları tekrar bunları yazmaya yönelik talimatlar aldı. Tekrar normal olarak çalışmaya yetkili olan entegrasyonlar. Kök nedeni 27 Ekim 2026'da Bitbucket hizmet hatasıydı, 03:45 UTC'de, bazı entegrasyonların ayrıntılarını geçersiz kılan. Atlassian ile soruşturmaları için ayrıntıları paylaştık.

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

1. 20 Ekim 2026 09:28 UTCinvestigating

   Giriş akış sorunlarının potansiyel bir nedeni tespit ettik ve daha fazla araştırıyoruz.

2. 20 Ekim 2026 09:54 UTCinvestigating

   AB bölgesinde giriş akış sorununu çözdük.

3. 20 Ekim 2026 10:04 UTCmonitoring

   Sorun çözüldü ve sistemi istikrar sağlamak için izlemeye devam ediyoruz.

4. 20 Ekim 2026 15:43 UTCresolved

   Olay tamamen çözüldü ve daha fazla sorun görmüyoruz.

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

1. 18 Ekim 2026 13:10 UTCinvestigating

   PR tarama ve ihlal yük başarısızlıkları ile ilgili uygulamadaki hataları araştırıyoruz. Davayı bulduğumuzda daha fazla güncelleme yapmaya devam edeceğiz.

2. 18 Ekim 2026 13:26 UTCidentified

   Uygulama veritabanımızdan biriyle bir sorun yaşadık. Veritabanı normal operasyonlara geri döndü, ancak hala bozuldu ve bunu düzeltmek için aktif olarak çalışıyoruz. Platform normal operasyonlara geri döndü ve ihlaller ve PR taramaları normalde çalışmalıdır.

3. 18 Ekim 2026 13:34 UTCmonitoring

   Veritabanı normal operasyonlara geri döndü. Kalan sorunları olmadığından emin olmak için aktif olarak izliyoruz.

4. 18 Ekim 2026 14:40 UTCresolved

   Olay tamamen çözüldü ve daha fazla sorun görmüyoruz.

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

1. 13 Ekim 2026 12:56 UTCmonitoring

   **Monitoring**: tarama API (US region) Bugün uyarı sistemimiz, taramaların API'sinin arkasındaki hizmetin beklenenden daha sık yeniden başlatıldığını tespit etti, bu da bazı isteklerin kısa bir süre için başarısız olmasına neden oldu. Servise mevcut hafızayı artırdık ve o zamandan beri stabildi. Hizmeti, kalıcı bir gelişmeyi sonlandırırken yakın gözlem altında tutuyoruz.

2. 13 Ekim 2026 13:01 UTCresolved

   **Re solution**: Taramaların API'sinin (US bölgesinin) kısa yavaşlaması 13 Ekim 2026, 07:58 ve 08:28 UTC arasında, bazı istekler ABD bölgesinde tarama API başarısız oldu veya yavaştı. Cycode UI ve Cycode CLI'daki tarama sayfaları geçici hataları gösterebilir ve bazı çekme istek taramaları her zamankinden birkaç dakika sonra geldi. Mevcut hafızayı 08:34 UTC'de tam olarak çözdük. Tüm kuyruklı taramalar kısa bir süre sonra tamamlandı ve hiçbir veri kayboldu. Nedeni ve kalıcı bir gelişmeyi gözden geçirdik.

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

1. 13 Ekim 2026 08:30 UTCinvestigating

   GitLab şu anda Cycode PR tarama ve entegrasyon bağlantısını etkileyebilecek bir hizmet kesintisi yaşıyor. Sorun GitLab'un altyapısından kaynaklanır ve Cycode'un kontrolü dışındadır. Durumu takip ediyoruz ve GitLab normal hizmeti geri yüklemek için güncellemeler sağlayacaktır. Daha fazla bilgi için lütfen GitLab'un durumu sayfasına bakınız: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614 "https://status.com/ pages/sayfas/int/5b36dc2082d06804c083

2. 13 Ekim 2026 08:47 UTCmonitoring

   GitLab, PR taramasını etkileyen ve izleme aşamasına entegrasyonu etkileyen olayı taşıdı. GitLab bir düzeltme uyguladı ve sonuçları takip ediyor. Cycode entegrasyonu üzerindeki etkisini izlemeye devam ediyoruz ve gerekirse daha fazla güncelleme sağlayacaktır. Daha fazla bilgi için lütfen GitLab'un durumu sayfasına bakınız: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614 "https://status.com/ pages/sayfas/int/5b36dc2082d06804c083

3. 13 Ekim 2026 11:27 UTCresolved

   GitLab, PR tarama ve entegrasyon bağlantısını etkileyen olayı çözdü

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

1. 7 Ekim 2026 14:22 UTCinvestigating

   Ekip, konuyu içsel olarak tırmanan AWS ile çalışmaya devam ediyor. Paralel olarak, başka bir veritabanına hareket ederek işlevselliği geri yüklemek için çalışıyoruz. Cycode statüsünü bekleyen herhangi bir engel, Cycode taramalarını doğrudan SCM'nizde (Kaynak Kodu Yönetimi) kaldırarak engellenebilir. Süreç akışına yardımcı olmak için Cycode temsilcisine ulaşın.

2. 7 Ekim 2026 14:22 UTCinvestigating

   AWS, etkilenen PostgreSQL örneğinin şu anda içsel bir kurtarma durumunda olduğunu doğruladı. Beklenen Multi-AZ başarısızlığı tasarlandığı gibi gerçekleşmedi ve AWS neden aktif olarak araştırıyor. Paralel olarak, kurtarma yolunda alternatif bir veritabanı yolunu kullanarak etkilenen hizmetleri geri yüklemeye devam ediyoruz

3. 7 Ekim 2026 14:22 UTCinvestigating

   Veritabanının operasyonel kapablarını restore ettiğini görüyoruz. İlk Pull Request taramalarının işlendiğini görüyoruz. Sistemi takip ediyoruz ve aktarım yapıyoruz.

4. 7 Ekim 2026 14:22 UTCinvestigating

   Veritabanı tamamen operasyonel kalır. Tüm gerilogları mümkün olduğunca kısa sürede işlemek için normal işlem hızı üzerinde çalışıyoruz.

5. 7 Ekim 2026 14:22 UTCinvestigating

   PostgreSQL bağlantı egzozion nedeniyle ABD platformunda büyük bir bozulma incelemeye devam ediyoruz. Müşteriler yavaş yanıt süreleri, yüksek 500 hata ve daha yavaş PR iş akışları ve 97 taramaları yaşayabilirler. Birkaç servis boyunca veritabanı yükünü azalttık ve bir RDS başarısız başlattık. Ekip normal performansı geri yüklemek için aktif olarak çalışıyor.

6. 7 Ekim 2026 14:22 UTCinvestigating

   Prod-us Pull Request veya CLI tarama gibi akışlar her zamankinden daha yavaş olabilir

7. 7 Ekim 2026 14:22 UTCinvestigating

   Ekip aktif olarak AWS ile çalışıyor ve ABD ortamını etkileyen bir veritabanı başarısız sorunu olduğunu araştırıyor. Daha fazla bilgimiz olduğu sürece başka bir güncelleme paylaşacağız.

8. 7 Ekim 2026 14:22 UTCinvestigating

   ABD platformu daha önceki RDS/PostgreSQL bağlantı egzozunu takip ediyor. AWS, orijinal PostgreSQL örneğinin operasyonel bir duruma geri döndüğünü doğruladı ve PR taramalarının tekrar işlendiğini görüyoruz. Kalan bozulma, büyük bir webhook backlog nedeniyle GitHub-güdümlü işleme gecikiyor, ki bu da yok olmaya devam ediyor. Kurtarmayı izlemeye devam edeceğiz ve işlem normale dönerken başka bir güncelleme sağlayacağız

9. 7 Ekim 2026 14:22 UTCinvestigating

   Sistem tamamen operasyonel olmaya geri döndü

10. 7 Ekim 2026 14:22 UTCresolved

    (2/2) • Kısa süreli veri operasyonlarının yüksek hacimleri oluşturan iş yüklerini kullandı, gecikmiş olaylar silindiğinde veritabanı yükünü azaltmak için. • Olay sırasında kaçırılmış olan çekme taleplerini taradı. **4b. Action Elements ** • Veri kümelerinin veritabanı yükünü azaltmak için ne kadar büyük özetlendiğini değiştirin. • En yüksek hacimli iş yüklerimizi kendi özel veritabanına taşıyın, bu yüzden platformun geri kalanını etkilemez. • Veritabanı bağlantı kullanımı ve veritabanı sağlığı için uyarıları ve daha derin izleme ekleyin. • Her hizmeti kendi özel veritabanı bilgilerini verin. • Gelen olaylar bir kesintiden sonra kurtarmayı daha verimli bir şekilde gerçekleştirir. • İş gecikmelerinin ve içsel olay uyarılarının izlenmesi. • Daha fazla oda eklemek için veritabanı kapasitesi ve performans ayarları gözden geçirin.

11. 7 Ekim 2026 14:22 UTCresolved

    (1/2) **1. Özet** 5 Ekim 2026'da, 15:55 IDT'de başlayan, ABD platformumuzdaki müşteriler yavaş cevaplar gördü, geçici hatalar ve talep çeklerinde gecikmeler görüldü. Bazı müşteriler Cycode çekme istek kontrollerini gerektirir, tarama özgeçmişine kadar birleşemez. Sorun, birincil veritabanımızda bir arka plan bakım süreci geride kaldığı ve tamamlanmasının ardından başladı ve veritabanı yeni verileri kurtarmayı bıraktı. Restoring servisi birkaç saat sürdü, çünkü standby veritabanı ilk önce büyük bir geri dönüşüm sürecindeydi. Veritabanı geri döndü ve platform 19:43 IDT tarafından tekrar mevcuttu. Gecikmiş işleme sonra yakalandı ve olay 23:24 IDT'de çözüldü. Olay sırasında kaçırılan Pull talepleri tarandı. **2. Anahtar Zamanlı (IDT)** • ** 5 Ekim 2026, 12:55 IDT**: Rutin bir veritabanı bakım süreci normalden çok daha yavaş çalışmaya başlar. Henüz müşteri etkisi yok. • ** 5 Ekim 2026, 14:53 IDT**: Bir sonraki bakım döngüsü başlar ve tamamlanmaz. • ** 5 Ekim 2026, 15:55 IDT**: Veritabanı yeni verileri kurtarmayı durduruyor ve platform performansları bozuluyor. • ** 5 Ekim 2026, 16:03 IDT**: Veritabanı bağlantı limitine ulaşır. Müşteriler hataları görmeye başlar. • ** 5 Ekim 2026, 16:21 IDT**: Olay ilan etti ve yanıt ekibi meşgul etti. • ** 5 Ekim 2026, 16:24 IDT**: İlk güncelleme statü sayfasına gönderildi. • ** 5 Ekim 2026, 16:49 IDT**: standby veritabanına geçiş başladı. • ** 5 Ekim 2026, 17:00 IDT**: Bulut altyapı sağlayıcımızla açılan destek durumu. • ** 5 Ekim 2026, 18:24 IDT**: Alternatif kurtarma yolu paralel olarak başladı. Gerekli çekme talebi kontrolleri tarafından bloke edilen müşteriler için işbaşı. • ** 5 Ekim 2026, 19:43 IDT**: Veritabanı tekrar kullanılabilir ve Cycode API ve Cycode Platform erişilebilir. • ** 5 Ekim 2026, 19:54 IDT**: Pull request tarama özgeçmişleri. • ** 5 Ekim 2026, 20:20 IDT**: İşleme kapasitesi gecikmiş olayları temizlemek için arttı. • ** 5 Ekim 2026, 20:45 IDT**: Yüksek hacimli iş yükleri veritabanı yükünü azaltmak için durakladı. • ** 5 Ekim 2026, 21:56 IDT**: Pull talepleri tespit edildi ve tarandı. • ** 5 Ekim 2026, 23:09 IDT**: Tüm hizmetler tamamen operasyonel. • ** 5 Ekim 2026, 23:24 IDT**: Olay çözüldü. **3. Root Cause** Veritabanımız, kalıcı depolama için son değişiklikleri düzenli olarak kurtaran rutin bir arka plan süreci yürütüyor. Bu süreçte iki koşul yavaşladı: • **High-volume kısa ömürlü veri operasyonları: ** Bazı işlem iş yüklerimiz sürekli olarak çok sayıda kısa ömürlü veri yapısını yaratmak ve kaldırmaktı. • ** gecikmiş bir arka plan senkronizasyonu: ** Bir veri-seni süreci geride kaldı, bu da veritabanını kendi başına temizlemekten alıkoydu. Bakım süreci yavaşladı ve sonunda tamamlandı. Veritabanı daha sonra yeni veriler kurtaramadı ve istekler kuyruklara başladı. Hizmetlerimiz bu talepleri tekrarladı ve veritabanının bağlantı kapasitesini kullanan birçok yeni bağlantı açtı. Müşteriler bunu hataları ve yavaş cevaplar olarak gördüler. standby veritabanımıza geçtik. Trafik hizmet etmeden önce, son tamamlanmış bakım döngüsünden bu yana yapılan tüm değişiklikleri işlemek zorundaydı, yaklaşık dört saat aktivite. Bu, kesintiyi uzatmıştır. **4. Actions Taken** • Veritabanına geçici olarak ayarlanmamış işleme göre azaltın. • standby veritabanına bir geçiş başlattı. • Bulut altyapı sağlayıcımızla bir destek vakası açın ve onlarla birlikte tırmanan bir temel üzerinde çalıştı. • Paralel olarak alternatif bir kurtarma yolunu hazırlayın. • Gerekli çekme talebi kontrolleri tarafından bloke edilen müşteriler için geçici bir çalışma paylaşın. • Veritabanı kurtarıldığında, gecikmiş olayları temizlemek için işlem kapasitesi arttı.

12. 7 Ekim 2026 14:22 UTCinvestigating

    Son kalan backlog sürekli bir oranda işlenmeye devam ediyor. Tahminlerimiz, son bölümlerin arkalogun yaklaşık 60-90 dakika (20:30 UTC) tam olarak işlenmesi gerektiğini gösteriyor. Talep taramalarının çoğunluğunu görüyoruz (6% bu güncelleme anında) 15 dakika içinde tamamlanıyor. Ve bu sayı sürekli istikrarlı bir oranda büyüyor. Diğer bu sistem operasyonel görünüyor. Uygulama/UI tamamen operasyonel olduğuna inanıyoruz.

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

1. 5 Ekim 2026 13:24 UTCinvestigating

   Prod-us Pull Request veya CLI tarama gibi akışlar her zamankinden daha yavaş olabilir

2. 5 Ekim 2026 14:17 UTCinvestigating

   PostgreSQL bağlantı egzozion nedeniyle ABD platformunda büyük bir bozulma incelemeye devam ediyoruz. Müşteriler yavaş yanıt süreleri, yüksek 500 hata ve daha yavaş PR iş akışları ve 97 taramaları yaşayabilirler. Birkaç servis boyunca veritabanı yükünü azalttık ve bir RDS başarısız başlattık. Ekip normal performansı geri yüklemek için aktif olarak çalışıyor.

3. 5 Ekim 2026 14:29 UTCinvestigating

   Ekip aktif olarak AWS ile çalışıyor ve ABD ortamını etkileyen bir veritabanı başarısız sorunu olduğunu araştırıyor. Daha fazla bilgimiz olduğu sürece başka bir güncelleme paylaşacağız.

4. 5 Ekim 2026 15:17 UTCinvestigating

   Ekip, konuyu içsel olarak tırmanan AWS ile çalışmaya devam ediyor. Paralel olarak, başka bir veritabanına hareket ederek işlevselliği geri yüklemek için çalışıyoruz. Cycode statüsünü bekleyen herhangi bir engel, Cycode taramalarını doğrudan SCM'nizde (Kaynak Kodu Yönetimi) kaldırarak engellenebilir. Süreç akışına yardımcı olmak için Cycode temsilcisine ulaşın.

5. 5 Ekim 2026 16:10 UTCinvestigating

   AWS, etkilenen PostgreSQL örneğinin şu anda içsel bir kurtarma durumunda olduğunu doğruladı. Beklenen Multi-AZ başarısızlığı tasarlandığı gibi gerçekleşmedi ve AWS neden aktif olarak araştırıyor. Paralel olarak, kurtarma yolunda alternatif bir veritabanı yolunu kullanarak etkilenen hizmetleri geri yüklemeye devam ediyoruz

6. 5 Ekim 2026 16:58 UTCinvestigating

   Veritabanının operasyonel kapablarını restore ettiğini görüyoruz. İlk Pull Request taramalarının işlendiğini görüyoruz. Sistemi takip ediyoruz ve aktarım yapıyoruz.

7. 5 Ekim 2026 17:31 UTCinvestigating

   Veritabanı tamamen operasyonel kalır. Tüm gerilogları mümkün olduğunca kısa sürede işlemek için normal işlem hızı üzerinde çalışıyoruz.

8. 5 Ekim 2026 18:17 UTCinvestigating

   ABD platformu daha önceki RDS/PostgreSQL bağlantı egzozunu takip ediyor. AWS, orijinal PostgreSQL örneğinin operasyonel bir duruma geri döndüğünü doğruladı ve PR taramalarının tekrar işlendiğini görüyoruz. Kalan bozulma, büyük bir webhook backlog nedeniyle GitHub-güdümlü işleme gecikiyor, ki bu da yok olmaya devam ediyor. Kurtarmayı izlemeye devam edeceğiz ve işlem normale dönerken başka bir güncelleme sağlayacağız

9. 5 Ekim 2026 19:06 UTCinvestigating

   Son kalan backlog sürekli bir oranda işlenmeye devam ediyor. Tahminlerimiz, son bölümlerin arkalogun yaklaşık 60-90 dakika (20:30 UTC) tam olarak işlenmesi gerektiğini gösteriyor. Talep taramalarının çoğunluğunu görüyoruz (6% bu güncelleme anında) 15 dakika içinde tamamlanıyor. Ve bu sayı sürekli istikrarlı bir oranda büyüyor. Diğer bu sistem operasyonel görünüyor. Uygulama/UI tamamen operasyonel olduğuna inanıyoruz.

10. 5 Ekim 2026 20:09 UTCinvestigating

    Sistem tamamen operasyonel olmaya geri döndü

11. 5 Ekim 2026 20:24 UTCresolved

    **1. Özet** 5 Ekim 2026'da, 15:55 IDT'de başlayan, ABD platformumuzdaki müşteriler yavaş cevaplar gördü, geçici hatalar ve talep çeklerinde gecikmeler görüldü. Bazı müşteriler Cycode çekme istek kontrollerini gerektirir, tarama özgeçmişine kadar birleşemez. Sorun, birincil veritabanımızda bir arka plan bakım süreci geride kaldığı ve tamamlanmasının ardından başladı ve veritabanı yeni verileri kurtarmayı bıraktı. Restoring servisi birkaç saat sürdü, çünkü standby veritabanı ilk önce büyük bir geri dönüşüm sürecindeydi. Veritabanı geri döndü ve platform 19:43 IDT tarafından tekrar mevcuttu. Gecikmiş işleme sonra yakalandı ve olay 23:24 IDT'de çözüldü. Olay sırasında kaçırılan Pull talepleri tarandı. **2. Anahtar Zamanlı (IDT)** • ** 5 Ekim 2026, 12:55 IDT**: Rutin bir veritabanı bakım süreci normalden çok daha yavaş çalışmaya başlar. Henüz müşteri etkisi yok. • ** 5 Ekim 2026, 14:53 IDT**: Bir sonraki bakım döngüsü başlar ve tamamlanmaz. • ** 5 Ekim 2026, 15:55 IDT**: Veritabanı yeni verileri kurtarmayı durduruyor ve platform performansları bozuluyor. • ** 5 Ekim 2026, 16:03 IDT**: Veritabanı bağlantı limitine ulaşır. Müşteriler hataları görmeye başlar. • ** 5 Ekim 2026, 16:21 IDT**: Olay ilan etti ve yanıt ekibi meşgul etti. • ** 5 Ekim 2026, 16:24 IDT**: İlk güncelleme statü sayfasına gönderildi. • ** 5 Ekim 2026, 16:49 IDT**: standby veritabanına geçiş başladı. • ** 5 Ekim 2026, 17:00 IDT**: Bulut altyapı sağlayıcımızla açılan destek durumu. • ** 5 Ekim 2026, 18:24 IDT**: Alternatif kurtarma yolu paralel olarak başladı. Gerekli çekme talebi kontrolleri tarafından bloke edilen müşteriler için işbaşı. • ** 5 Ekim 2026, 19:43 IDT**: Veritabanı tekrar kullanılabilir ve Cycode API ve Cycode Platform erişilebilir. • ** 5 Ekim 2026, 19:54 IDT**: Pull request tarama özgeçmişleri. • ** 5 Ekim 2026, 20:20 IDT**: İşleme kapasitesi gecikmiş olayları temizlemek için arttı. • ** 5 Ekim 2026, 20:45 IDT**: Yüksek hacimli iş yükleri veritabanı yükünü azaltmak için durakladı. • ** 5 Ekim 2026, 21:56 IDT**: Pull talepleri tespit edildi ve tarandı. • ** 5 Ekim 2026, 23:09 IDT**: Tüm hizmetler tamamen operasyonel. • ** 5 Ekim 2026, 23:24 IDT**: Olay çözüldü. **3. Root Cause** Veritabanımız, kalıcı depolama için son değişiklikleri düzenli olarak kurtaran rutin bir arka plan süreci yürütüyor. Bu süreçte iki koşul yavaşladı: • **High-volume kısa ömürlü veri operasyonları: ** Bazı işlem iş yüklerimiz sürekli olarak çok sayıda kısa ömürlü veri yapısını yaratmak ve kaldırmaktı. • ** gecikmiş bir arka plan senkronizasyonu: ** Bir veri-seni süreci geride kaldı, bu da veritabanını kendi başına temizlemekten alıkoydu. Bakım süreci yavaşladı ve sonunda tamamlandı. Veritabanı daha sonra yeni veriler kurtaramadı ve istekler kuyruklara başladı. Hizmetlerimiz bu talepleri tekrarladı ve veritabanının bağlantı kapasitesini kullanan birçok yeni bağlantı açtı. Müşteriler bunu hataları ve yavaş cevaplar olarak gördüler. standby veritabanımıza geçtik. Trafik hizmet etmeden önce, son tamamlanmış bakım döngüsünden bu yana yapılan tüm değişiklikleri işlemek zorundaydı, yaklaşık dört saat aktivite. Bu, kesintiyi uzatmıştır. **4. Actions Taken** • Veritabanına geçici olarak ayarlanmamış işleme göre azaltın. • standby veritabanına bir geçiş başlattı. • Bulut altyapı sağlayıcımızla bir destek vakası açın ve onlarla birlikte tırmanan bir temel üzerinde çalıştı. • Paralel olarak alternatif bir kurtarma yolunu hazırlayın. • Gerekli çekme talebi kontrolleri tarafından bloke edilen müşteriler için geçici bir çalışma paylaşın. • Veritabanı kurtarıldığında, gecikmiş olayları temizlemek için işlem kapasitesi arttı. • Kısa süreli veri operasyonlarının yüksek hacimleri oluşturan iş yüklerini kullandı, gecikmiş olaylar silindiğinde veritabanı yükünü azaltmak için. • Olay sırasında kaçırılmış olan çekme taleplerini taradı. **4b. Action Elements ** • Veri kümelerinin veritabanı yükünü azaltmak için ne kadar büyük özetlendiğini değiştirin. • En yüksek hacimli iş yüklerimizi kendi özel veritabanına taşıyın, bu yüzden platformun geri kalanını etkilemez. • Veritabanı bağlantı kullanımı ve veritabanı sağlığı için uyarıları ve daha derin izleme ekleyin. • Her hizmeti kendi özel veritabanı bilgilerini verin. • Gelen olaylar bir kesintiden sonra kurtarmayı daha verimli bir şekilde gerçekleştirir. • İş gecikmelerinin ve içsel olay uyarılarının izlenmesi. • Daha fazla oda eklemek için veritabanı kapasitesi ve performans ayarları gözden geçirin.

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

1. 7 Ekim 2026 14:14 UTCmonitoring

   2:00 PM EDT (18:00 UTC), doğrulama veritabanını etkileyen önemli bir yük artış tespit ettik. Sorunu azaltmak için, örnek bir yükseltme yaptık. Veritabanı bağlantılarına kısa bir kesinti, yükseltme sırasında meydana gelebilir. Platform istikrarlı ve durumu yakından takip etmeye devam ediyoruz.

2. 7 Ekim 2026 14:14 UTCresolved

   Sistem tamamen operasyoneldir, devam eden sorunlarla gözlemleniyor. Bu olay şimdi çözüldü.

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

1. 28 Eylül 2026 19:08 UTCmonitoring

   2:00 PM EDT (18:00 UTC), doğrulama veritabanını etkileyen önemli bir yük artış tespit ettik. Sorunu azaltmak için, örnek bir yükseltme yaptık. Veritabanı bağlantılarına kısa bir kesinti, yükseltme sırasında meydana gelebilir. Platform istikrarlı ve durumu yakından takip etmeye devam ediyoruz.

2. 28 Eylül 2026 20:45 UTCresolved

   Sistem tamamen operasyoneldir, devam eden sorunlarla gözlemleniyor. Bu olay şimdi çözüldü.

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

1. 7 Ekim 2026 14:14 UTCresolved

   Çözüldü

2. 7 Ekim 2026 14:14 UTCinvestigating

   GitHub bileşeni: Pull Requests Original GitHub olayı:

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

1. 8 Ekim 2026 08:42 UTCinvestigating

   GitHub bileşeni: Pull Requests Original GitHub olayı:

2. 8 Ekim 2026 08:42 UTCresolved

   Çözüldü

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

1. 13 Eylül 2026 10:36 UTCinvestigating

   GitHub bileşeni: Pull Requests Original GitHub olayı:

2. 13 Eylül 2026 18:53 UTCresolved

   Çözüldü

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

1. 7 Ekim 2026 14:04 UTCresolved

   MemoryDB metrics stabil, işlem gecikmesi geri alındı ve sistem şimdi tamamen operasyonel.

2. 7 Ekim 2026 14:04 UTCmonitoring

   Aktif takas kullanımı da dahil olmak üzere MemoryDB bellek kullanımında keskin bir artış gözlemledik. Dava uygulandı. MemoryDB ölçümleri o zamandan beri stabil kaldı ve işlem gecikmesi hızla azaldı

3. 7 Ekim 2026 14:04 UTCinvestigating

   Prod-us Pull Request veya CLI tarama gibi akışlar her zamankinden daha yavaş olabilir

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

1. 8 Eylül 2026 16:53 UTCinvestigating

   Prod-us Pull Request veya CLI tarama gibi akışlar her zamankinden daha yavaş olabilir

2. 8 Eylül 2026 17:21 UTCmonitoring

   Aktif takas kullanımı da dahil olmak üzere MemoryDB bellek kullanımında keskin bir artış gözlemledik. Dava uygulandı. MemoryDB ölçümleri o zamandan beri stabil kaldı ve işlem gecikmesi hızla azaldı

3. 8 Eylül 2026 17:26 UTCresolved

   MemoryDB metrics stabil, işlem gecikmesi geri alındı ve sistem şimdi tamamen operasyonel.

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

1. 7 Ekim 2026 14:14 UTCinvestigating

   Prod-eu'da bozulan performansı fark ettik. Performans bozulması tüm uygulama ve tüm akışları etkiler (** Pull Request veya CLI tarama** gibi) normalden daha yavaş olabilir. İlk soruşturmamız paylaşılan veritabanına aşırı yük öneriyor, okumak ve daha yavaş yazmak. Ekip araştırmaya devam ediyor.

2. 7 Ekim 2026 14:14 UTCresolved

   Sistem tamamen operasyonel olmaya geri döndü.

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

1. 8 Eylül 2026 09:53 UTCinvestigating

   Prod-eu'da bozulan performansı fark ettik. Performans bozulması tüm uygulama ve tüm akışları etkiler (** Pull Request veya CLI tarama** gibi) normalden daha yavaş olabilir. İlk soruşturmamız paylaşılan veritabanına aşırı yük öneriyor, okumak ve daha yavaş yazmak. Ekip araştırmaya devam ediyor.

2. 8 Eylül 2026 10:52 UTCresolved

   Sistem tamamen operasyonel olmaya geri döndü.

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

1. 7 Ekim 2026 14:14 UTCresolved

   GitHub bileşeni: Pull Requests Orijinal GitHub olayı: https://stspg.io/0xbhq84v4mt

2. 7 Ekim 2026 14:14 UTCinvestigating

   GitHub bileşeni: Pull Requests Orijinal GitHub olayı: https://stspg.io/0xbhq84v4mt

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

1. 8 Ekim 2026 08:42 UTCinvestigating

   GitHub bileşeni: Pull Requests Orijinal GitHub olayı: https://stspg.io/0xbhq84v4mt

2. 8 Ekim 2026 08:42 UTCresolved

   GitHub bileşeni: Pull Requests Orijinal GitHub olayı: https://stspg.io/0xbhq84v4mt

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

1. 1 Eylül 2026 15:10 UTCinvestigating

   GitHub bileşeni: Pull Requests Orijinal GitHub olayı: https://stspg.io/0xbhq84v4mt

2. 1 Eylül 2026 16:05 UTCresolved

   GitHub bileşeni: Pull Requests Orijinal GitHub olayı: https://stspg.io/0xbhq84v4mt

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

1. 8 Ekim 2026 08:42 UTCinvestigating

   GitHub bileşeni: Pull Requests Orijinal GitHub olayı: https://stspg.io/nrbwjftcz72d

2. 8 Ekim 2026 08:42 UTCresolved

   GitHub bileşeni: Pull Requests Orijinal GitHub olayı: https://stspg.io/nrbwjftcz72d

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