Neo4j Aura の障害履歴

1. 2026年10月26日 14:50 UTCinvestigating

   現在、データベースインスタンスのスナップショットをダウンロードしようとすると、Aura on Azure を使用して顧客に影響を与える問題が認識されています.

2. 2026年10月26日 15:09 UTCidentified

   問題を特定し、現在修正の展開に取り組んでいます.

3. 2026年10月26日 16:22 UTCidentified

   修正は現在、デプロイ前の環境下でテストされています.

4. 2026年10月26日 17:43 UTCidentified

   修正のテストは進行中であり、テストが完了すると展開が進行します.

5. 2026年10月26日 19:14 UTCresolved

   当社のエンジニアは、正常に修正をデプロイし、問題が解決しました。 Azure の Aura のお客様は、問題なくデータベースのスナップショットをダウンロードできるようになりました.

公式のインシデント更新を自動翻訳しています。

1. 2026年10月20日 7:35 UTCinvestigating

   現在、地域におけるデータベースインスタンス作成を含む一部の運用に影響を及ぼすGCPの欧州西2地域に影響を与える問題について調査しています.

2. 2026年10月20日 8:36 UTCinvestigating

   現在、GCP と連携して解決策を講じています。 この時点では、地域内のデータベースインスタンス作成を含むいくつかの操作が影響を受け続ける.

3. 2026年10月20日 9:15 UTCidentified

   GCP では、現在消費者に影響を及ぼしている問題のソースを特定しています。 詳細は、https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj の GCP ステータスページから入手してください。 この時点では、地域内のデータベースインスタンス作成を含むいくつかの操作が影響を受け続ける.

4. 2026年10月20日 10:42 UTCidentified

   現在、問題を軽減するための是正措置を実施中です。 https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj のステータスページで最新の GCP をフォローしてください.

5. 2026年10月20日 12:38 UTCmonitoring

   影響を受ける Aura サービスに機能が復元されるようになりました。 解決する前に、状況を密接に監視します.

6. 2026年10月20日 14:06 UTCmonitoring

   現時点ではGCPの状況を監視し続けており、この時点では新しい問題が見つかりませんでした.

7. 2026年10月20日 14:50 UTCresolved

   この事件は解決しました

公式のインシデント更新を自動翻訳しています。

1. 2026年10月13日 9:15 UTCinvestigating

   Aura Consoleでメトリクスに影響を及ぼす問題やメトリックエンドポイントを経由して調査しています.

2. 2026年10月13日 10:13 UTCidentified

   クラウドサービスプロバイダ関連の問題が現状に影響を及ぼしていると確認しました。 クラウドサービスプロバイダでサポートケースをオープンし、詳細を追って更新します.

3. 2026年10月13日 11:01 UTCmonitoring

   クラウドサービスプロバイダの問題は、内部システムの問題が見つからなくなったため、解決されています。 引き続き、クラウドサービスプロバイダからの確認をお待ちしています.

4. 2026年10月13日 12:08 UTCresolved

   問題が解決したクラウドサービスプロバイダから確認しました.

5. 2026年10月16日 17:06 UTCpostmortem

   **GCP europe-west1** からメトリックを送信したときにエラー **何が起こったのか** 10月13日(火)、854 UTCで2026、GCP europe-west1のインスタンスのメトリックは配信されず、読み取れません。 原因は Google Cloud 側の問題で、監視サービスの容量削減が誤って拒否された有効な要求につながりました。 Google Cloud が修正を適用した後、10:49 UTC で通常のメトリックに戻り、Google Cloud が完全な解像度を確認したら 12:08 UTC でインシデントを解決しました。 Instancesは、クエリのパフォーマンスやデータの完全性に影響を与えない、このイベント全体で利用可能に残ります。 メトリックの可視性のみが影響されました。 **サービスが影響を受けた場合** Customers はインスタンスの metrics: のギャップをいくつか見ました * **コンソールメトリック:** GCP europe-west1 のインスタンスは、インシデント ウィンドウのインシデント データの不完全または欠落を表示している可能性があります。 * **クラウド監視統合\(CMI\):** この領域から独自の監視システムに転送されるメトリックは、ギャップを持つ可能性があります。 地域内のすべてのインスタンスが影響されず、他のクラウドプロバイダや地域は影響を受けていない。 インシデント中に生成されたメトリックが記録されていないため、影響を受けたインスタンスの履歴チャートにギャップが残されます。 **今や何をしているか** この機会にGoogle Cloudから修正されましたが、当社のメトリックスパイプラインは単一領域パスに依存しているため、その露出を削減するための手順を講じています。 * **地域レジリエンス:** クロスレギュレーションルーティングを評価するため、メトリクストラフィックは健康な領域に失敗することができます。 * **トラフィックルーティング:** クラウド・ネットワーク・レイヤーのオプションを調べて、読み込み\(Console と CMI\) をリルートし、インパクトのある領域から\(ingestion\) を記述します。

公式のインシデント更新を自動翻訳しています。

1. 2026年10月8日 14:58 UTCinvestigating

   Aura Console のメトリックとメトリックのエンドポイントでの問題を調査しています.

2. 2026年10月8日 15:36 UTCidentified

   根本原因を調査し続けています。 問題は、GCP でお客様に限定されています。 Auraインスタンスが実行され、操作は影響を受けません.

3. 2026年10月8日 16:30 UTCidentified

   クラウドサービスプロバイダと協力し、問題の性質を調査しています。 当社のチェックは、当社に拠点を置くお客様のみが影響を受けることを確認します.

4. 2026年10月8日 18:41 UTCidentified

   今後もクラウドサービスプロバイダと連携し、ソリューションをお届けしてまいります.

5. 2026年10月8日 19:11 UTCresolved

   このインシデントが解決しました。メトリックは正常に動作するはずです.

6. 2026年10月16日 17:04 UTCpostmortem

   **GCPのメトリックをGCPから送信する場合のエラー1** **何が起こったのか** 2026年10月8日(木)14:05 UTC、GCP us-central1のインスタンスからのメトリックが配信停止しました。 原因は、有効なメトリックリクエストを誤って拒否したGoogle Cloud側の問題でした。 Google Cloud が修正後、18:48 UTC でメトリック配信を再開し、18:48 UTC. でインシデントを解決しました。 Instancesは、クエリのパフォーマンスやデータの完全性に影響を与えない、このイベント全体で利用可能に残ります。 メトリックの可視性のみが一時的に影響されました。 **サービスが影響を受けた場合** 顧客はインスタンスのmetrics: のギャップを見ました * **コンソールメトリック:** GCP us-central1 のインスタンスは、インシデント ウィンドウのインシデント データの不完全または欠落を表示している可能性があります。 * **クラウド監視統合\(CMI\):** この領域から独自の監視システムに転送されるメトリックは、ギャップを持つ可能性があります。 地域内のすべてのインスタンスが影響されず、他のクラウドプロバイダーや地域が影響を受けていない。 **今や何をしているか** この修正はGoogleクラウドから来ましたが、今後同様のイベントをキャッチして対応する手順を講じています。 * **メトリックデリバリーエラーの警告:** メトリック転送エラーレートにアラートを追加するので、プロバイダー側のエラーは以前検出され、ルーチンギャップから区別されます。 * **準拠監視:** 再発のためにGoogleクラウドで地域を監視します。

公式のインシデント更新を自動翻訳しています。

1. 2026年10月6日 9:22 UTCinvestigating

   バックアップが正常に完了しているにもかかわらず、スナップショットのダウンロードは空白のダンプを返す問題を調査しています。 Aura コンソールまたは API を介してスナップショットから復元することは影響を受けると考えられず、現在検証中です。 情報が増えるとすぐに更新情報を共有します.

2. 2026年10月6日 10:43 UTCinvestigating

   課題を調査し続けています。 この問題の一部として、復元操作は影響を受けません.

3. 2026年10月6日 13:41 UTCinvestigating

   今後もこの問題について調査を続けてまいります.

4. 2026年10月6日 13:41 UTCinvestigating

   この問題は引き続き調査中です。

5. 2026年10月6日 15:19 UTCresolved

   修正が展開されました。スナップショットのダウンロードには適切なデータが含まれています.

6. 2026年10月26日 8:58 UTCpostmortem

   # 何が起こったのか 2026年9月18日(金)14:33 UTCでは、AzureでホストされているAuraインスタンスのスナップショットダウンロードが予想されるマルチギガバイトサイズではなく、約24KBのファイルを返すことを確認しました。 Azure で保存された基本的なバックアップは正しいサイズでしたが、コンソールのダウンロードパスは、ほぼ空のファイルを提供していました。 根本的な原因は、デプロイ中に発生したAzureクレデンシャルの問題であり、ダウンロードのために提供されるバックアップデータを防止しました。 初期修正は、月、21 Sep 2026 10:31 UTC に展開され、正しいダウンロードサイズを復元しました。 しかし、同じクレデンシャルの問題は、火曜日、06 Oct 2026 08:20 UTCで再発され、再びすべてのAzure層に空白のスナップショットのダウンロードを生成します。 当社のエンジニアリングチームは、再発を識別し、同じ根本原因にリンクし、生産にターゲットを絞ったクレデンシャルフィックスを配備し、予想されるサイズに戻ってダウンロードを確認しました。 9月18日(土)のステータスページには、少数のお客さまが影響を受けたため、直接対応しました。 10月6日(火)に10月22日(日)に、再発の約1時間後、明らかにより広まっていた。 # サービスがどのように影響を受けたか スナップショットのダウンロードは、AuraDS ProfessionalとEnterprise、AuraDB Professional、ビジネスクリティカル、およびAzure上で実行されている仮想専用クラウドインスタンスに影響されました。 * スナップショットのダウンロードは、使用できないファイルを返しました。 コンソールからスナップショットをダウンロードすると、実際のバックアップデータではなく、およそ24KBのファイルが受信され、サイズが複数のギガバイトになる可能性があります。 ダウンロードしたスナップショットはオフライン復元または移行の目的で使用できません。 * バックアップ自体は失われていませんでした。 Azure に保存されている基本的なバックアップアーティファクトはそのままで、正しくサイズ化されています。 問題は、バックアップキャプチャやストレージプロセスではなく、ダウンロードパスに厳密にありました。 * コンソールを経由して復元しても影響を受けません。 プラットフォーム内の復元操作 \(ダンプファイル\をダウンロードするのではなく) は、影響を受けたダウンロードパスではなく、バックアップデータに直接アクセスしたため、機能し続けた。 # わたしたちが今何をしているか 課題を解決し、再発を防ぐための保護策を講じています。 * 展開される Credential の苦境。 Azureクレデンシャルの問題は、すべての影響を受けたインスタンスのスナップショットのダウンロードを即座に復元した状態で修正しました。 * 意図されていない定形回転を防ぐ。 あらゆる展開でAzureクレデンシャル・ローテーションをトリガーしたロジックを変換するためにコード変更を提出しました。 これにより、将来のデプロイメントは、初期インシデントと再発の両方を引き起こしたメカニズムが、既存の資格情報を無効にしないことを保証します。 * 監視の開始。 Azure のスナップショットのダウンロードを監視し、すべてのティアを監視して、安定した状態に保ちます。 お客様が、ダウンロードが予想されるファイルサイズを返すことを確認するよう求めました。 これらの変更は、問題が再発することを可能にする即時の症状と根本的な展開行動の両方に対処します

公式のインシデント更新を自動翻訳しています。

1. 2026年10月6日 8:07 UTCidentified

   AuraDSのスナップショットから復元しようとすると、問題を特定しました。 修正準備ができてすぐに展開します。 代わりに、バックアップから復元できます.

2. 2026年10月6日 9:07 UTCidentified

   根本原因を明らかにし、この問題の修正に引き続き取り組んでまいります.

3. 2026年10月6日 10:03 UTCidentified

   今後も本問題の修正に取り組んでまいります.

4. 2026年10月6日 12:14 UTCidentified

   修正が展開され、影響を受けた顧客に短時間でロールアウトされます.

5. 2026年10月6日 13:35 UTCmonitoring

   修正は転がり、影響を受けた顧客は機能が進歩的に元通りに復元されていることを見るべきです.

6. 2026年10月6日 14:04 UTCresolved

   弊社では、全てのお客様に修正を行っております.

7. 2026年10月26日 8:51 UTCpostmortem

   # 何が起こったのか Neo4j Auraのスナップショット復元の中央管理コンポーネントのソフトウェアは、AWSでホストされているAuraDS ProfessionalおよびAuraDS Enterpriseインスタンスの失敗に失敗します。 復元が要求されると、システムが誤ったリソースタイプを使用してインスタンスを調べ、エラーを返します。 10月05日(月)2026日(月)21:52 UTCにてお知らせいただきました。 当社のエンジニアリングチームは、根本原因を特定し、修正を行い、火曜日、06 Oct 2026 13:37 UTCで生産に展開しました。 # サービスがどのように影響を受けたか AuraDS Professional および AuraDS Enterprise インスタンスの復元操作をスナップショットするインパクトがスコープ化されました。 Aura Console や Aura API を経由してスナップショットを復元できない不具合が発生しました。 * 返されたエラーを復元し、スナップショット復元に依存するワークフローを中断します。 ※本イベントでは、本イベントを通しての連絡が残っています。 データの完全性は影響しません。 完全なバックアップとエクスポートされたバックアップから復元しても、回避策として利用できます。 # わたしたちが今何をしているか ※オーラズ・プロフェッショナルとオーラズ・エンタープライズ・スナップショットの復元に影響を受けたオーラの経営層に不具合を修正し、生産の修正を行いました。 * デプロイメントパイプラインの最適化: このインシデント中に、デプロイパイプラインは、シーケンシャルテストインスタンス作成による理想的なものよりも長くなりました。 重要なロールアウト時に待機時間を削減するためにテストインスタンスの作成を並列化しました。 この改善は、将来の事故の修正を検証し、出荷するのに要する時間を短縮し、顧客に直面している影響を減らすことを目指しています

公式のインシデント更新を自動翻訳しています。

1. 2026年9月17日 16:46 UTCinvestigating

   現在、Aura on Azureを利用している顧客向けに、作成、削除、クローンなどの特定のデータベース操作に影響を及ぼす問題が認識されています.

2. 2026年9月17日 17:11 UTCidentified

   問題を特定し、解決に向けて取り組んでいます。 現時点では、Neo4j AuraをAzureで使用している顧客向けに作成、削除、クローン作成などの特定のデータベース操作は、引き続き影響を受けます.

3. 2026年9月17日 19:06 UTCmonitoring

   すべての影響を受ける環境に修正が展開されています。 問題を完全に解決するために、状況を監視します.

4. 2026年9月17日 19:55 UTCresolved

   修正をデプロイした後、影響を受けたインスタンス、運用メトリック、エラーを監視しました。 この事件が解決しました。 完了後すぐに投稿受付をいたします.

5. 2026年10月16日 16:23 UTCpostmortem

   # 何が起こったのか 2026年9月17日(木)13:52 UTCでは、並列操作間のデプロイタイムコンフリクトが、Auraのコアコンポーネントが使用したクレデンシャルで、Azure-hostedインフラストラクチャが削除されるようになりました。 既存の認証トークンが期限が切れるにつれて、コンポーネントはAzureでホストされているAuraインスタンスのエラーを返し、特定のデータベース操作に影響を与えました。 不足しているクレデンシャルにエラーを追跡し、新しいものを作成し、安全に保存し、影響を受けたコンポーネントのローリング展開を18:39 UTCで完了しました。 不足時に進行していたデータベース作成リクエストは、不完全な状態に残り、マニュアルの修正が必要でした。 19:48 UTCで完了し、19:55 UTCで事故が解決しました。 # サービスがどのように影響を受けたか AzureでホストされているAuraインスタンスに影響が制限されました。 他のクラウドプロバイダは影響を受けませんでした。 ***データベース操作:** ユーザーは、インシデントウィンドウ内の一部のAzureインスタンスで、作成、削除、クローンなどの特定のデータベース操作を実行できませんでした。 進行中の数が少なくなり、手動で回復しました。 ***管理の可視性:** Aura ConsoleでAzure-hostedインスタンスを一時的に表示または管理できませんでした。 ***メトリックのギャップ:** メトリックは、いくつかのAzureインスタンスが断続的なエラーを返し、影響を受ける期間のメトリックデータの短いギャップを残します。 このデータは返送されません。 既に稼働している Azure インスタンスが利用できず、作業負荷を正常に動作させ続ける。 # わたしたちが今何をしているか 再発を防止し、応答を改善するために、次の手順を実行しています。 *** イヤー検知・通信:** 監視やアラートを改善し、自動認証チェックの評価を行い、問題が検出され、顧客はすぐに通知されます。 ***不完全なデータベース作成からの回復:** インフラコールが途中で故障してしまったら、データベース作成が立ち往生できる不具合を修正しますので、システム自身で復旧します。 ***認証レビュー:** このコンポーネントがクラウドプロバイダーとどのように認証するかを見直し、失敗の1つのポイントを削除し、このタイプの競合再発のリスクを削減します.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月16日 8:50 UTCidentified

   サポートポータルのサービスプロバイダは、いくつかの停電を経験しています - https://status.salesforce.com/products/Salesforce Services を参照してください。 新規サポートケースを提出する問題が発生した場合は、[email protected]までメールでお問い合わせください

2. 2026年9月16日 9:16 UTCidentified

   当社のサポートポータルプロバイダは、問題の解決に取り組んでいます。 詳細はこちら https://status.salesforce.com/incidents/20004433

3. 2026年9月16日 10:11 UTCidentified

   当社のサポートポータルプロバイダは、引き続き問題の解決に取り組みます。 詳細はこちら https://status.salesforce.com/incidents/20004433

4. 2026年9月16日 11:30 UTCmonitoring

   修正はロールアウトされ、ポータルはエラーによって時間が経つにつれて影響が少なくなります。 詳細を見る https://status.salesforce.com/incidents/20004433

5. 2026年9月16日 12:29 UTCmonitoring

   当社のサポートポータルプロバイダは、修正をロールアウトし続けています.

6. 2026年9月16日 14:31 UTCresolved

   修正が展開され、すべての機能が回復されるようになりました.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月9日 12:31 UTCinvestigating

   現在、Aura Console.neo4j.ioとAPI api.neo4j.ioに影響を及ぼす問題について調査しています

2. 2026年9月9日 12:54 UTCidentified

   問題のソースを識別し、現在解決に取り組んでいます.

3. 2026年9月9日 13:10 UTCidentified

   今後も課題解決に向けて取り組んでまいります.

4. 2026年9月9日 13:26 UTCidentified

   私たちは、良好な進歩を遂げ、問題のあるコンポーネントを回復しています.

5. 2026年9月9日 13:36 UTCmonitoring

   修正を配備し、影響を受けたサービスが回復しています.

6. 2026年9月9日 13:39 UTCresolved

   すべての影響を受けたコンポーネントが完全に回復されます.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月3日 16:43 UTCinvestigating

   現在、この問題を調査中です.

2. 2026年9月4日 10:23 UTCidentified

   問題は特定され、インスタンスは利用可能なままであり、現在レビューされる影響を受けたインスタンスの解決の手順です.

3. 2026年9月4日 15:36 UTCresolved

   すべてのインスタンスが利用可能で、残りの少数のインスタンスをブロック解除する手動の手順は解決するために実行されました.

公式のインシデント更新を自動翻訳しています。

1. 2026年8月20日 15:49 UTCinvestigating

   当社のチームは、Auraインスタンスのメトリックを収集する問題を特定しました。 これは、メトリックの可視性と転送に影響を与えます。 現在、課題を調査中です.

2. 2026年8月20日 16:48 UTCinvestigating

   Aura のメトリックの問題を引き続き調査します.

3. 2026年8月20日 19:10 UTCresolved

   最終更新以来、調査が進んできました。 問題は特定され、劣化から回復したようにサービスを監視しました。 問題が解決しました.

4. 2026年9月17日 10:09 UTCpostmortem

   # 何が起こったのか 2026年8月20日(木)14:58:00 UTCでは、Googleマネージド・プロメテウス\(GMP\)にデータを送信する際に、当社のメトリック・インゲスメント・パイプラインは、高額な輸出失敗を経験し始めました。 根本的な原因は、「us-west1」地域でGoogle Cloud Platformサービスインシデントで、メトリクスの収集インフラで使用される輸出経路を破壊しました。 その結果、メトリクスエクスポートキューは、生産環境のサブセットで構築を開始しました。 メトリックデータをGMPに配信しようとすると、主にネットワークのタイムアウトとして明示された障害は、影響を受けたクラスターの通常の摂取を防ぎます。 当社のエンジニアリングチームは、影響を受けるシステムの地理的集中を特定しました。AWSの`us-west-2`、Google Cloud `us-west1`、およびAzure `westus2`を、Oregon領域のインフラを通るすべてのルートを特定しました。 GCP のローカルインシデントが Google によって緩和されたら、エラーのサブサイドとキューをエクスポートし、排水を開始しました。 # サービスがどのように影響を受けたか Aura環境のサブセットでは、**metrics可視性**に制限されました。 顧客環境が約45件、データベースからのデータがインシデントウィンドウの監視プラットフォームに取り込まれていないことを意味する。 最も影響を受けた領域は、AWS `us-west-2` で、Google Cloud `us-west1` および Azure `westus2` への追加の影響を受けました。 これらの地域のデータベースをお持ちのお客様は、そのメトリックダッシュボードのギャップを経験し、インシデントの持続期間のデータを監視することができます。 コアデータベースの操作 — 読み込み、書き込み、可用性を含む — の影響を受けていない**; パフォーマンスメトリックの収集と可視性のみが破壊されました。 Googleが根本的な地域問題を緩和すると、メトリックの摂取量が再開され、キューされたデータのバックログが処理されました。 # わたしたちが今何をしているか 私たちは、この事件を徹底的に見直し、当社のレジリエンスと対応能力を向上させるために次のステップを講じています。 * **改善された保守性ダッシュボード**: 私達は私達のメートルの輸出業者のダッシュボードにより明確、より速い可視性を列の健康に高め、誤差率を輸出し、同じような問題のより速い検出そして診断を可能にします。 ***アラート集計の改善**: 複数のクラスターに影響する地域事故が単一の相関イベントとして表面化され、適切な重症度と注意で処理されるため、自動アラートグループ化を実施しています。 * * * Ingestion の間違い率の積極的な警告:** 弊社では、GMP のインジェクション エラー レートを上昇させる専用のアラートを追加し、エクスポート キューが容量に達する前に、当社のチームが以前の信号を生成します。 これらの改善は、検出時間を短縮し、インシデント・トライエイジを簡素化し、将来のアップストリーム・プロバイダーの混乱に対するメトリック・パイプラインを強化するように設計されています.

公式のインシデント更新を自動翻訳しています。

1. 2026年8月5日 17:31 UTCinvestigating

   We have identified an issue currently that could result in unexpected query failures when using the trim() Cypher function. Investigations into the cause are in progress.

2. 2026年8月5日 19:27 UTCidentified

   We have found the issue and are working on a fix. A small percentatge of queries using trim may still err. VDC customers with databases set to highest are not impacted at all unless they pause and start their instances.

3. 2026年8月6日 0:58 UTCidentified

   We are testing the fix for the trim() Cypher function issue. We will update before we begin our deployment into the Aura environment.

4. 2026年8月6日 7:13 UTCidentified

   We are actively validating the fix for the trim() Cypher function. Further updates will be provided before we begin deploying to Aura instances

5. 2026年8月6日 11:17 UTCidentified

   We continue to validate the fix for the trim() Cypher function. Further updates will be provided before we begin deploying it to Aura instances.

6. 2026年8月6日 14:54 UTCidentified

   The fix for the trim() Cypher function is undergoing testing and validation before deployment. Further updates will be provided before we begin deploying it to Aura instances.

7. 2026年8月7日 1:15 UTCidentified

   Development has completed on the hot-fix for this issue, and we are finalizing the rollout plan for Aura.

8. 2026年8月7日 1:16 UTCidentified

   We are actively working on addressing the issue. The fix for the trim() Cypher function is undergoing testing and validation currently before deployment. Further updates will be provided before we begin deploying it to Aura instances.

9. 2026年8月7日 9:44 UTCidentified

   The fix to the trim() Cypher function has passed testing and validation and is now being deployed.

10. 2026年8月7日 13:49 UTCmonitoring

    The fix to resolve the issue has now completed deployment to the Aura service and we are monitoring the situation.

11. 2026年8月7日 15:34 UTCresolved

    We have monitored the fix and found the service to be stable. This incident is now considered resolved.

1. 2026年7月23日 10:52 UTCinvestigating

   現時点での課題を調査中です.

2. 2026年7月23日 11:08 UTCinvestigating

   エンジニアリングチームと連携し、現時点での調査を進めています.

3. 2026年7月23日 11:24 UTCinvestigating

   エンジニアリングチームと連携し、現時点での調査を進めています.

4. 2026年7月23日 11:38 UTCidentified

   現在の問題の原因を特定し、現在修正に積極的に取り組んでいます.

5. 2026年7月23日 11:53 UTCidentified

   修正の第1部を配備し、フルソリューションの展開に積極的に取り組んでいます。 今から1時間注文でETAを期待しています.

6. 2026年7月23日 12:11 UTCidentified

   私たちは、影響を受けたインスタンスのサブセットを識別し、この時点で修正をデプロイし続けます.

7. 2026年7月23日 12:32 UTCidentified

   設定の修正をデプロイし、影響を受けたインスタンスのサブセットを解決するようになりました.

8. 2026年7月23日 12:49 UTCidentified

   コンフィギュレーションの修正が展開されると、引き続きインスタンスのサブセットを解決します.

9. 2026年7月23日 14:07 UTCidentified

   引き続きインスタンスのサブセットを解決します.

10. 2026年7月23日 14:27 UTCidentified

    引き続き影響を受けるインスタンスのサブセットを解決します.

11. 2026年7月23日 14:44 UTCmonitoring

    引き続き影響を受けるインスタンスのサブセットを解決します.

12. 2026年7月23日 15:03 UTCmonitoring

    AuraDB 仮想専用クラウドと AuraDB ビジネスクリティカルは、すべて修正する必要があります。 AuraDB ProfessionalとFreeに依然として影響されるインスタンスのサブセットを解決し続けます.

13. 2026年7月23日 15:29 UTCmonitoring

    AuraDB ProfessionalとFreeに依然として影響されるインスタンスのサブセットを解決し続けます.

14. 2026年7月23日 15:57 UTCmonitoring

    AuraDB Professional および Free にはまだ影響されるインスタンスのサブセットを引き続き解決します.

15. 2026年7月23日 16:32 UTCmonitoring

    AuraDB Professional および Free にまだ影響されるインスタンスのサブセットを引き続き解決します

16. 2026年7月23日 17:01 UTCmonitoring

    AuraDB ProfessionalとFreeに依然として影響されるインスタンスのサブセットを修正し続けます

17. 2026年7月23日 17:31 UTCmonitoring

    AuraDB Professional と Free tiers の下ではまだ影響されているインスタンスの小さなサブセットを修正し続けます.

18. 2026年7月23日 18:07 UTCmonitoring

    AuraDB のプロフェッショナルなインスタンスで問題に対処しました。 Aura Freeは、まだ影響を受ける可能性があります。 引き続き、残りのデータベースを監視・修正します.

19. 2026年7月23日 19:39 UTCmonitoring

    引き続き、影響を受けるフリーインスタンスの小さなサブセットを修正します.

20. 2026年7月24日 6:00 UTCmonitoring

    今後も状況を監視し続けてまいります.

21. 2026年7月24日 8:30 UTCmonitoring

    今後の問題がないか引き続き監視しています。

22. 2026年7月24日 12:59 UTCmonitoring

    すべての識別されたインスタンスが修正され、監視し続けます。 さらなる問題に対するカスタマーサポートにお問い合わせください.

23. 2026年7月24日 15:56 UTCresolved

    すべての修正が展開され、問題が解決されるようになりました.

24. 2026年7月29日 21:58 UTCpostmortem

    ##**何が起こったのか 2026年7月23日(木)10:33 UTCは、データベースインスタンスのメモリ割り当てがどのように計算されたか意図せずに変更したAuraに構成変更がデプロイされました。 その結果、不十分なメモリを受け取ったインスタンスのサブセットが、データベースインスタンスが利用できなくなったり、更新を完了できなかったりします。 調整されたメモリ割り当ては、不足しているメモリリソースのためにデータベースインスタンスを繰り返し再起動したり、更新をスタックしたりすることを引き起こし、メモリ外の状態につながりました。 この問題は、複数のクラウドプロバイダーと複数の製品層に影響するインスタンスです。 問題が特定されたら、設定変更を即座に再変換し、不正確な設定を受信する追加のインスタンスを防止します。 2026年7月23日(木)11時56分UTCの制作に修正された構成が導入されました。 しかし、既に誤った構成を受け取ったデータベースインスタンスは、通常の操作に戻ることができる前に、個々の回復アクションが必要でした。 2026年7月23日(木)17:59 UTCにより、既知の顧客影響データベースインスタンスが回復しました。 2026年7月24日(金)16:30 UTCにて、下記の日に引き続きモニタリングを実施。 ##**サービスが影響を受ける方法** 第一次顧客の影響は、AuraDB データベースのインスタンスが利用できなくなったり、劣化した状態に入ったりすることだった。 感染したインスタンスは、ルーチンソフトウェアの更新を完了できませんでした。また、不十分なメモリが割り当てられたため、いくつかのケースでは繰り返し再起動しました。 ***サービスの利用可能性:** サービスの階層によって変化する顧客の影響。 AuraDB Professionalインスタンスは、高可用性を提供しないため、サービス中断の最大のレベルを経験し、サブセットが利用できなくなり、読み取りや書き込みを処理することができません。 影響を受けたAuraDBビジネスクリティカルおよび仮想専用クラウド\(VDC\)インスタンスの場合、サービス可用性が維持された間、一般的に故障公差の一時的な損失に限定されていました。 ケース数が少ない場合、ビジネスクリティカルおよびVDCインスタンスも利用できなくなった。 * ** スタッフの更新**: 追加インスタンスは利用できませんが、変更や設定変更などの顧客開始操作をブロックした「Updating」状態に固執していました。 * **十字プラットホームの規模**: 3つのサポートされているクラウドプロバイダーと複数の地域に及ぶ影響は、世界中の顧客に影響を及ぼします。 顧客サポートのケースが上げられ、当社のチームは、影響を受けたインスタンスを優先的に回復しました。 AuraDBインスタンスの大半は正常に動作し続けています。 顧客の影響は、各影響を受けたインスタンスの構成の逆転および標的された手動回復によって十分に軽減されました。 ##**今何をやっているか** この事件を徹底的に分析し、次の行動を識別しました。 *** 予防措置** * **導入検証の改善:** リリースの検証プロセスを強化し、構成変更をよりよく特定します。 ***コンポーネントデカップリング**: コンポーネントのデプロイメントのシーケンシングに関する改善を評価し、リリースに含まれていない変更のリスクを削減します。 * **積極的なロールアウト戦略**: 影響を受けたコンポーネントのロールアウトプロセスを見直し、他の重要なコンポーネントに使用されるロールアウト制御と並行してそれらをもたらす。 *** 検出** * **注意点**: 故障率の異常増加を検知するために、モニタリングを強化しています\(障害耐性や可用性の損失など)より迅速かつ確実に。 ***マイティグレーション** * **より安全な構成の配置:** 生産構成の変更がどのように展開されるかを改善し、広範なソフトウェアリリースを必要としずに、無効化またはロールバックすることができます。 ***Faster手動回復ツール**: 私たちは、影響を受けたインスタンスを識別し、手動で回復するために必要な時間を減らすために、私たちの回復ツーリングを改善しています。 被害を受けたお客さまに影響を及ぼすと、この事故が起こってお詫び申し上げます。 直近の是正措置をクリアし、上記の長期的改善は、将来同様の事件の可能性と影響を削減するために既に進行中です.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月10日 17:18 UTCinvestigating

   現在、Aura Consoleに影響する問題について調査中です。その場合、一部の顧客はそのインスタンスが表示されない場合があります。 この問題は、オーラが依存する第三者サービスの故障によるものです。 Affected インスタンスは正常に動作し、データベース接続は影響しません。 私たちのチームは積極的に問題を調査しています.

2. 2026年7月10日 17:23 UTCinvestigating

   今後もこの問題について調査を続けてまいります.

3. 2026年7月10日 17:51 UTCmonitoring

   Auraが依存するサードパーティサービスは、通常の操作を復元し、Neo4j Auraシステムが回復しました。 Aura Consoleが期待どおりに実行されていることを確認するために、当社のチームが積極的に問題を監視しています.

4. 2026年7月10日 19:23 UTCresolved

   業務を遂行し、さらなる中断が予想されることはありません.

5. 2026年7月27日 4:28 UTCpostmortem

   ## 何が起こったのか Aura Console と Aura コンポーネントは、16:14 UTC で 2026-07-10 で破壊を経験し、故障やクラッシュループが発生しました。 その結果、顧客のセグメントは、インスタンスに関する可視性の問題に直面しています。 アウラと統合した外部の第三者サービスの停電によって引き起こされました。 直面的に、データベース接続は妥協せず、影響を受けたインスタンスは通常の操作を続けた。 LaunchDarklyサービスは問題を解決するために復元されました ## サービスがどのように影響を受けたか Aura Console、経験豊富な中断を含む複数のAuraコンポーネント。 データベース関連のページや操作に関する HTTP 500 エラーが発生しましたが、組織やプロジェクトはまだアクセスできませんでした。 特定のデータベースインスタンスへの直接接続が完全に影響されない 制御平面は利用できませんでした。これにより、ユーザーはAPIまたはAuraコンソールを介してインスタンスの設定を作成、削除、サイズ変更、または調整することはできません。 既存のインスタンスは、しかし、運用を続けた。 問題は LaunchDarkly の停電によって引き起こされ、当社のサービスは起動時にその依存性障害を順調に処理しませんでした。 2026-07-10 17:07 UTCで通常の動作に戻ったすべての影響を受けたシステム ## 私たちが今何をしているか Neo4j エンジニアリングチームは、根本原因と復元されたサービスを迅速に診断しました。 このインシデントの評価では、将来の解像度を加速し、再発リスクを軽減するための重要な領域を特定しました。 * 応答効率を加速するための機会を識別するために、アラート対応答時間に焦点を当てた重要なインシデントメトリックを分析 * 透明なロギング、インシデント管理ツールによるシームレスなアライメント、データ平面接続の不当性を維持した複数のコンポーネントの弾力性、豊かで豊かな劣化による迅速なroot-cause分析を含む、包括的なレトロスペクティブハイライトを実施 * ベンダーのダウンタイム中にコア操作を保護するために機能フラグのためのより優雅なフォールバックのデフォルトを積極的に開発 *高度の計画、Chaosの工学練習および生産レベルの欠陥の注入のテストを統合することによって建築弾性を強化し、潜在的障害経路を明らかにし、軽減します * オペレータ機能のフラグキャッシュでアドレスされたロジック制限, オペレータが評価されたフラグをローカルに保存する必要性を強調し、外部の依存関係が失敗した場合、運用継続を維持します.

公式のインシデント更新を自動翻訳しています。

1. 2026年6月30日 14:45 UTCidentified

   CREATE VECTOR INDEXの実行はエラー51N31で失敗します error: システム構成または動作例外 - 未サポート V2026 02 では、提供された設定でベクトルインデックスを作成することはサポートされていません。 動作に必要なバージョンはV2026 06です。 DBMSをアップグレードしてください。 これは新しいインデックスにのみ影響します。, 既存のベクトルインデックスは影響しません。. 2026-06-30 時 09:00 までに作成されるベクターインデックスは正常に動作し続けます.

2. 2026年6月30日 15:41 UTCidentified

   この問題に対処するために修正をデプロイし、進捗をすぐに更新します.

3. 2026年6月30日 16:05 UTCmonitoring

   固定は転がり、うまく進行します。 進捗状況の更新を行います.

4. 2026年6月30日 17:45 UTCresolved

   Fixは、すべての影響を受けたインスタンスに完全にデプロイされています。 この事件が解決しました.

5. 2026年7月20日 8:40 UTCpostmortem

   ## 何が起こったのか アップグレードされたAuraインスタンスで`CREATE VECTOR INDEX`を実行して、08:00 UTCで2026-06-30のバージョン2026.06の展開に従って、問題が特定されました。 アンダーリーティングストアとカーネルが動作をサポートするための追加アップデートが必要なため、インデックス生成の失敗が発生しました この問題は、新しいインデックスの作成に影響を与えただけです。既存のベクトルインデックスは影響を受けません。 2026-06-30 で 09:00 前に作成された任意のベクトルインデックスは、正常に動作し続け. ## サービスがどのように影響を受けたか バージョン2026.06のロールアウト後、CREATE VECTOR INDEXステートメントの実行が失敗し、新しいベクターインデックスを追加することに依存したアプリケーションに影響を与える。 欠陥のあるクライアントがエラーを受け取った: V2026\ 02 で提供設定したベクトルインデックスの作成はサポートされていません。 動作に必要なバージョンはV2026\ 06です。 DBMS をアップグレードしてください。 既存のインデックス \(このインシデント\の前に作成) および他のクエリは、完全に影響力のない、完全に機能的です。 ## 私たちが今何をしているか Neo4j チームは、Cypher プランナーのバグとして根本的な原因を特定し、コード修正で問題を解決しました。 この修正は、すべての影響を受ける Aura インスタンスに展開され、エラーを完全に解決します。 将来の発生を防止するため、特にロールアウト前のステージング環境では、モニタリングとアラートシステムを強化しています。 同時に、顧客の衝撃および回復時間を最小にするために私達の配置プロセスを精製します また、ベクターインデックス作成などの重要な操作に特に自動化されたポストアップグレード検証テストを実施するオプションを調査しています

公式のインシデント更新を自動翻訳しています。

1. 2026年6月23日 11:25 UTCidentified

   Aura コンソールは、いくつかの断続的なエラーが発生しています。: 「私たちのシステムは今問題を経験しています。 問題が解決しない場合は、もう一度お試しください。 これは、コンソールでナビゲートするためのリロードまたは待機時間を要求することができます 操作と Aura API は影響を受けないまま 修正に積極的に取り組んでいます

2. 2026年6月23日 13:03 UTCidentified

   私たちは、問題の修正を継続的に調査しています

3. 2026年6月23日 13:39 UTCidentified

   この問題の修正には引き続き取り組んでいます。

4. 2026年6月23日 15:43 UTCmonitoring

   変更をデプロイします。 監視・更新を行います.

5. 2026年6月23日 19:27 UTCmonitoring

   展開された変更を監視し続けます。 次回更新予定 6/24/2026 10am UTC.

6. 2026年6月24日 9:14 UTCmonitoring

   問題が完全に対処されていることを確認し、確認しました.

7. 2026年6月24日 9:14 UTCresolved

   この事件は解決しました.

8. 2026年7月10日 14:50 UTCpostmortem

   ## 何が起こったのか 2026年1月22日には、Auraコンソール表示中の断続的なエラーバナーに遭遇したユーザーは、「問題がある」と表示されます。 コンソール API エンドポイントから 500 個のエラーで発生した、もう一度お試しください。 これらの混乱は、通常約10秒以内に解決するか、ページがリフレッシュした後、TLSハンドシェイクプロセス中に内部APIのタイミングで過渡され、引き起こされました ## サービスがどのように影響を受けたか Aura Console と Aura API は、Aura コンソール UI 内の断続的なエラーバナーとして宣言された、劣化したパフォーマンスを経験しました。 調査は、コンソール API 内で高い CPU の使用法および回転として根本原因を識別しました。 この問題は、主に、大規模なエンティティティリストと高価な調整要求によって駆動されました 問題に対処するため、対象となる修正は、AuraコンソールとAura APIの両方に正常にデプロイされました。 続いて、運用ヘッドルームを増加させ、安定性を確保するリソース構成の調整 ## 私たちが今何をしているか 同様の事件の可能性を減らすために、以下の反応および積極的な対策を実施しました。 * モニタリングダッシュボードを開発し、内部のAPIログデータに基づいてドロップを要求し、自動監視を実施し、問題が発生する前に問題をキャッチするアラートを警告します。 * 高資源消費量を緩和し、APIの安定性を向上させるために、paginated reconciler 要求間の厳しい遅延を実施 * インフラを強化し、リソースの計算を意識してパフォーマンスを改善 * サービスティアに基づいて、再コンシラーが実行する各呼び出しのCPUオーバーヘッドを最適化するための新しいフィルタを導入 * API 呼び出しを最適化するための冗長リクエストミドルウェア処理を無効に

公式のインシデント更新を自動翻訳しています。

1. 2026年5月26日 18:23 UTCinvestigating

   Aura Console is currently not accessible. Our team is investigating the issue. Aura instances are running normally and are not impacted. They remain accessible via https://browser.neo4j.io/ and https://bloom.neo4j.io/ Console-related administration and configuration procedures may be unavailable. We will provide updates as soon as more information is available.

2. 2026年5月26日 19:19 UTCmonitoring

   The Aura Console issue has now been resolved. The root cause was a failure while fetching public certificates from Auth0. We are reaching out to the Auth0 team to gather more detailed information about the incident.

3. 2026年5月26日 23:06 UTCresolved

   This incident has been resolved.

4. 2026年6月9日 16:50 UTCpostmortem

   **What Happened** During the incident window, users attempting to log in to the Aura Console were unable to do so. Auth0, the authentication provider for Aura Console, experienced an issue that prevented new authentication requests from completing. Existing sessions with valid cached tokens were largely unaffected. Aura database instances were running normally throughout and were not impacted, and access via the Aura API to database instances was also unaffected. **How the service was affected** Authentication requests from the Aura Console to Auth0 began failing, preventing new logins and session refreshes. Affected users received 503 errors when accessing the Aura Console. Once Auth0 recovered, access was restored. **What are we doing now** We've made two changes as a result of this incident: * Client identification: Authentication requests now include a clearer client identifier, reducing the chance of requests being incorrectly blocked in the future. * Observability: We've improved logging and alerting for authentication failures, including better visibility into errors from external services,so we can detect and escalate issues like this faster.

1. 2026年3月6日 10:18 UTCidentified

   We identified an issue with the availability of console.neo4j.io - we are investigating

2. 2026年3月6日 10:24 UTCmonitoring

   We have made a code change and we believe the console is available again.

3. 2026年3月6日 10:25 UTCresolved

   We have checked and confirm that the issue is now fully addressed.

4. 2026年3月30日 7:25 UTCpostmortem

   ## What Happened On March 6, at 10:04 AM UTC,  the Aura Console became inaccessible following a recent deployment. The deployment included changes related to user organizations and switching to an org memberships entity. This change caused the console to become inaccessible for a short period. ## How the service was affected A deployment to the Aura Console introduced an issue that caused an unexpected increase in backend requests related to access validation. This led to elevated CPU usage, which impacted the availability of the console and dependent services. We rolled back to a previous version to restore access. The rollback ensured the full restoration of access to the Aura Console, resolving the core issue within the incident window ## What are we doing now We are currently implementing a comprehensive strategy to bolster system resilience and prevent future recurrence. Our immediate actions include integrating stricter and more robust safeguards into the deployment pipeline. Crucially, we are significantly enhancing our validation processes to proactively detect and flag any potential performance impacts _before_ code is promoted to the production environment

1. 2026年3月3日 21:35 UTCidentified

   A recent update resulted in MERGE queries which referenced the same merged property on both the left and right hand side of an ON MATCH SET or ON CREATE SET clause deleting that property from the node, or setting it to an invalid value during query runtime. The node being matched against must have had at least one property uniqueness constraint present. A fix has been identified and will be applied as soon as possible. Instances marked as "Production" are not impacted.

2. 2026年3月4日 1:39 UTCidentified

   The fix is being deployed and the status page will be updated upon completion of the full deployment of the fix.

3. 2026年3月4日 4:52 UTCidentified

   The fix is being deployed and the status page will be updated upon completion of the full deployment

4. 2026年3月4日 14:07 UTCmonitoring

   The fix has now been deployed to those instances impacted and we are monitoring the situation.

5. 2026年3月4日 15:19 UTCresolved

   The fix has been fully deployed to all impacted instances. This incident is now resolved.

6. 2026年4月8日 6:39 UTCpostmortem

   ## What Happened An issue was introduced in the Neo4j 2026.02 release where MERGE queries that referenced the same property on both the left and right sides of an `ON MATCH SET` or `ON CREATE SET` clause could potentially delete that property from the node or set it to an invalid value during query execution. This behaviour was observed specifically when the node being matched had at least one property uniqueness constraint. ## How the service was affected A change in the Neo4j 2026.02 release introduced a potential risk of writes failing or invalid data being returned for queries using MERGE together with `ON MATCH`. This issue affected instances across Aura tiers and required immediate investigation by Neo4j Engineering. The team identified the root cause and deployed a fix in version 2026.02.1. ## What are we doing now The following proactive measures have been implemented to reduce the likelihood of similar incidents: * We have strengthened test coverage for `ON CREATE` and `ON MATCH` clauses, particularly those involving more complex expressions. * We are investigating additional safeguards to improve our ability to control MergeInto/MergeUnique behaviour more flexibly, as well as potential rollback capabilities to support recovery in future incidents

1. 2026年3月2日 19:55 UTCidentified

   We are aware of issues in the Middle East regions via our cloud partner AWS, affecting AWS me-central-1 (United Arab Emirates) and AWS me-south-1 (Bahrain). The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We are actively working to limit the impact on the Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels. Our team is available to advise and assist as needed.

2. 2026年3月3日 15:26 UTCidentified

   We continue to monitor the situation in the affected AWS Middle East regions. The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as soon as more information becomes available.

3. 2026年3月6日 14:29 UTCidentified

   We continue to monitor the situation in the affected AWS Middle East regions. The latest information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as more information becomes available. Please review the AWS recommendation on the website above.

4. 2026年3月6日 16:06 UTCresolved

   While AWS continues working on this situation, we are closing this incident and invite our customers to monitor the AWS Status on our main Neo4j Status Page under AWS (Amazon Web Services). The latest information from AWS can be found at: https://health.aws.amazon.com/health/status

5. 2026年3月29日 15:16 UTCpostmortem

   ## What Happened On March 1, at 12:51 PM UTC, AWS services in the ME-CENTRAL-1 & ME-SOUTH-1 Region were impacted. Connectivity and power issues affected APIs and AWS core services essential to run Neo4j Aura prompting AWS to initiate an investigation ## How the service was affected Operations \(clone, backup, resuming/pausing, resizing\) that require additional resources like EC2 Instances, EBS Volumes, and other resources were impaired in the ME-CENTRAL-1 and ME-SOUTH-1 Region. Other AWS Services also experienced error rates and latencies for some workflows. Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure. A detailed summary of the AWS regional incident can be found here:[ https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status) ## What are we doing now We are actively working to limit the impact on the Neo4j Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels Please visit AWS Status page for more info:[https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status)