Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
postmortem
### Summary
On September 8, 2026, customers in Prod 1 and Prod 2 experienced elevated platform latency and pipeline failures. The issue was caused by a regression in a newly released capability that triggered cascading failures under high load. Because the capability was behind a feature flag, it was quickly disabled, and service was restored after a brief monitoring period.
### Customer Impact
* Customers encountered slowness and failures during pipeline execution and UI operations. Some API calls returned errors or timed out.
* No data loss or corruption occurred.
### Root Cause
The new capability introduced a regression that created contention on a shared backend resource used by multiple Harness components. This saturated the shared platform infrastructure and caused the cascading failures.
### Mitigation
* Disabled the capability across all environments
* Temporarily increased platform capacity to restore stability
### Next Steps
To prevent recurrence, Harness will:
1. **Permanently fix the capability** by profiling and eliminating the sub-optimal code path and query
2. **Improve detection** by enhancing alerting for resource-intensive queries on high-frequency platform paths
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Prod2 geçici olarak mevcut değildi
Başlangıç 5 Eylül 2026 09:40 UTC · 1m
Pending
Etkilenen bileşenler
Platform
investigating
Şu anda bu konuyu araştırıyoruz.
resolved
Bu olay çözüldü.
postmortem
## **Summary**
Between 12:34am PST and 12:38am PST on 5th September, the Delegate service manager experienced some elevated exceptions when attempting to write to the database. Consequently, delegate connections were dropped, causing them to disconnect. Delegate automatically re-attempts registration back to the `delegate service manager` and majority of the delegates got connected back after the incident. For Docker and ECS delegates the automatic restart is not enabled unless these delegates have health monitoring enabled. For these delegates a manual restart is needed and was recommended. Post restart the delegate would re-connect and the issue was resolved.
## **Root cause**
On Prod2 cluster we identified a performance bottleneck in the delegate service that, under certain conditions, can increase database write latency and delay heartbeat processing which leads to delegates being disconnected.
## **Impact**
All K8s delegates and \`Docker/ECS\` delegates got connected back immediately within 4 mins and started to function normally. The impact can be scoped to those specific types of delegates that didn’t have health monitoring enabled.
## **Remediation**
* Immediate: We have added additional monitoring and increased resources for handling the influx of traffic.
* Permanent: We have identified a hotspot in the code that can cause high latency when writing to a database which we are actively working on resolving.
## **Action Items**
To prevent such issues from happening again, Harness will work on the following:
1. Increased targeted monitoring and alerting to initiate timely mitigation and prevent this from happening again.
2. Fix the identified delegate service managers database client reconnect failures
3. Fix the hotpots that can cause query latency.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Boru hatları Prod1'de sıkıştı
Başlangıç 3 Eylül 2026 10:00 UTC · 1h 40m
IssuesKüçük çaplı olay
Etkilenen bileşenler
Continuous Delivery - Next Generation (CDNG)
investigating
Boru yürütme Prod1'de sıkıştı. Sorunu araştırıyoruz.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Harness'teki eşitsizlikler Prod3'te yüklemez
Başlangıç 28 Ağustos 2026 07:04 UTC · 32m
IssuesKüçük çaplı olay
Etkilenen bileşenler
Platform
investigating
Şu anda bu konuyu araştırıyoruz.
identified
Sorun tespit edildi ve bir düzeltme uygulanır.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
postmortem
# # # Ö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.
Boru hatları IACM müşterileri için başarısız
Başlangıç 26 Ağustos 2026 08:38 UTC · 32m
IssuesKüçük çaplı olay
Etkilenen bileşenler
Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)
investigating
Ş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.
investigating
Bu konuyu araştırmaya devam ediyoruz.
monitoring
Bu sorunun tüm kümelerde ortaya çıkmasına neden olan değişikliği yeniden başlattık.
resolved
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Özel Yönetim ve Deneyleme (FME) kullanıcı arayüzü mevcut değildir
Başlangıç 24 Ağustos 2026 00:57 UTC · 16m
OutageBüyük çaplı olay
Etkilenen bileşenler
FME
investigating
Şu anda bu konuyu araştırıyoruz.
investigating
Ş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.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
postmortem
# # # Ö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.
Tüm modüller Prod1/2/3/4'te bulut sağlayıcı olayı nedeniyle yavaş çalışıyor
Başlangıç 20 Ağustos 2026 15:37 UTC · 3h 46m
OutageBüyük çaplı olay
Etkilenen bileşenler
PlatformPlatformPlatformPlatform
investigating
Şu anda bu konuyu araştırıyoruz.
investigating
Yavaşlık ya aşağıdaki semptomlara neden olabilir:
- Borular başlamaz
- infazlarda gecikmeler
- Zamanlar nedeniyle borular iptal edilir
investigating
Bulut sağlayıcımız aktif bir olayla karşı karşıya ve takip ediyoruz.
investigating
Bu konuyu araştırmaya devam ediyoruz.
identified
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.
monitoring
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
resolved
Bu olay çözüldü.
postmortem
# Ö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.
FME API yaz işlemleri 499 hata geri dönmeye başladı
Başlangıç 20 Ağustos 2026 14:32 UTC · 30m
IssuesKüçük çaplı olay
Etkilenen bileşenler
FME
investigating
Şu anda bu konuyu araştırıyoruz.
identified
Sorun tespit edildi ve bir düzeltme uygulanır.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
postmortem
# ### Ö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.
Data ingestion, Traceable US production üzerinde gecikiyor
Başlangıç 19 Ağustos 2026 13:22 UTC · 2h 44m
OutageBüyük çaplı olay
Etkilenen bileşenler
US - app.traceable.ai / api.traceable.ai
investigating
Şu anda bu konuyu araştırıyoruz.
investigating
Bu konuyu araştırmaya devam ediyoruz.
identified
Sorun tespit edildi ve bir düzeltme uygulanır.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
monitoring
Daha fazla sorun için izlemeye devam ediyoruz.
resolved
Bu olay çözüldü.
postmortem
**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.
investigating
We are continuing to investigate this issue.
identified
The issue has been identified and a fix is being implemented.
resolved
This incident has been resolved.
postmortem
## 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.
Takip - Borular Stuck - Prod2
Başlangıç 6 Ağustos 2026 13:50 UTC · 4h 31m
IssuesKüçük çaplı olay
Etkilenen bileşenler
Continuous Delivery - Next Generation (CDNG)
monitoring
Prod2'deki sıkı boru hatları izliyoruz. Yeni infazlar, hizmetleri sürekli takip ettiğimiz gibi geçiyor.
monitoring
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.
resolved
Bu olay çözüldü.
postmortem
# **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.
Editing 'Variable Sets' in the IaCM module is experiencing issue
Başlangıç 4 Ağustos 2026 12:07 UTC · 3h 21m
IssuesKüçük çaplı olay
Etkilenen bileşenler
Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)
investigating
We are currently investigating this issue.
investigating
We are continuing to investigate this issue.
investigating
We have identified the issue and started to implement the fix , prod2 is restored.
investigating
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
investigating
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
resolved
This incident has been resolved.
postmortem
# 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.
Legacy Dashboards - Degraded
Başlangıç 3 Ağustos 2026 03:08 UTC · 2h 45m
IssuesKüçük çaplı olay
Etkilenen bileşenler
Custom Dashboards
investigating
Şu anda bu konuyu araştırıyoruz.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
UI panjurları geride kalıyor (CI)
Başlangıç 31 Temmuz 2026 20:22 UTC · 12h 48m
Pending
Etkilenen bileşenler
Continuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud BuildsContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud Builds
investigating
Şu anda bu konuyu araştırıyoruz.
identified
Sorun tespit edildi ve bir düzeltme uygulanır.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
postmortem
# **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.
Harness Artifact Sicil yükleme boru hattından başarısız oluyor - EU1 bölgesi
Başlangıç 31 Temmuz 2026 13:48 UTC · 1d 10h
IssuesKüçük çaplı olay
Etkilenen bileşenler
Artifact Registry
investigating
Şu anda bu konuyu araştırıyoruz.
identified
Sorun tespit edildi ve bir düzeltme uygulanır.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
postmortem
# **Summary**
On July 31, 2026, artifact uploads performed through pipeline in the EU1 cluster began failing with an authentication error. Uploads initiated manually \(outside of a pipeline\) were not affected, and the ability to retrieve existing artifacts \(downloads\) was also unaffected — this was isolated to the specific pipeline upload path in one cluster.
# **Impact**
* Artifact uploads performed through pipeline in the EU1 cluster failed with an authentication error for approximately 4 hours and 34 minutes.
* Retrieving existing artifacts \(downloads\) was not affected.
* Manually uploading artifacts outside of a pipeline was not affected.
* Other clusters/regions were not affected by this issue.
# **Root Cause**
The component responsible for handling pipeline-based artifact uploads is distributed as a container image. In the EU1 cluster, this image is retrieved from an internal registry that mirrors a public image source; in other clusters, the same image is retrieved directly from the public source.
A publishing error in our release process caused a new build of this component to be published using a version label that was already in use, rather than being assigned a new, unique version. As a result, two different images ended up associated with the same version label in the public source.
Our internal registry mirrors images from the public source via an automated replication process. Because of how that replication was triggered, it copied the original \(earlier\) image associated with that version label rather than the corrected one. This meant the EU1 cluster — which pulls from the internal mirror — ended up running a different, defective image than other clusters, which pull directly from the public source and therefore received the corrected image. The defective image contained an authentication issue that caused pipeline uploads to fail.
# **Mitigation**
* Reverted the affected account to the last known-good version of the upload component, immediately restoring pipeline uploads.
* Published a corrected, permanent version of the component to resolve the issue across all clusters.
# **Next steps**
* Fix the upload step to remove the underlying container-related defect that made this failure mode possible.
* Update our release pipeline for this component so that publishing an image can never overwrite an existing version — every publish must create a new, distinct version going forward.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
VM'leri Etkileyen Dış Ağ Bağımlılığı Sorunları
Başlangıç 30 Temmuz 2026 05:59 UTC · 21h 24m
IssuesKüçük çaplı olay
Etkilenen bileşenler
Continuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud Builds
investigating
Ö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.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
monitoring
Daha fazla sorun için izlemeye devam ediyoruz.
resolved
Bu olay çözüldü.
postmortem
## 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.
Prod3 Filestore HTTP 500 hatayla başarısız
Başlangıç 27 Temmuz 2026 09:09 UTC · 4h 24m
OutageBüyük çaplı olay
Etkilenen bileşenler
Continuous Delivery (CD) - FirstGen - EOS
investigating
Şu anda bu konuyu araştırıyoruz.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Prod3 & Prod1 ortamı geçici kesintiler yaşıyor. Şu anda konuyu araştırıyoruz.
Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
monitoring
Daha fazla sorun için izlemeye devam ediyoruz.
resolved
Bu olay çözüldü.
postmortem
# Summary
During a recent production deployment, a defect in our internal deployment tooling caused two critical services to run with incorrect, non-production configuration values in our production environment This led to a related set of four distinct symptoms: incorrect configuration behavior, intermittent login/access failures, a filestore access issue affecting one customer environment, and delayed pipeline status updates in the UI.
We have identified and are implementing a permanent fix for the underlying configuration defect, and have already put in place resource and capacity changes that resolve the UI delay symptom.
At no point during this incident were pipeline executions themselves lost, corrupted, or left in a stuck state. Where execution behavior was affected, it was limited to delays in status visibility, not in the underlying processing.
# Incident Details
## Incorrect Production Configuration Values Applied
Our engineering team confirmed a defect in the Service Manager deployment pipeline that caused certain production services to be deployed using configuration values intended for a different environment, rather than the correct production configuration.
**Root Cause**
The service responsible for fetching configuration overrides during deployment queries an internal API that returns a maximum of 1,000 results per request. The total number of services in the environment recently grew beyond that limit. As a result, any service beyond the first 1,000 returned was not included in the response, and the deployment pipeline silently fell back to default configuration values for those services. This is a confirmed pagination defect in the deployment tooling, not an issue with the configuration values themselves.
**Resolution**
Engineering has confirmed the mechanism and is implementing a permanent fix to remove this limit-related gap in the deployment pipeline.
## Intermittent Login / Access Failures
During the Service Manager deployment referenced above, some users experienced intermittent login or access failures. Under normal operation, previously running instances should continue serving traffic without interruption while a new deployment is in progress. In this incident, that fallback behavior did not occur as expected, contributing to access failures during the deployment window.
## Filestore Access Issue
A filestore access issue was identified that was specific to the Prod-3 environment and affected a single customer's environment.
**Root Cause**
This is related to an IAM / storage-bucket permission configuration on Service Manager, potentially triggered by rollback activity.
## Delayed Pipeline Execution Status Updates in UI
Some users observed that the pipeline execution graph in the UI was slow to refresh and did not reflect the latest status promptly. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were stuck or failed as a result of this issue.
**Root Cause**
The pipeline execution graph relies on a message stream \(the orchestration log\) to receive status updates. During the incident window, consumer processing of this stream fell behind \(high consumer lag\), which delayed how quickly status updates reached the UI. This was caused by the fact that the underlying database was in the middle of a planned scaling operation at the same time, and a traffic spike during that window further exacerbated the delay. Users experienced this as apparent pipeline slowness, even though the underlying executions were running normally.
**Resolution**
We have increased resource capacity for the affected components to maintain more than 50% spare headroom going forward, reducing sensitivity to similar load spikes. This change has been implemented and is currently being validated as part of longer-term hardening for this part of the platform.
# Impact Summary
* Service Manager and License Manager ran with incorrect configuration values in the Prod-1 and Prod-3 environments.
* Some users experienced intermittent login or access failures during the affected deployment window.
* One customer environment in Prod-3 experienced a filestore access issue.
* Users across affected environments saw delayed pipeline execution status updates in the UI; underlying pipeline executions continued to run correctly and were not lost, stuck, or corrupted.
# Preventive Actions
The following corrective and preventive actions have been identified.
| **Corrective / Preventive Action** |
| --- |
| Correct the pagination limit in the configuration-lookup service so that all services are returned and evaluated, regardless of total count. |
| Add safeguards so that a service which cannot retrieve its configuration fails safely \(e.g. alerts and blocks the deployment\) rather than silently falling back to non-production defaults. |
| Increase Postgres and messaging-pipeline resource headroom \(target: greater than 50% spare capacity\) to reduce sensitivity to concurrent load and scaling events. |
_We recognize the impact this incident had across multiple areas of the platform and appreciate your patience as we work through a complete resolution._
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.
identified
Sorun tespit edildi ve bir düzeltme uygulanır.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
postmortem
# # # Özet
Prod1, Prod2 ve Prod3 kümeleri, 2026 Temmuz'da AIDI 2.0 panolarına eriştiğinde geçici bir yükleme kutusu başarısızlıkları yaşadı. Tüm widget'lar aynı anda tam bir kesinti yerine sporadik başarısızlıklar olarak ortaya çıktı.
Hiçbir müşteri verileri kaybedilmedi. SEI 1.0 müşterileri etkilenmedi.
# # # Root Cause
Zamanla, rutin bir veritabanı bakım süreci analitik veritabanımızda bazı tablolarda başarısız oldu, bu masaların silinmiş kayıtları takip etmek için kullanılan geniş bir iç metadata hacmi kazanmasına neden oldu. Veritabanı bu tablolara karşı sorgular planlandığında, tüm bu bir metadata'yı hafızaya yükledi, etkilenen düğümlere defalarca hafıza kullanımına neden oldu. Bu tekrarlanan artışlar aşırı hafıza basıncı tespit ettiğinde otomatik bir güvenlik mekanizması başlattı ve etkilenen düğümler bir döngüde bir sonuç olarak yeniden başladı. Bu, olay süresi için AIDI 2.0 panolarında geçici sorgu performansına neden oldu.
## Effects
Prod1, Prod2 ve Prod3 kümes üzerindeki müşteriler, AIDI 2.0 panolarında geçici pencere yükleme başarısızlıkları veya daha fazla yükleme süreleri yaşamış olabilir.
**Durasyon: ** 22 Temmuz 2026, 07:58 PDT - 16:16 PDT \ (~8 saat 18 dakika), geçici widget başarısızlıkları ile; sistem yeniden başlatıldı ve 08:25 PDT'den aktif bir şekilde takip edildi.
### Ne etkilendi?
* Data ingestion and processing
* SEI 1.0 müşteriler
* Entegrasyonlar ve metadata akışlar
Hiçbir müşteri verileri kaybedilmedi.
## Remediation
Sorunu tespit ettikten sonra, etkilenen veritabanı düğümleri ilk istikrarı restore eden 08:25 PDT'de yeniden başlatılmıştır. Sistemi yakından takip etmeye devam ettik ve intermittent bozulması hala daha sonra gözlemlendiğinde, birkaç ek düzeltme uygulandık:
* Metadata'yı işlemek için kullanılan hafıza miktarını sınırlamak için veritabanı yapılandırma ayarlarını optimize edin ve hafıza basıncı azaltmak için planlayıcı ayarlar.
* Ran etkilenen masalarda metadata'nın geri kalanını azaltmak için işleri temizliyor.
* etkilenen veritabanı düğümleri üzerinde artan kapasite ek oda sağlamak için.
Bu değişiklikler sistemi ilerici bir şekilde stabilize etti ve olay 16:16 PDT'de tamamen çözülmüştü.
## Action Elements
Recurrence önlemek için aşağıdakileri uyguluyoruz:
1. Aşırı silin dosyaların neden olduğu hafıza aksaklarını işleyen temel iyileştirmeleri içeren arka uçları geliştirdik.
2. Yeni ortaya çıkan tablolar için otomatik kompaktlama işleri yaptık, dosya birikiminin ilerlemesini engellemek için.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Degraded CI performans
Başlangıç 17 Temmuz 2026 17:16 UTC · 4h 40m
IssuesKüçük çaplı olay
Etkilenen bileşenler
Continuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud Builds
investigating
Şu anda bu konuyu araştırıyoruz.
identified
Sorun tespit edildi ve bir düzeltme uygulanır.
monitoring
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
resolved
Bu olay çözüldü.
postmortem
# Ö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.