Prod2は断続的に利用できませんでした
Pending
影響を受けたコンポーネント
Platform
- investigating
現在、この問題を調査中です.
- resolved
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
82 Split incidents · 2026年4月 — official updates, affected components, duration and resolution details.
現在、この問題を調査中です.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
パイプラインの実行はProd1でスタックされます。 課題を調査しています.
修正を実装し、結果を監視しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
## 概要 2026年8月27日～8月28日の間に、一部のパイプライン、デプロイメント、および関連リソースがハーネスUIやAPIに見つからない問題が発生しました。 内部プラットフォームサービス間の通信に影響する計画された内部インフラ更新中に発生した問題。 その結果、アカウント、組織、およびプロジェクトスコープの解像度に依存するリクエストは正常に完了できませんでした。これにより、既存のエンティティティのために顧客に返される応答が見つかりませんでした。 エンジニアリングは、問題を特定し、変更をロールバックし、通常のサービスを復元しました。 事故時に顧客データが紛失または削除されたことはありません。 ## 根本原因 今回の問題は、生産計画された内部サービスルーティング更新中に導入された設定エラーによって引き起こされました。 変更後の他のハーネスサービスからのリクエストを検証できなかったアカウント、組織、プロジェクトコンテキストの解決を担当する内部プラットフォームサービス。 多くのエンティティティティが読み、パイプライン関連のアクションを進める前に検証ステップが必要であるため、通常存在し続けたリソースのエラーが見つかりませんでした。 問題は、影響を受ける生産環境に限られ、以前のサービス通信経路の変更と復元を反転することによって解決されました。 ## インパクト * 一部の顧客は、UIとAPIに見つからないように、既存のパイプライン、デプロイメント、および関連するエンティティティが現れています。 * 実行進行、webhook-triggered の起動、スケジュールされたトリガーの評価、およびエンティティティティリストを含むパイプライン関連の操作は、一時的に中断されました。 * 既存のエンティティティの可用性や可視性に影響した問題は、データを削除したり、顧客設定を変更したりしなかった。 ※ 不正なアクセスが発生しず、お客様のデータ損失は認められません。 ## 修正 * * 即時:** インフラ構成の更新を反転し、以前に作業したサービス通信経路を復元しました。 ***回復検証:** 影響を受けたエンティティティティエントのルックアップ、パイプライン操作、および依存する API がロールバック後に正常に機能していたことを確認しました。 *****お名前 更新に関連する設定処理を修正したので、同様の問題は、将来のロールアウトにおけるサービスツーサービス認証に干渉しません。 ## アクションアイテム そのような問題が再び起きるのを防ぐため、ハーネスは 1。 生産トラフィックをシフトする前に、内部サービス通信を検証するために、事前開発テストを強化することにより、設定検証を改善します。 2.内部認証障害の監視と警告を強化し、問題を早期に検出することができます。 3。 エラー処理を改善し、依存性障害は、リソースが見つかったエラーとして顧客に表示される可能性が低いです.
公式のインシデント更新を自動翻訳しています。
現在、Prod-1、Prod-2、Prod-4、EU1ハーネスクラスターのIACMパイプラインで報告された問題について調査しています.
今後もこの問題について調査を続けてまいります.
すべてのクラスターでこの問題を引き起こした変更を反転しました.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
現在、機能管理と実験(FME)のユーザーインターフェイスがロードできないと報告しています。 FME コンソールにアクセスしようとするお客様は、エラーやレスポンシブなページが発生することがあります。 特徴の旗の評価およびSDKの交通は影響を受けると信じません。 アップデートが短時間で続きます.
修正を実装し、結果を監視しています.
この事件は解決しました.
## 概要 * 8月23日、2026日は23:42 UTC**で開始し、FME UIをロードする故障が報告されました。 * FME UIアーティファクトは、保持ポリシーにより期限が切れたCDNから提供され、FME UIはロードできません。 * API によるフラグリクエストの変更、配信の変更、データパイプラインの中断無しで作業を続けた。 ## 根本原因 * CDNからFME UIが配信されます。 UI のアーティファクトは、保持ポリシーにより悪用され、UI がすべてのユーザーの読み込みに失敗しました。 ## インパクト ※ FME UI は、全ての生産環境で全てのユーザに読み込まれることができません。 ### 影響を受けなかったこと ※SDK機能とランタイムフラグ評価 * 管理者API呼び出し * 顧客フラグ構成データ ※データ損失が発生しません ## 修正 * FME UI は、展開を通じて CDN に復元されました ※事故を閉止する前に、全ての生産環境で回復確認 ## アクションアイテム ※現行のアクティブバージョンが逸脱する可能性があるため、資産保持ポリシーを改善します.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
低下は、以下の症状のいずれかを引き起こす可能性があります。 - パイプラインは始まりません - 実行中の遅延 - タイムアウトによるパイプラインのキャンセル
当社のクラウドプロバイダは、アクティブなインシデントに直面しています.
今後もこの問題について調査を続けてまいります.
クラウドプロバイダーは、複数の地域に影響する継続的なインシデントを確認しました。 ハーネスパイプラインは結果的に失敗を経験していませんが、一部のユーザーは引き続き遅い経験を継続できます。 状況を密接に監視し、情報が増えるにつれて更新を行います.
クラウドプロバイダーが実装した修正に従って、ボード全体でレイテンシーを向上しています。 今後も状況を監視し、さらなるアップデートを保証いたします。 顧客数のCIの実行に立ち向かっていました
この事件は解決しました.
# まとめ 2026年8月20日、Harnessプラットフォームは、生産環境全体で広範囲にわたる性能劣化を経験しました。 通常、約2分で完了したパイプラインの実行は7〜10分かかります。 継続的な配信、継続的統合、パイプラインのオーケストレーション、および機能管理と実験はすべて影響を受けました。 Google Cloud Platform は、Bigtable、Compute Engine、Google Kubernetes Engine、Persistent-disk I/O に影響を及ぼす、弊社-west1 地域における複数の製品インシデントを経験しました。ハーネスの生産インフラは、その地域の持続的なディスク上で動作します。 劣化は、約2msから95パーセントで10ms以上までのデータベース動作遅延を上げ、メッセージキュー処理の遅延を引き起こし、タイムリーなデータベースアクセスに依存するすべてのサービスに伝播しました。 # インパクト これは劣化ではなく、劣化でした。 パイプラインは、実行を続け、全体で正常に完了します。失敗するのではなく、遅くなりました。 データが失われず、この事件の結果として顧客作業が低下しませんでした。 #**ルート原因** 影響を受ける環境におけるハーネスの生産インフラは、Google Cloud Platform の永続ディスクで実行されます。 その記憶層が劣化すると、予測可能なチェーンでプラットフォームを介して推進される効果: **永続的ディスクI/Oは、当社西1で劣化します。** Google Cloud Platformは、Bigtable、Compute Engine、Google Kubernetes Engine、Persistent-diskのパフォーマンスに影響を及ぼす複数の製品インシデントを経験しました。 プロバイダーの環境下でのインフラ障害で、ハーネスの制御外でした。 #**予防措置** ハーネスはクラウドプロバイダのインフラ障害を防止できませんが。 以下の行動は、より速く1つを検出し、それを行動するためにより良い位置にあることを目的としています。 |**アクション** | お問い合わせ | 標的クロスレギオンデータベースの障害の定期的な事前テストを続けて下さい。この事件で実行されるように、想定されるよりもフェイルオーバーの信頼性を検証し続けるために | | 交差規制の遅延が許されない将来のシナリオのためのフルスタックマルチレギオン障害の信頼性を評価 |
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
#### 概要 8月 20, 2026, 10:24 と 14:55 UTC の間, FME のサブセットが失敗しました. FME UI から作られた書き込みとハーネスアクセストークン \(PATs と SATs\) で作られた書き込みは影響を受けません。 Runtime フラグの評価は、正常に動作し続けます。 この問題は、共有ガバナンスサービスの最近の認証変更を元に戻し、14:55 UTCによって正常に返された影響を受けました。 ステータス: [https://status.harness.io/incidents/rhthgm7d5dkz](https://status.harness.io/incidents/rhthgm7d5dkz) ## 根本原因 共有ガバナンスサービスの認証されたインバウンドコールの変更は、FME が拒否された結果になります。 これらは、変更後にガバナンスサービスがもはや検証できないサービスツーサービス資格情報を書きます。 FME は、クライアントに HTTP 499 としてガバナンスの失敗を表し、ガバナンスポリシーが意図的に変更を拒否したときに使用される同じステータスを処理します。 499は、その否定的なパスで有効で予想される応答であるため、障害はアラートの停電のように見えなかったため、内部検出ではなく、顧客レポートからインシデントが識別されました。 ##インパクト * FMEのサブセットは、主にレガシーのSplit APIキーを使用して作られたもの、またはリクエストスケジューリングを変更した場合に失敗しました。 ※FME UIから作られた書き込みは影響しません。 *ハーネスアクセストークン\(PATとSATs\)を使用して書き込みは影響しません。 ※ランタイムフラグ評価は、通常継続しています。 ※データの損失は発生しません。 失敗した書き込みは適用されません。 ### 修正 ガバナンスサービスの認証変更をリセットしました。 欠陥のある書き込みはすぐに通常に戻ります。 ###アクションアイテム こんな問題が起きるのを防ぐため、 * ガバナンスが評価できないため、書き込みが失敗したときにハーネスは異なるエラー\(499\ではありません)を返しますので、意図的なポリシー拒否と混同しません。 * クライアントに直面しているステータスコードに依存するのではなく、ガバナンス評価コール自体にアラートを追加する。 ※ポリシー評価の認証サポートを拡大 *追加の書き込みシナリオのための自動カバレッジを拡大します.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
今後もこの問題について調査を続けてまいります.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
今後の問題がないか引き続き監視しています。
この事件は解決しました.
**概要** 19 8月2026日、12:35と17:29 UTCの間、ハーネスアプリケーションセキュリティサービスは、SaaS生産とUS1地域における顧客向けコンソールとデータ摂取パイプラインの両方に大きな混乱を経験しました。 **ルート原因** ほぼすべてのコンポーネントにランタイム設定を供給する内部設定サービスは、オーバーロードされ、リピートされた再起動サイクルに入りました。 多くのサービスはそれに依存しているため、効果は広範でした:保護ポリシー、姿勢ビュー、アクティビティログ、API在庫、カスタムポリシーなどのコンソールページがロードまたはタイムアウトに失敗し、設定を待ちながら、停止処理が取得できませんでした。 #**顧客のインパクト** | **寸法** | ** | お問い合わせ | | コンソール \(UI\) の影響 | 複数のページがロードまたはタイムアウトに失敗しました, 保護ポリシーを含みます, 姿勢イベントページやダッシュボードやインサイトページ内のビューを投稿, アクティビティログクエリ, API 在庫画面, カスタムポリシー, 機密データビューとウィジェット. お問い合わせ | 摂取の影響 | セキュリティテレメトリー処理が重度劣化し、一部経路では、完全に停止します。 消費者のラグは、正規化、グループ化、異常検知、生成、および関連する処理ステージで成長しました。 お問い合わせ | データの損失 | 中断時に発生するテレメトリーのサブセットが永久に低下しました。 お問い合わせ **住宅** いくつかの中間緩和追加のCPUとメモリ、リラックスした健康チェックのしきい値、データベースの再起動、およびより大きな接続プールは、問題を緩和しました。 影響力のある地域に新しい機能を解散し、スループットを鋭く回復しました。 事故は17:29 UTCで解決しました。 #**予防措置** 次のアクションは、内部で完了にコミットし、追跡されます。 このインシデントをトリガーした機能は無効のままであり、以下の作業が完了し、検証されるまで再有効ではありません。 |**アクション** | お問い合わせ お問い合わせ | キャッシュ・エビクションや保持などのパラメータを調整することでコードを最適化し、ルールカウントが成長するにつれて、バルク・ルール・レトリバルのカーソルベースのペジネーションを評価します | | サービススコープアクセスパターンの目的別データベースインデックスを追加 | | パイプラインの回復のセマティクスを解放して下さい従って消費者はバックログをスキップするのではなく位置のマーカーの損失の後で安全に再生します | | ダウンストリームのリクエストパターンを変化させる構成上書きのロールアウトをマンデート: 低ボリュームクラスター、その後のミッドボリューム、そして高ボリューム | | 構成サービスにバックプレッシャーやコンポレーション保護を追加:回路破壊、境界線のキュー、タイムアウトの分離 | | より詳細なメトリクスを計測することにより、保守性の向上 |
公式のインシデント更新を自動翻訳しています。
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 のスタックされたパイプラインを監視しています。 サービスの継続的な監視のため、新しい実行が通過しています.
Prod2 のスタックされたパイプラインを監視しています。 まだまだ立ち向かうパイプラインを眺めているお客様には、中絶・再トリガーをお願いしております.
この事件は解決しました.
##**概要** 2026年8月6日、Prod2生産環境でパイプラインを実行している一部の顧客は、進捗を中止したパイプラインの実行を観察しました。さらに出力やステータスの更新を行わないステージです。 影響を受けたお客さまからの問題が報告されました。 ハーネスエンジニアは、原因を特定し、衝撃を緩和し、通常の動作に戻ったパイプラインの実行を緩和しました。 問題は、自己反射パイプライン式によって引き起こされました。 Git の webhook は webhook のペイロードの内容を参照したパイプラインをトリガーし、ペイロード自体は、その同じ表現のさらなるコピーが含まれています。 式決議の各ラウンドにより、毎回作業量を倍増させるためのより多くの式が生成されます。 これは、その実行を処理するサービスインスタンスのリソースを排出し、同じインスタンスに割り当てられた他の実行は、その状態にある間に進行できませんでした。 ##**インパクト** インシデントウィンドウの時\(およそ6:11 AMから8月6、2026\の11:23 AM) * Prod2 のパイプラインの実行中は実行中を固定し、それ以上の進行をしませんでした。 * 新しいステップのアウトプットやステータスの更新を生成し、ミディゲーション後に中止・再実行する必要がなかった不具合の実行。 * Behaviorは、影響を受けるサービスインスタンスによって処理される実行に限定されていました。他のインスタンスが処理したパイプラインは、通常実行し続けました。 **データ損失なし**. パイプラインの定義、実行履歴、保存された状態が影響を受けていない。 Prod2のパイプラインの大部分は、事件全体で正常に実行し続けた。 主な影響は、問題が緩和されたら、いくつかの機内の実行が完了し、再実行する必要があることだった。 ##**ルート原因** ハーネスパイプラインは、実行時に解決する式をサポートしています。例えば、パイプラインをトリガーしたGit Webhookペイロードの内容をインサートする式です。 この場合、Gitコミットメッセージには、ペイロード式自体のリテラルテキスト、二度、パイプラインは同じペイロード式を参照しました。 コミットメッセージは webhook のペイロードの一部であるため、コミットメッセージで実行される式の 2 つのリテラル コピーを含む、ペイロード全体を差し込みます。 新しくインサートされたコピーは、解決する式として処理され、各パスはペイロードの2つの完全なコピーをインサートしました。 処理される値の大きさと、処理に必要な作業は、すべてのパスに倍増し、収束ではなく指数関数的に成長します。 ハーネスは、正確に停止するための保護策を持っています。式解像度は、解像度の半分とパイプラインが明示的なエラーで失敗するよりも、最大ネスティング深さによってバインドされます。 その保護策の欠陥は、この特定の自己反射症例では限界が適用されていないため、解決はチェックを外しました。 式分解能はパイプラインのステップを開始するスレッド上でインラインを実行します。 各パスは、これまで完了することなく、プログレッシブにより多くのメモリとCPUを消費したため、その作業が進行を中止し、そのインスタンスに割り当てられたすべての実行は、顧客が報告したものです。 ##**運転** ハーネスは、次の即時の緩和手順を完了しました。 * パイプラインと実行中の解像度に責任のある式パターンを識別しました。 * 影響を受けるサービスインスタンスを停止し、これ以上の作業をしないようにします。 残りの健康なインスタンスは、キューされた実行を正常に取得および処理します。 * パイプラインの実行が正常に戻り、インシデントを閉じることを確認します。 これらのアクションは、通常のパイプラインの実行動作を復元し、顧客の失敗の影響を解決しました。 ##**アクションアイテム** 再発のリスクを低減し、検出を改善するために、次の操作は、さまざまな段階の実装です。 * 式深さとループ検出保護に欠陥を固定し、自己反射式が捕捉され、境界なしでリソースを消費する代わりに明確なエラーで高速に失敗するようにします。 * ペイロード式がトリガーペイロードコンテンツから解決されないようにし、自己認証パスを完全に削除します。 * 既存の深さの限界に加えて、最大式のネスティング深さを締め、明示的なループ検出を評価します。 * 自己認証式パターンを再現し、セーフガードが検出し、停止することを検証する、試作前の環境で自動テストを強化します。 * パイプラインの実行中にこのパターンの監視を追加して、積極的に検出されます.
公式のインシデント更新を自動翻訳しています。
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.
現在、この問題を調査中です.
修正を実装し、結果を監視しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
#**概要** 2026年7月25日～8月4日の間に、ハーネスプロド2とプロド3クラスターのパイプライン実行ダッシュボードと概要ページがリアルタイムの背後にあるデータを表示します。 パイプライン自体は、全体的に正常にビルド、デプロイ、実行し続けてきました。問題は、レポートとダッシュボードビューを提供するデータベースに素早く実行レコードがコピーされた方法に限定されました。 **顧客データが失われない。** 影響を受けた記録は、ほとんど保存されず、基礎的な制限が解除されると分析データストアに再再生されました。 ハーネスは、影響を受けたクラスターを水平にスケーラブルに移行し、レプリケーションコンポーネントのキューバックバージョンは2026年8月1日に移行し、すべての影響を受けたアカウントのターゲットデータバックフィルが完成しました。 #**ルート原因** ハーネスは、主要な運用データストアからパイプラインの実行レコードを継続的にコピーし、ダッシュボードとレポートのクエリを最適化した別のタイムシリーズのデータストアに更新データキャプチャコンポーネントを維持します。 ダッシュボードは、分析データストアからのみ読み取ります。 レプリケーションが背後にあるとき、ダッシュボードは世界の正確で古いビューをレンダリングし、実行自体は影響を受けません。 これは、同じレプリケーションパスを共有する別のハーネスプラットフォームモジュールからデータベースの書き込みボリュームのシャープで持続的な増加によって引き起こされました。 古い、そのコンポーネントの単一インスタンスバージョンは、Prod 2とProd 3で実行されます。 バックログが形成され、成長しました。 #**予防措置** ハーネスは、そのような問題を防ぐため、次の行動に完了またはコミットしています。 |**アクション** | お問い合わせ | 定義されたしきい値を超えた遅延が通知されるように、レプリケーションラグの警告を微調整 | | 標準プラットフォーム監視ボードにレプリケーションラグパネルを追加し、デフォルトでパイプラインヘルスをオンコールに表示 | | 複製ストリームにフィルタリングするコテナントモジュールの書き込み増幅を削減 |
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
# **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.
公式のインシデント更新を自動翻訳しています。
概要 - ビルド VM の外部リソースに接続できないネットワーク接続の問題に直面しています。 現在、課題を調査中です.
修正を実装し、結果を監視しています.
今後の問題がないか引き続き監視しています。
この事件は解決しました.
## 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..
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
修正を実装し、結果を監視しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
今後もこの問題について調査を続けてまいります.
問題が特定され、修正が実装されています.
この問題の修正には引き続き取り組んでいます。
修正を実装し、結果を監視しています.
今後の問題がないか引き続き監視しています。
この事件は解決しました.
# まとめ 最近の生産展開では、社内展開ツールの不具合により、生産環境の不正確で非生産的な構成値で動作する2つの重要なサービスが実現しました。 これは、関連する4つの異なる症状のセットにつながりました。誤った構成の動作、断続的なログイン/アクセスの失敗、ファイルストアのアクセスの問題は、1つの顧客の環境に影響を及ぼし、UIのパイプライン状態の更新を遅らせました。 当社は、基本構成欠陥の恒久的な修正を識別し、実装しています。すでに、UI遅延症状を解決するリソースと容量の変更を配置しています。 このインシデント中にパイプラインの実行自体が失われた、破損、またはスタック状態に残された点ではなかった。 実行挙動が影響を受けた場合、進行中の処理ではなく、ステータスの可視性を遅らせることは限られていました。 # インシデントの詳細 ## 不適切な生産構成値が適用される 当社のエンジニアリングチームは、正しい生産構成ではなく、異なる環境のために意図した設定値を使用してデプロイされる特定の生産サービスを引き起こしたサービスマネージャのデプロイパイプラインの欠陥を確認しました。 **ルート原因** デプロイ中にコンフィギュレーションのオーバーライドを取得する責任のあるサービスは、リクエストごとに最大1,000件の結果を返す内部APIを問い合わせます。 環境におけるサービスの総数は、最近増加しました。 その結果、最初の1,000を超えるサービスが応答に含まれていなかったり、デプロイメントパイプラインは、これらのサービスに対してデフォルト設定値に戻りました。 これは、設定値自体の問題ではなく、展開ツールで確認されたペジネーションの欠陥です。 **決断** エンジニアリングは、機構を確認し、デプロイパイプライン内のこの制限関連のギャップを除去するための永続的な修正を実施しています。 ## 断続ログイン/アクセス失敗 上記のサービスマネージャの展開中に、一部のユーザーは、断続的なログインやアクセスの失敗を経験しました。 通常の操作では、新しい展開が進んでいる間、インスタンスを継続して中断することなくトラフィックをサービングする必要があります。 このインシデントでは、フォールバックの動作が予想どおりに行われなかったため、デプロイ時の障害へのアクセスに貢献しました。 ## ファイルストアアクセスの問題 ファイルストアアクセスの問題は、Prod-3 環境に特異的だったことを特定し、単一の顧客の環境に影響を与えました。 **ルート原因** これは、サービスマネージャーのIAM /ストレージ・バック・パーミッション・コンフィギュレーションに関連しています。 ## UI のパイプライン実行状況の更新遅延 一部のユーザーは、UI のパイプライン実行グラフが更新され、最新の状態を速やかに反映しなかったことを観察しました。 重要なのは、これは可視性遅延のみでした。実際のパイプラインの実行に影響がなかったため、この問題の結果として、実行がスタックまたは失敗しませんでした。 **ルート原因** パイプライン実行グラフは、ステータスの更新を受け取るために、メッセージストリーム\(オーケストレーションログ\)に依存しています。 インシデントウィンドウでは、このストリームの消費者処理が\(high Consumer lag\)の後ろに落ち、ステータスの更新がUIにどのように迅速に到達したかを遅らせました。 これは、計画されたスケーリング操作の途中で、そのウィンドウの間にトラフィックスピークがさらに遅延を悪化させたという事実によって引き起こされました。 ユーザーは、通常、基礎的な実行が実行されたにもかかわらず、明らかなパイプラインの低下としてこれを経験しました。 **決断** 影響を受けたコンポーネントのリソース容量を増加させ、今後50%以上のスペアヘッドルームを維持し、同様の負荷スパイクに対する感度を減らします。 この変更は実装されており、現在プラットフォームのこの部分の長期硬化の一環として検証されています。 # インパクトの概要 * サービスマネージャとライセンスマネージャは、Prod-1 および Prod-3 環境の誤った構成値で実行されます。 * 一部のユーザーは、影響を受けたデプロイウィンドウで断続的なログインやアクセス障害を経験しました。 * Prod-3 の 1 つの顧客の環境はファイルストアのアクセス問題を経験しました。 * 影響を受けた環境のユーザは、UI のパイプラインの実行状況の更新を遅らせました。パイプラインの実行は、正しく実行し続け、紛失、スタック、または破損しませんでした。 # 予防行動 以下の是正措置および予防措置が特定されました。 | **対応 / 予防措置** | お問い合わせ | 全サービスが全件数に関わらず、全てのサービスが返送・評価されるように、設定サービスのペジネーション制限を補正します。 | | 設定を取り戻すことができないサービスが、非生産のデフォルトに戻すのではなく、安全に\(例えば、アラートやブロックの展開\)を失敗させるように、セーフガードを追加します。 お問い合わせ | ポストグレスとメッセージングパイプラインのリソースヘッドルームを増加させる\(ターゲット:50%以上のスペアキャパシティ\)は、同時負荷およびスケーリングイベントに対する感度を削減します。 お問い合わせ このインシデントがプラットフォームの複数の領域に及ぼす影響を認識し、完全な解像度で動作するように忍耐を認めます。
公式のインシデント更新を自動翻訳しています。
AIDIダッシュボードに影響する課題を調査しています。 ダッシュボードにアクセスする際に、負荷時間が増加したり、断続的な故障が発生することがあります。 私たちのチームは、根本原因を特定し、通常のパフォーマンスを回復するために積極的に取り組んでいます。 最新情報をお届けいたします.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
## 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.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
# まとめ 2026年7月17日、ルーチンコードの展開に伴い、古いデリーゲートバージョンの顧客は、グローバルビルドキューイング機能を使用して、CIがハーネスクラウドでホストされているビルドに遅延した経験を始めました。 影響を受けたビルドは、予想されるサブ秒時間内で進むのではなく、「インフラの待ち合わせ」ステージで最大8分の予期しない一時停止を経験しました。 全体的なビルドの減速は断続的だった。 # インパクト *すべてのCIビルドは遅延の可能性があります。グローバルビルドキューイング機能を使用して、ハーネスクラウドホストインフラストラクチャの構築に最も顕著な影響がありました。 * 影響を受けたビルドは、継続して約8分前に、未明な一時停止を経験し、前保存されたコンピュートスロットが利用できなかったため、より遅い「コールドスタート」が続いた - これは、失敗をビルドするのではなく、遅いビルドとしてユーザーに提示しました。 ※ 新規登録したアカウントは、858xx以上\(858xx以上\)に影響しません。 ※この問題の直接的な結果として、ビルドが失敗し、データが失われない。 # 根本原因 根本的な原因は、特定のビルドキューイングレコードが、以前のバージョンのコードで既にキューに入れられたビルドが、新しくデプロイされたバージョンに遭遇した時に、データベースから読み返されたかを誤って壊れた内部コードの変更でした。 影響を受けたレコードをクリーンアップし、根本的なコード変更を逆転させることにより、即時の影響を解消し、再発の課題を防止するために、いくつかの安全対策を実施しています。 # 次のステップ 以下のような行動が不足していると、同様の再発のリスクを評価します。 このインシデントを引き起こした特定のコードパスは既に再変換され、コードベースではそうでなければ、この問題の一般的なクラスが再発できないように構造的保護策を実装しています。 | **対応 / 予防措置** | お問い合わせ | データベースに保存されるすべての内部データクラスに明示的、安定した識別子を追加し、将来の内部コードの再編成は、以前に保存されたレコードを読んだシステム能力を破ることができません。 お問い合わせ | 生産に達する前に、特にこの問題のクラスをキャッチするために設計された、試作環境でロールバックと後方互換性テストを導入。 お問い合わせ
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
今後の問題がないか引き続き監視しています。
この事件は解決しました.
# まとめ 6月19日と7月17日、2026年の間に、内蔵のGitクローンステップと、ドローン-gitクローンプラグインを使用してパイプラインステップ - ARM64 Kubernetesでエラーexec /usr/local/bin/cloneでインフラストラクチャを構築しました。 exec形式のエラー。 AMD64 \(Intel/AMD\)ビルド、Windowsビルド、VMコンテナレスバイナリパスは影響を受けていません。 根本的な原因は、ARM64-tagged 無人機-git 画像を実際にAMD64バイナリを含むように引き起こした内部画像の公開プロセスの欠陥でした。 ドローン-gitイメージを最終既知のバージョンに戻すことで報告された日と同じ日に問題を識別し、軽減しました。 顧客行動や構成変更は必要ありません。 # 根本原因 2026年6月19日、ドローン-gitイメージの仕組みを再構築しました。 AMD64 ビルドは正しく更新されましたが、ARM64 ビルドパイプラインは ARM64 ファイルを直接ビルドしなかったため、AMD64 ビルドファイルをテキスト置換で適応し、ARM64 インフラストラクチャ上でコンパイルしました。 6月19日はAMD64ファイルを変更し、置換が失敗するのではなく黙ってno-op'dを置換するので、パイプラインはGit CloneとGit LFSバイナリがAMD64のためにまだコンパイルされたARM64にタグ付けされた画像を発表しました。 # インパクト * Affected:内蔵のGitクローンステップ、およびドローン-gitクローンプラグインを使用してパイプラインステップ、ARM64 Kubernetesビルドインフラストラクチャ、7月6日から7月17日までのすべてのアカウントで実行します。 * Symptom: exec /usr/local/bin/clone で Git Clone ステップで失敗したビルド: exec 形式のエラー。 *影響を受けない:AMD64 \(Intel/AMD\)KubernetesとVMビルド、Windowsビルド、VMコンテナレス実行パス、および強化された画像のバリアント。 # ミティグレーション 過去の既知のリリースに影響を受けたすべてのサービスで使用されているドローン-gitイメージバージョンを反転させました。 ARM64 の実行失敗を完全に解決しました。顧客構成の変更は必要ありません。 # 次のステップ そのような問題が起きないようにするため。 * ARM64 イメージの公開パイプラインを再構築し、AMD64 ビルドファイルを適応するのではなく、専用の ARM64 ビルドファイルを直接ビルドします。 * イメージリリースごとに自動ポスト公開検証を強化:バイナリアーキテクチャがイメージタグにマッチし、イメージが再リリースされる前に機能的な煙テストを実行します。 * ARM64 Kubernetesビルドシナリオを含む自動テストカバレッジを拡大します。 * 修正されたリリースが検証されると、影響を受ける中間画像バージョンを循環から削除します.
公式のインシデント更新を自動翻訳しています。