Prod2 geçici olarak mevcut değildi
Pending
Etkilenen bileşenler
Platform
- investigating
Şu anda bu konuyu araştırıyoruz.
- resolved
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
82 Split incidents · Nisan 2026 — official updates, affected components, duration and resolution details.
Şu anda bu konuyu araştırıyoruz.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Boru yürütme Prod1'de sıkıştı. Sorunu araştırıyoruz.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
# # # Özet 27 Ağustos ve 28 Ağustos tarihleri arasında, müşteriler bazı boru hatlarının, dağıtımların ve ilgili kaynakların Harness UI ve API'de bulunamadığı bir sorun yaşadılar, ancak temel veriler bozulmamış olsa da. Sorun, iç platform hizmetleri arasında etkilenen iletişimi etkileyen planlı bir iç altyapı güncellemesi sırasında gerçekleşti. Sonuç olarak, dikkate bağlı olan talepler, organizasyon ve proje kapsamı kararı başarıyla tamamlayamadı, bu da mevcut varlıklar için müşterilere geri dönmedi. Mühendislik sorunu tespit etti, değişikliği geri getirdi ve normal hizmeti restore etti. Olay sırasında müşteri verileri kayboldu veya silinmedi. # # # Root Cause Sorun, üretimde planlanmış bir iç hizmet routing update sırasında ortaya çıkan bir yapılandırma hatasıyla neden oldu. Hesap, organizasyonunu çözmekten sorumlu bir iç platform servisi ve proje bağlamı, değişiklik uygulandıktan sonra diğer Harness hizmetlerinden talepleri doğrulamadı. Çünkü bu geçerlilik adım birçok varlık okumasından ve boru hattıyla ilgili eylemlerin devam etmesinden önce gereklidir, normalde var olmaya devam eden kaynaklar için başarısız talepler bulunur. Sorun etkilenen üretim ortamı ile sınırlıydı ve önceki hizmet iletişim yolunu yeniden sağlayarak çözüldü. ## Effects * Bazı müşteriler mevcut boru hatları, dağıtımları gördü ve ilgili varlıklar UI ve API'de bulamadılar. * İcra ilerlemesi dahil olmak üzere bazı boru hatlarıyla ilgili operasyonlar, webhook-triggered başlar, planlanan tetikleyici değerlendirme ve varlık listesi geçici olarak kesintiye uğradı. * Sorun mevcut varlıkların erişilebilirliği ve görünürlüğünü etkiledi, ancak verileri kaldırmadı veya müşteri yapılandırmalarını değiştirmedi. * İzinsiz erişim gerçekleşmedi ve hiçbir müşteri veri kaybı gözlemlendi. ## Remediation * **Immediate:** Daha önce çalışan hizmet iletişim yolunu yeniden yapılandırın ve altyapı yapılandırmasını geri yükleyin. * **Recovery validation:** Etkilenen varlık görünümleri, boru hatları işlemleri ve bağlı API'ler normalde geri döndükten sonra çalışıyorlardı. * **Permanent:** Güncelleme ile ilişkili yapılandırma işlemini düzeltti, bu nedenle benzer konular gelecekteki rolloutlarda hizmet-hiz doğrulamasına müdahale etmiyor. ## Action Elements Bu tür sorunların tekrar gerçekleşmesini önlemek için Harness olacak 1. Üretimin üretim trafiğini değiştirmeden önce iç hizmet iletişimini doğrulamak için önceden çalışan testleri geliştirerek doğrulamayı geliştirin. 2. İç doğrulama hataları için izleme ve uyarılama, böylece sorunlar daha önce tespit edilebilir. 3. Bu kadar bağımlılık başarısızlıklarını geliştirmek, hataları bulamadıkça müşterilere görünme olasılığı daha azdır.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda Prod-1'de IACM boru hatlarında bildirilen bir sorunu araştırıyoruz, Prod-2,Prod-4 ve EU1 kullanım kümeleri.
Bu konuyu araştırmaya devam ediyoruz.
Bu sorunun tüm kümelerde ortaya çıkmasına neden olan değişikliği yeniden başlattık.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Şu anda Özel Yönetim ve Deneyleme (FME) kullanıcı arayüzünün yüklenmediğini bildiriyoruz. FME konsoluna ulaşmaya çalışan müşteriler hatalarla veya sorumlu sayfalarla karşılaşabilir. Özel bayrak değerlendirme ve SDK trafiği etkilenmeye inanmaz. Daha fazla güncelleme kısa sürede takip edecektir.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
# # # Özet * **23:42 UTC ** 23 Ağustos 2026'da, birkaç FME müşterileri FME UI'yi yüklemeyi bildirdi. * CDN'den servis edilen FME UI Artifacts, bir saklama politikası nedeniyle sona erdi, FME UI'ye yüklenmesine neden oldu. * Herhangi bir bayrak isteği API, değişim teslimatı ve veri hattı kesinti olmadan çalışmaya devam etti. # # # Root Cause * FME UI bir CDN'den servis edilir. UI eserleri bir saklama politikası nedeniyle tahliye edildi, UI'nin tüm kullanıcılar için yüklemeye neden oldu. ## Effects * FME UI tüm üretim ortamlarındaki tüm kullanıcılar için yükleyemezdi. ### Ne etkilendi? * SDK işlevselliği ve runtime Flag değerlendirme * Admin API çağrıları * Müşteri Bayrak yapılandırma verileri * Veri kaybı gerçekleşmedi ## Remediation * FME UI bir dağıtım yoluyla CDN'de restore edildi * Kurtarma olayı kapatmadan önce tüm üretim ortamlarında doğrulandı. ## Action Elements * Şu anda aktif versiyonun asla evlendirmeye tabi olmadığı için varlık tutma politikasını geliştirin.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Yavaşlık ya aşağıdaki semptomlara neden olabilir: - Borular başlamaz - infazlarda gecikmeler - Zamanlar nedeniyle borular iptal edilir
Bulut sağlayıcımız aktif bir olayla karşı karşıya ve takip ediyoruz.
Bu konuyu araştırmaya devam ediyoruz.
Bulut sağlayıcımız, çoklu bölgeleri etkileyen devam eden bir olayı doğruladı. Harness boru hatları bir sonuç olarak deneyimli başarısızlıklara sahip değildir, ancak bazı kullanıcılar yavaşlığı yaşamaya devam edebilir. Durumu yakından takip ediyoruz ve daha fazla bilgi olarak güncelleştirmeler sağlayacaktır.
Bulut sağlayıcımız tarafından uygulanan düzeltmeyi takip eden yönetim kurulunda gelişmiş değişiklikler gözlemliyoruz. Durumu yakından izlemeye devam ediyoruz ve garanti edilen olarak daha fazla güncelleme sağlayacaktır. Birkaç müşteri için CI için bazı sıkı infazları kaydettik, bu da araştırıyoruz
Bu olay çözüldü.
# Özet 20 Ağustos 2026'da yaklaşık 15:00 UTC'de başlayan Harness platformu tüm üretim ortamlarında yaygın performans bozulmasını yaşadı. Normalde iki dakika içinde tamamlanmış olan boru infazları yedi ila on dakika sürdü. Sürekli Teslimat, Sürekli entegrasyon, boru hattı orkestrası ve Özel Yönetim ve Deneyleme tüm etkilendi. Google Cloud Platform, Bigtable, Compute Engine, Google Kubernetes Engine'i etkileyen birçok ürün olayı yaşadı ve bu bölgede kalıcı diskler üzerinde ısrar etti. Regreasyon, veritabanı işlemine yaklaşık 2 ms'ten 10 ms'e kadar gecikti ve zamanında veritabanı erişimine bağlı olan her hizmete yol açtı. # Etkisi Bu bir bozulmadı, bir kesinti değildi. Borular sürekli olarak idam edilmeye devam etti; başarısız olmaktan ziyade yavaşlardı. Hiçbir veri kaybedilmedi ve müşteri çalışması bu olayın bir sonucu olarak düştü. # **Root neden ** Etkilenen ortamlardaki Harness üretim altyapısı Google Cloud Platform'da kalıcı diskler üzerinde çalışıyor. Bu depolama katmanı bozulduğunda, etki öngörülebilir bir zincirde platform aracılığıyla ortaya çıktı: **Persistent-disk I/O in us-west1.** Google Cloud Platform, Bigtable, Compute Engine, Google Kubernetes Engine ve kalıcı performans etkileyen çok ürün olayı yaşadı. Bu, sağlayıcının ortamında bir altyapı başarısızlığıydı, Harness’in kontrolü dışında. # **Proventive actions** Harness bir bulut sağlayıcı altyapı başarısızlığını engelleyebilir. Aşağıdaki eylemler daha hızlı bir şekilde tespit etmeyi ve üzerinde hareket etmeyi daha iyi konumlandırmayı amaçlamaktadır. | **Action** | | --- | | Hedeflenen çapraz-region veritabanı başarısızovers'ın rutin pre-testi devam et, bu olay sırasında yapılan gibi, tahmin edilenden ziyade başarısız olmaya devam edin | | Assess full-stack multi-region, geç kalan gecikmelerin kabul edilemez olacağını gelecekteki senaryolar için hazırlanabilir |
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
# ### Özet 20 Ağustos 20, 2026, 10:24 ve 14:55 UTC arasında, FME'nin bir alt seti başarısız oldu. FME UI'den yapılmış yazlar ve Harness erişim jetleri ile yazlar (PATs ve SATs\) etkilenmedi. Runtime bayrak değerlendirme normalde çalışmaya devam etti. Sorun, paylaşılan bir yönetişim hizmetinde son doğrulama değişikliği tekrarlayarak azaltıldı ve etkilenen yazar 14:55 UTC tarafından normale döndü. Durum: [https://status.harness.io/incidents/rhthgm7d5dkz] (https://status.harness.io/incidents/rhthgm7d5dkz) # ## Root Cause Paylaşılan bir yönetişim servisinin, bazı FME'nin reddedildiği bir değişiklik. Bunlar, yönetim servisinin değişiklikten sonra artık doğrulamayabileceği hizmet içi kimlikleri kullandı. FME yüzeyleri, bir yönetişim politikası kasıtlı olarak bir değişikliği reddettiğinde kullanılan aynı durum. Çünkü 499, bu inkar yolunda beklenen bir yanıt olduğundan, başarısızlıklar uyarılarımızda kesintiye uğramadı ve olay içsel algılamadan ziyade müşteri raporlarından tespit edildi. # ## Effects * FME'nin bir alt kümesi pencere sırasında başarısız oldu, öncelikle miras Split API anahtarlarını veya değişim talebi zamanlamasını kullananlar. * FME UI'den yapılan yazlar etkilenmedi. * Harness erişim jetlerini kullanarak yazlar \(PATs ve SATs\) etkilenmedi. * Runtime bayrak değerlendirme normalde devam etti. * Veri kaybı gerçekleşmedi. Başarısız yazar uygulanmadı. # ## Remediation Yönetilen kimlik doğrulama değişikliğini yeniden finanse etti. Etkilenen yazı hemen normale döndü. ### Action Elements Bu sorunların tekrar gerçekleşmesini önlemek için, * Harness, bir yazı başarısız olduğunda farklı bir hata döndürür, çünkü yönetim değerlendirilmezdi, bu yüzden kasıtlı bir politika inkarı ile karıştırılmamalıdır. * Yönetişim değerlendirme çağrısının kendisini uyarmasını ekleyin, müşteri odaklı durum koduna güvenmek yerine. * Politika değerlendirmeleri için doğrulama desteği. * Ek yazma senaryoları için otomatik kapsamı genişletin.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Bu konuyu araştırmaya devam ediyoruz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Daha fazla sorun için izlemeye devam ediyoruz.
Bu olay çözüldü.
**Summary** 19 Ağustos 2026'da 12:35 ve 17:29 UTC, Harness Uygulama Güvenliği hizmeti hem müşteri odaklı konsolu hem de SaaS Production ve US1 bölgelerindeki veri kesinti hattını etkileyen önemli bir kesinti yaşadı. **Root Cause** Ekipmanların neredeyse her diğer bileşenine kadar çalıştırdığı iç yapılandırma servisi aşırı yüklenmeye ve tekrarlanan bir yeniden başlatma döngüsüne girdi. Çünkü o kadar çok hizmet buna bağlı, etkiler genişti: Koruma politikaları, duruş görüşleri, aktivite logları, API envanteri ve özel politika başarısız oldu ve yapılandırmayı beklerken kesintiye uğradı. # **Müşteri etkisi** | **Dimension** | **Detail** | | --- | | Konsol \(UI\) etkisi | Çoklu sayfalar koruma politikaları, duruş olayı sayfaları ve panodaki manzaralar, etkinlik günlük sorguları, API envanter ekranları, özel politika ve hassas-data görüşler ve widgets dahil olmak üzere yük ya da zamanlamaya başarısız oldu. | | Ingestion etkisi | Güvenlik telemetri işleme ciddi şekilde ve bazı yönlerde tamamen durduruldu. Tüketici lag normalleşme, gruplama, anomali algılama, nesil ve ilgili işleme aşamalarında büyüdü. | | Veri kaybı | Yıkım sırasında telemetrinin alt kümesi kalıcı olarak düştü. | **Mitigation** Birkaç ara işlem ek CPU ve hafıza, rahat sağlık kontrol eşleri, bir veritabanı yeniden başlatılır ve bu konuyu daha büyük bir bağlantı havuzu iyileştirmektedir. Her iki etkilenen bölgelerdeki yeni özelliği keskin ve durgun bir şekilde restore etti. Olay 17:29 UTC'de çözüldü. # **Proventive actions** Aşağıdaki eylemler kararlı ve tamamlanmak için içsel olarak takip edilir. Bu olayı tetikleyen özellik devre dışı kalır ve aşağıdaki çalışma tamamlanmaya ve doğrulamaya kadar yeniden etkinleştirilemez. | **Action** | | --- | | | Şifreyi önbellek evlenebilirlik ve saklama gibi ayarlayarak, büyük kural retrieval için eğriliği değerlendirin | | Servis büyütme erişim modeli için bir amaç tabanlı veritabanı indeks ekleyin | Add a purpose- built database index for the service-scoping access pattern | | Remediate pipeline recovery semantics bu yüzden tüketiciler geri adım atmak yerine konum işaretli kayıptan güvenli bir şekilde geri dönüyorlar | | Mandate pointd rollout for configuration overrides that alter downstream request pattern: düşük hacimli küme, sonra orta hacimli, sonra yüksek hacimli | | yapılandırma servisine geri baskı ve tutarlı koruma ekleyin: devre kırılması, bağlı kuyruklar ve zaman izolasyon | | Daha ayrıntılı metrikleri Instrumenting tarafından gözlemlenebilirlik |
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
## Summary Customers on Prod1, Prod2, and Prod3 \(US\) clusters experienced failures when loading SEI 2.0 dashboards on August 6, 2026, from 7:22 AM PDT to 9:03 AM PDT. Customers calling the SEI 2.0 API also experienced similar failures. No customer data was lost, and ingestion of all integration data continued to work uninterrupted. SEI customers using 1.0 were not impacted. ## Root Cause The incident was caused by resource exhaustion on the nodes serving queries. This resource degradation developed in a pattern that did not cross our existing alerting thresholds early enough to provide sufficient warning or allow mitigation before customer impact occurred. ## Impact Customers on Prod1, Prod2, and Prod3 \(US\) clusters were unable to load SEI 2.0 dashboards during the incident window. **Duration:** August 6, 2026, 7:22 AM PDT – 9:03 AM PDT \(~1 hour 41 minutes\) ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the root cause, our team took immediate corrective action by adding capacity to restore the affected systems. Services were fully recovered, and all dashboards resumed normal operation at 9:03 AM PDT. ## Action Items To prevent from such issues happening again, Harness is/has Proactively added capacity updates have been applied to prevent this issue from recurring #### Enhanced Monitoring and Alerting Additional monitoring and alerting have been put in place to detect anomalies early, focused on a leading indicator, which in this case was thread pool exhaustion, before they can impact dashboard availability and data rendering. #### System Patch in Progress We are working with our vendor to apply a patch to remediate this and similar issues completely.
Prod2'deki sıkı boru hatları izliyoruz. Yeni infazlar, hizmetleri sürekli takip ettiğimiz gibi geçiyor.
Prod2'deki sıkı boru hatları izliyoruz. Hala sıkı boru hatları gören müşteriler için, sizi birbort ve re-trigger'e talep ediyoruz.
Bu olay çözüldü.
# **Summary** 6 Ağustos'ta, 2026 \ (morning PDT\), bazı müşteriler Prod2 üretim ortamında boru hatları yürütmelerini durdurdu - ilerlemeyi durduramayan aşamalar - daha fazla çıkış veya durum güncelleştirmeleri yapmadı. Sorun etkilenen müşteriler tarafından rapor edildi. Harness mühendisleri, etkisini hafifletti ve boru hatları infazları normal operasyona geri döndü. Sorun kendi kendine bağlı bir boru hattı ifadesi tarafından kaynaklandı. Bir Git webhook, webhook ödeme yüklerinin içeriğine atıfta bulunan bir boru hattını tetikledi ve ödeme yükü bu ifadenin daha fazla kopyasını içeriyordu. Bu nedenle her ifade kararının her turu, her seferinde çalışma miktarını ikiye katladı. Bu, o infazın hizmet örneği işleme kaynaklarının tükendi ve aynı şekilde atan diğer infazlar bu durumdayken ilerlemedi. # **Impact** Olay sırasında pencere \(yaklaşık 6:11 AM to 11:23 AM PDT 6 Ağustos 2026'da): * Bazı müşteriler Prod2 tezgahlanmış orta-execution üzerinde çalışır ve daha fazla ilerleme kaydetmedi. * Etkilenen infazlar yeni bir adım çıktısı veya durum güncelleştirmeleri yaratmadı ve mitigation'den sonra tekrarlanacaktı. * Davranış, etkilenen servis örneği tarafından işlendiği infazlarla sınırlıydı - diğer örnekler tarafından yapılan boru hatları normal olarak çalışmaya devam etti. ** Yok veri kaybı** vardı. Boru tanımları, idam tarihi ve saklanan devlet etkilenmedi. Prod2'deki boru hatlarının çoğunluğu olay boyunca başarılı bir şekilde idam etmeye devam etti; birincil etki, bazı aydınlatıcı infazların tamamlanmadığı ve bir kez daha ele alınması gerektiğiydi. # **Root Cause** Harness boru hatları, runtime'da çözülmesi gereken ifadeleri destekler - örneğin, boru hattını tetikleyen Git webhook ödeme yüklerinin içeriğini içeren bir ifade. Bu durumda, bir Git mesajı, ödeme yükü ifadesinin gerçek metnini iki kez içeriyordu ve boru hattı aynı ücret ifadesine atıfta bulundu. Çünkü taahhüt mesajı webhook ödeme yükünin bir parçasıdır, ifadenin tüm ödeme yüklerini birleştirin - iş mesajında yürütülen ifadenin iki gerçek kopyası da dahil. Bu yeni eklenti kopyaları daha sonra çözülmesi için ifadeler olarak tedavi edildi ve her biri ödeme yükünün iki kopyasını ekledi. Değerin işlenmesinin büyüklüğü ve bunu işlemek için gerekli olan çalışma, bu nedenle her geçişte iki katına çıktı ve konvering yerine üst üste büyüdü. Harness tam olarak bunu durdurmak için tasarlanmış bir koruma vardır: ifade kararı maksimum nesting derinliği ile bağlıdır, hangi kararın durması ve boru hattının açık bir hatayla başarısız olması. Bu korumadaki bir hata, limitin bu özel kendi kendine özgü durumda uygulanmadığı anlamına geliyordu, bu nedenle karar kontrol edilmedi. Expression çözünürlüğü, boru hatları adımlarına başlayan iplikler üzerinde durmaktadır. Her bir geçiş sürekli olarak daha fazla hafıza ve CPU'yu hiç tamamlanmadan tükettiği gibi, bu çalışmanın ilerlemeyi durdurmasını sağlayan hizmet örneği ve bu örnek tezgaha verilen her uygulama - hangi müşterilerin rapor ettiği. # **Mession** Harness aşağıdaki hemen masyon adımlarını tamamladı: * Boru hattını ve runaway kararından sorumlu ifade kalıbını tanıdım. * Etkilenen servis örneklerini durdurun, böylece daha fazla iş almayacaktır. Kalan sağlıklı örnekler normalde kuyruklanmış infazları aldı ve işledi. * Boru yürütmelerinin normale döndü ve olayı kapattığını onaylayın. Bu eylemler normal boru yürütme davranışını restore etti ve müşteri odaklı etkiyi çözdü. # **Action Elements ** Recurrence riskini azaltmak ve algılamayı geliştirmek için, aşağıdaki eylemler çeşitli aşamalarda uygulanır: * ifade derinliğinde ve döngüsüz korumadaki hataları düzeltin, böylece kendi kendine özgü ifadeler yakalanır ve sınırlı olmayan kaynakları tüketerek açık bir hatayla hızlı başarısız olur. * Ödeme yükleme ifadelerini tetikleyici ödeme yükleme içeriğinden çözerek, kendi kendine özgü yolu tamamen ortadan kaldırmak. * Maksimum ifade derinliğini daraltır ve mevcut derinlik sınırına ek olarak açık döngü algılamasını değerlendirin. * Kendi kendine özgü ifade modellerini yeniden üreten pre-prodüksiyon ortamlarda otomatik testleri geliştirin ve korumanın onları tespit ettiğini doğrulayın. * Boru yürütmelerinde bu desen için izleme ekleyin, böylece proaktif olarak tespit edilir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.
Şu anda bu konuyu araştırıyoruz.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
# **Summary** 25 Temmuz ve 4 Ağustos 2026 arasında, Harness Prod 2 ve Prod 3 kümesleri, gerçek zamanlı olarak geride kalan verileri sergiledi. Boru hatları kendilerini normal olarak inşa etmeye, dağıtmaya ve yürütmeye devam etti; konu, raporlama ve pano görüşlerine hizmet eden veritabanına ne kadar hızlı infaz kayıtları kopyalanmıştı. **Hiçbir müşteri verileri kaybedilmedi.** Etkilenen her kayıt durgun olarak saklandı ve alt sınır kaldırıldıktan sonra analitik veri deposuna yeniden çekildi. Harness etkilenen kümeleri 1 Ağustos 2026'daki replikasyon bileşeninin yatay olarak ölçeklenebilir, geri dönüşümlü versiyonuna göç etti ve etkilenen tüm hesaplar için hedeflenen verileri geri tamamladı. # **Root neden ** Harness, birincil operasyonel veri deposundan panolar ve raporlama sorguları için optimize edilmiş ayrı bir zaman serisi veri deposuna sürekli olarak kopyalanan bir değişim bileşeni tutar. Dashboards sadece analitik veri deposundan okunur. Replication geride kaldığı zaman, panolar dünyanın doğru ama daha eski bir görünümünü oluşturur, infazın kendisi etkilenmez. Bu keskin, veritabanında devam eden artış, diğer Harness platform modülünün aynı replikasyon yolunu paylaşması, bu bileşenin eski, tek yönlü versiyonu hala Prod 2 ve Prod 3'te çalıştırılıyor. Bir backlog kuruldu ve büyüdü. # **Proventive actions** Harness, bu sorunları önlemek için aşağıdaki eylemlere tamamlanmış veya taahhüt etmiştir. | **Action** | | --- | | Tamamlanan bir eşiğin ötesindeki herhangi bir gecikme bildirimde bulunulması | Fine melodi the replication lag alerting so that any gecikme beyond a defined eşi is notification | | Standart platform izleme kuruluna bir replikasyon lag paneli ekleyin, bu yüzden boru hattı sağlığı varsayılan olarak görünür | | Uygulama akışında per-module oranı sınırlaması veya varlık filtrelemesi yoluyla ortak modüllerden yazmayı azaltın |
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
# **Summary** 31 Temmuz 2026'da, AB1 setinde boru hattı yoluyla yapılan sanatlar doğrulama hatasıyla başarısız oldu. Yüklemeler manuel olarak \ (bir boru hattının dışında) etkilenmedi ve mevcut eserler alma yeteneği de etkilenmedi \(downloads\) aynı zamanda etkilenmedi - bu bir kümedeki özel boru hattı yükleme yolunda izole edildi. # **Impact** * EU1 setinde boru hatlarıyla yapılan Artifact yükleri yaklaşık 4 saat ve 34 dakika boyunca bir doğrulama hatasıyla başarısız oldu. * Mevcut eserleri yeniden sunmak \(downloads\) etkilenmedi. * Bir boru hattı dışındaki eserler yüklemek etkilenmedi. * Diğer kümeler/bölgeler bu konu tarafından etkilenmedi. # **Root Cause** Boru tabanlı sanatifact yüklemelerini işlemekten sorumlu olan bileşen bir konteyner resmi olarak dağıtılır. EU1 kümesinde, bu görüntü, halka açık bir görüntü kaynağı olan bir iç kayıttan alınır; diğer kümelerde, aynı görüntü doğrudan kamu kaynağından alınır. Serbestleşme sürecinde yayınlanan bir yayın hatası, yeni, benzersiz bir versiyon atamak yerine zaten kullanımda olan bir sürüm etiketi kullanarak yeni bir bileşen oluşturmasına neden oldu. Sonuç olarak, halk kaynağında aynı versiyon etiketi ile iki farklı görüntü sona erdi. İç kayıt aynalarımız otomatik bir replikasyon işlemi aracılığıyla kamu kaynağından görüntüler. Bu replikasyonun nasıl tetiklendiği için, düzeltilmesi yerine bu sürüm etiketiyle ilişkili orijinal \ (earlier\) görüntü kopyaladı. Bu, AB1 kümesi anlamına geliyordu - iç aynadan çeken - diğer kümelerden daha farklı, yanlış bir görüntü çalıştırmaya son verdi ve bu nedenle düzeltilmesi görüntü aldı. Hatalı görüntü, boru yüklemelerine neden olan bir kimlik doğrulama sorunu içeriyordu. # **Mession** * etkilenen hesabı yükleme bileşeninin son bilinen iyi versiyonuna geri verdi, hemen boru yüklemelerini geri yükleyin. * Tüm kümelerdeki sorunu çözmek için bileşenin düzeltilmesi, kalıcı bir versiyonunu yayınladı. # **Sonraki adımlar** * Bu başarısızlık modu mümkün kılan temel konteynerle ilgili hataları kaldırmak için yükleme adımını düzeltin. * Bu bileşen için serbest bırakma hattımızı güncelleyin, böylece bir görüntüyü yayınlamak asla mevcut bir sürüm yazamaz - her yayın yeni, farklı bir sürüm ortaya çıkar.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Özet - Build VM’miz ile ağ bağlantı sorunlarıyla karşı karşıyayız ve dış kaynaklara bağlanamıyoruz. Şu anda konuyu araştırıyoruz.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Daha fazla sorun için izlemeye devam ediyoruz.
Bu olay çözüldü.
## Summary Starting on August 4, 2026, CI runners in the us-west1 and us-central1 regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services such as GitHub and Bitbucket over outbound network gateways. ## Impact * CI runners in the affected regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services \(e.g., GitHub, Bitbucket\) over our outbound network gateways. * The issue was intermittent rather than constant — connections succeeded under normal load, and failures clustered during periods of high outbound traffic volume. * No data was lost or corrupted. This was a network-connectivity and capacity issue, not a data-integrity issue. * us-west1 and us-central1 were the affected regions; other regions were not impacted by this issue. ## Root Cause Our load balancer distributes outbound traffic across multiple NAT gateways using a hashing method based on connection details \(source/destination address and port\). For any single connection, these details stay constant for that connection's lifetime. We had a sustainted traffic surge for a few seconds which congested the gateways ## Action Items To prevent such issues from happening again Harness will, Increase outbound connection capacity on our NAT gateways by provisioning additional external network interfaces, giving each gateway a substantially larger pool of connections it can serve concurrently..
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Bu konuyu araştırmaya devam ediyoruz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Daha fazla sorun için izlemeye devam ediyoruz.
Bu olay çözüldü.
# Özet Son bir üretim dağıtımında, iç dağıtım aracımızdaki bir hata, yanlış, üretim olmayan konfigürasyon değerleri ile üretim ortamımızın yanlış çalışmasına neden oldu. Bu, dört ayrı semptomun ilgili bir setine yol açtı: yanlış yapılandırma davranışı, geçici giriş / erişim başarısızlıkları, bir müşteri ortamını etkileyen bir dosya cihazı erişim sorunu ve UI'de gecikmiş boru durumu güncelleştirmeleri. Tanımlandık ve alt konfigürasyon hatası için kalıcı bir düzeltme uyguluyoruz ve zaten UI gecikme semptomunu çözen yer kaynağı ve kapasite değişiklikleri koyduk. Bu olay sırasında hiçbir noktada, boru hatları kendilerini kaybetti, bozulmuştu veya sıkı bir durumda kaldı. Uygulamanın etkilendiği yerde, alt işlemede olmayan durum görünürlüğünde gecikmelerle sınırlıydı. # Olay Detayları ## Incorrect Production Build Values Applied Mühendislik ekibimiz, doğru üretim konfigürasyonundan ziyade, farklı bir ortam için tasarlanmış konfigürasyon değerleri kullanılarak dağıtılması için belirli üretim hizmetlerine yol açan bir hata doğruladı. **Root Cause** Dağıtım sırasında yapılandırma overrides'i satın almaktan sorumlu olan hizmet, talep başına en fazla 1.000 sonuç veren bir iç API sorgulamaktadır. Çevredeki toplam hizmet sayısı son zamanlarda bu sınırın ötesinde büyüdü. Sonuç olarak, ilk 1.000'in ötesinde herhangi bir hizmet yanıta dahil edilmedi ve dağıtım hattı bu hizmetler için varsayılan yapılandırma değerleri geri düştü. Bu, dağıtım aracında doğrulanmış bir paginasyon hatasıdır, yapılandırma değerleriyle ilgili bir sorun değildir. **Resolution** Mühendislik mekanizmayı doğruladı ve dağıtım hattında bu sınırla ilgili boşlukları kaldırmak için kalıcı bir düzeltme uyguluyor. ## Intermittent Login / Access Failures Servis Yöneticisi dağıtımı yukarıda referanslandı, bazı kullanıcılar geçici giriş veya erişim başarısızlıkları yaşadı. Normal operasyon altında, daha önce çalışan örnekleri, yeni bir dağıtım devam ederken trafiği kesintiye devam etmelidir. Bu olayda, bu geri dönüş davranışı beklenen gibi gerçekleşmedi, dağıtım penceresi sırasında başarısızlıklara katkıda bulundu. ## Filestore Access Issue Bir dosyacı erişim sorunu, Prod-3 ortamına özel olduğunu ve tek bir müşterinin ortamını etkilediğini tespit edildi. **Root Cause** Bu, Hizmet Yöneticisi'nde bir IAM / depolama-bucket izni konfigürasyonu ile ilgilidir, potansiyel olarak geri dönüşümlü aktivite ile tetiklenir. ## Gecikmiş Boru Execution Status Updates in UI Bazı kullanıcılar, UI'deki boru hattı yürütme grafiğinin yavaş yavaş olduğunu ve en son durumu hemen yansıtmadığını gözlemledi. Önemli olarak, bu sadece görünürlük bir gecikmedi: gerçek boru yürütmelerine etkisi yoktu ve bu sorunun sonucu olarak infazlar ya da başarısız olmadı. **Root Cause** Boru yürütme grafiği, statü güncellemelerini almak için bir mesaj akışına dayanıyor. Olay penceresi sırasında, bu yayının tüketici işlemesi \ (yüksek tüketici gecikmesi) geride kaldı ve bu da hızla durum güncellemelerinin UI'ye ulaştı. Bu, alt veritabanının aynı anda planlı bir ölçeklendirme işleminin ortasında olduğu ve bu pencere sırasında bir trafik artışının gecikmesini daha da kötüye kullanmasına neden oldu. Kullanıcılar bunu belirgin bir boru hattı yavaşlığı olarak deneyimledi, ancak altta yatan infazlar normalde koşuyordu. **Resolution** Etkilenen parçaların% 50'den fazla yedek odayı sürdürmesi için kaynak kapasitesi artırıldık, benzer yüklere duyarlılığı azaltır. Bu değişiklik uygulandı ve şu anda platformun bu kısmı için daha uzun vadeli zorlaşmanın bir parçası olarak onaylanmıştır. # Influence Özet * Servis Yöneticisi ve Lisans Yöneticisi, Prod-1 ve Prod-3 ortamlarda yanlış yapılandırma değerleri ile koştu. * Bazı kullanıcılar etkilenen dağıtım penceresinde geçici giriş veya erişim başarısızlıklarını deneyimledi. * Prod-3'te bir müşteri ortamı bir dosya deposu erişim sorunu yaşadı. * Etkilenen ortamlardaki kullanıcılar, UI'de gecikmiş boru yürütme durumu güncellemelerini gördü; temel boru hatları infazları doğru şekilde çalışmaya devam etti ve kaybolmadı, sıkıştı ya da yozlaşmış değildi. # Önleme Eylemleri Aşağıdaki düzeltici ve önleyici eylemler tespit edilmiştir. | **Corrective / Obive Action** | | --- | | Tüm hizmetlerin geri döndüğü ve değerlendirilmesi için paginasyon limitini düzeltin, toplam sayı ne olursa olsun. | | Korumaları ekleyin, böylece yapılandırmasını alamayan bir hizmet güvenle \ (örneğin, uyarılar ve dağıtım\) sessiz olmayan üretimlere geri dönmek yerine gelir. | | Postgres ve mesajlaşma-borline kaynak kafa odası \(target:% 50 yedek kapasitenin daha fazlası) eş zamanlı yük ve ölçeklendirme olayları için duyarlılığı azaltmak. | Bu olayın platformun birden çok alanında olduğunu ve sabrınızı tam bir kararla çalışırken takdir ettiğini biliyoruz.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
AIDI panolarını etkileyen bir sorunu araştırıyoruz. Kullanıcılar, panolara erişirken zaman veya aralıklı başarısızlıklar deneyimleyebilir. Ekibimiz aktif olarak kök nedenini tanımlamak ve normal performansı geri yüklemek için çalışıyor. Güncellemeleri daha fazla bilgi olarak sunacağız.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
## Summary Customers on Prod1, Prod2, and Prod3 clusters experienced intermittent widget load failures and increased load times when accessing AIDI 2.0 dashboards on July 22, 2026. Not all widgets were affected simultaneously the issue manifested as sporadic failures rather than a full outage. No customer data was lost. SEI 1.0 customers were not impacted. ## Root Cause Over time, a routine database maintenance process failed to run on certain tables in our analytics database, causing those tables to accumulate a large volume of internal metadata used to track deleted records. When the database planned queries against these tables, it loaded all of this accumulated metadata into memory, causing memory usage on the affected nodes to spike repeatedly. These repeated spikes triggered an automatic safety mechanism that restarts a node when it detects excessive memory pressure, and the affected nodes began restarting in a loop as a result. This caused intermittent, degraded query performance on AIDI 2.0 dashboards for the duration of the incident. ## Impact Customers on Prod1, Prod2, and Prod3 clusters may have experienced intermittent widget load failures or increased load times on AIDI 2.0 dashboards. **Duration:** July 22, 2026, 07:58 PDT – 16:16 PDT \(~8 hours 18 minutes\), with intermittent widget failures; system was restarted and under active monitoring from 08:25 PDT onward. ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the issue, the affected database nodes were restarted at 08:25 PDT, which restored initial stability. We continued to monitor the system closely, and when intermittent degradation was still observed afterward, we applied several additional fixes: * Adjusted database configuration settings to limit the amount of memory used for processing accumulated metadata, and tuned query-planning settings to reduce memory pressure. * Ran cleanup jobs to reduce the backlog of accumulated metadata on the affected tables. * Increased capacity on the affected database nodes to provide additional headroom. These changes progressively stabilized the system, and the incident was fully resolved at 16:16 PDT. ## Action Items To prevent recurrence, we are implementing the following: 1. We have upgraded the backend which includes underlying improvements that handle memory spikes caused by excessive delete files. 2. We have rolled out automated compaction jobs for newly introduced tables to prevent delete file accumulation going forward.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
# Özet 17 Temmuz 2026'da, rutin bir kod dağıtımını takiben, eski delege versiyonlarında müşteriler \(858xx ve altında) gecikmiş CI'yi Harness Cloud'da inşa etmeye başladı. Etkilenen yapılar, devam etmeden önce " altyapı için beklenen" aşamasında yaklaşık 8 dakika kadar beklenmedik bir durak yaşadılar, beklenen alt saniye içinde devam etmek yerine. Genel olarak yavaşlık intermittent idi. # Etkisi * Tüm CI inşaları potansiyel olarak gecikmeye tabiydi; Harness Cloud'da inşa edilen altyapıyı küresel inşa edilmiş bir özellik kullanarak inşa etmek için en belirgin şeydi. * Etkilenen yapılar, devam etmeden yaklaşık 8 dakika öncesine kadar açıklanmamış bir duraklama yaşadı, daha yavaş bir "soğuk başlangıç" tarafından takip edildi, çünkü önceden korunmuş bir hesap slot mevcut değildi - bu, başarısızlıkları yerine kullanıcılara sunulan yavaş inşalar. * Yenier delege versiyonları üzerinde çalışan hesaplar \(858xx ve üstünde) etkilenmedi. * Bu sorunun doğrudan bir sonucu olarak hiçbir yapılamıyor ve hiçbir veri kaybedilmedi. # Root Cause Kök nedeni, inadvertly'nin belirli bir yapı-kış kaydının veritabanımızdan bir kez geri okunduğu bir iç kod değişikliğiydi, kodun önceki sürümü altında zaten sıralanan yeni sürümle karşılaştı. Etkilenen kayıtları temizlemek ve alt kod değişimini tekrar tekrarlayarak acil etkiyi çözdük ve bu konunun tekrarlanması için çeşitli korumalar uyguluyoruz. # Sonraki Adımlar Aşağıdaki eylemlerin altında olduğu kadar benzer bir recurrence riskini değerlendiriyoruz. Bu olayın ortaya çıkmasına neden olan özel kod yolu zaten yeniden ortaya çıktı ve yapısal korumaları uyguluyoruz, böylece bu genel konu sınıfı kod tabanında herhangi bir şekilde gerçekleşemez. | **Corrective / Obive Action** | | --- | | Açık ekle, veritabanımızda depolanan tüm iç veri sınıflarına istikrarlı tanımlayıcılar ekleyin, bu nedenle gelecekteki iç kod reorganizasyonlar daha önce depolanan kayıtları okuma yeteneğini kıramaz. | | Prodüksiyon ortamındaki geri dönüşüm ve geri dönüşüm testlerini tanıtmak, özellikle bu konuyu üretime ulaşmadan önce yakalamak için tasarlanmıştır. |
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda bu konuyu araştırıyoruz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Daha fazla sorun için izlemeye devam ediyoruz.
Bu olay çözüldü.
# Özet 19 Haziran ve 17 Temmuz 2026 arasında, yerleşik Git Clone adım - ve drone-git klonu kullanarak herhangi bir boru hattı adım - ARM64 Kubernetes, hata ek /usr/yerel/bin/clone ile altyapı inşa etti: exec format hatası. AMD64 \(Intel/AMD\) inşalar, Windows inşalar ve VM konteynersiz ikili yolu etkilenmedi. Kök nedeni, ARM64-tagged drone-git görüntülerinin aslında AMD64 biner içerdiği iç resmi yayın sürecinde bir hataydı. Aynı gün sorunu tespit ettik ve azalttık, drone-git imajını son bilinen iyi versiyona tekrar göndererek rapor edildi. Hiçbir müşteri eylemi veya yapılandırma değişikliği gerekli değildi. # Root Cause 19 Haziran 2026'da, bir güvenlik aracılık, drone-git imajının nasıl inşa edildiğini yeniden yapılandırdı. AMD64 inşaları doğru bir şekilde güncellendi, ancak ARM64 inşa hattı doğrudan ARM64 dosyaları inşa etmedi - AMD64 dosyayı metin altlığı aracılığıyla uyarladı ve bunu ARM64 altyapısında derledi. 19 Haziran değişikliği AMD64 dosyasını değiştirdi, bu yüzden alt kurum sessiz bir şekilde başarısız değil, bu yüzden boru hattı, Git Clone ve Git LFS biners hala AMD64 için derlendi. # Etkisi * Etkilendi: İnşa edilen Git Clone adım ve drone-git klon eklentisini kullanarak herhangi bir boru hattı adım, 6 Temmuz ve 17 2026 arasında tüm hesaplarda altyapı inşa ediyor. * Symptom: Git Clone adımında eskiec /usr/local/bin/clone ile başarısız oldu: exec format hatası. * Etkilenme: AMD64 \ (Intel/AMD\) Kubernetes ve VM inşaları, Windows inşaları, VM konteynersiz infaz yolu ve sertleştirilmiş görüntü değişkenimiz. # Mession Son bilinen iyi salıvermelere tüm etkilenen hizmetlerde kullanılan drone-git görüntü versiyonunu yeniden gözden geçirdik. Bu, ARM64 uygulama başarısızlıklarını tamamen çözdü; müşteri yapılandırma değişiklikleri gerekli değildi. # Sonraki Adımlar Bu sorunların tekrar gerçekleşmesini önlemek. * Özel ARM64 görüntü yayın hattını inşa etmek için yeniden inşa etmek, AMD64 inşa dosyalarını adapte etmek yerine doğrudan dosyaları inşa etmek. * Her görüntü sürümüne otomatik olarak yayımlanmış otomatik yayın doğrulama: İkili mimari görüntü etiketini eşleştirin ve bir görüntüden önce işlevsel bir duman testi çalıştırın. * ARM64 Kubernetes oluşturmak için otomatik test kapsamı genişletin. * Yaralanan orta görüntü versiyonlarını bir kez düzelten sürüm doğrulanır.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.