57 Neo4j Aura incidents · 2023年12月 — official updates, affected components, duration and resolution details.
現在、この問題を調査中です.
問題は特定され、インスタンスは利用可能なままであり、現在レビューされる影響を受けたインスタンスの解決の手順です.
すべてのインスタンスが利用可能で、残りの少数のインスタンスをブロック解除する手動の手順は解決するために実行されました.
公式のインシデント更新を自動翻訳しています。
当社のチームは、Auraインスタンスのメトリックを収集する問題を特定しました。 これは、メトリックの可視性と転送に影響を与えます。 現在、課題を調査中です.
Aura のメトリックの問題を引き続き調査します.
最終更新以来、調査が進んできました。 問題は特定され、劣化から回復したようにサービスを監視しました。 問題が解決しました.
公式のインシデント更新を自動翻訳しています。
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.
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.
We are testing the fix for the trim() Cypher function issue. We will update before we begin our deployment into the Aura environment.
We are actively validating the fix for the trim() Cypher function. Further updates will be provided before we begin deploying to Aura instances
We continue to validate the fix for the trim() Cypher function. Further updates will be provided before we begin deploying it to Aura instances.
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.
Development has completed on the hot-fix for this issue, and we are finalizing the rollout plan for Aura.
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.
The fix to the trim() Cypher function has passed testing and validation and is now being deployed.
The fix to resolve the issue has now completed deployment to the Aura service and we are monitoring the situation.
We have monitored the fix and found the service to be stable. This incident is now considered resolved.
現時点での課題を調査中です.
エンジニアリングチームと連携し、現時点での調査を進めています.
エンジニアリングチームと連携し、現時点での調査を進めています.
現在の問題の原因を特定し、現在修正に積極的に取り組んでいます.
修正の第1部を配備し、フルソリューションの展開に積極的に取り組んでいます。 今から1時間注文でETAを期待しています.
私たちは、影響を受けたインスタンスのサブセットを識別し、この時点で修正をデプロイし続けます.
設定の修正をデプロイし、影響を受けたインスタンスのサブセットを解決するようになりました.
コンフィギュレーションの修正が展開されると、引き続きインスタンスのサブセットを解決します.
引き続きインスタンスのサブセットを解決します.
引き続き影響を受けるインスタンスのサブセットを解決します.
引き続き影響を受けるインスタンスのサブセットを解決します.
AuraDB 仮想専用クラウドと AuraDB ビジネスクリティカルは、すべて修正する必要があります。 AuraDB ProfessionalとFreeに依然として影響されるインスタンスのサブセットを解決し続けます.
AuraDB ProfessionalとFreeに依然として影響されるインスタンスのサブセットを解決し続けます.
AuraDB Professional および Free にはまだ影響されるインスタンスのサブセットを引き続き解決します.
AuraDB Professional および Free にまだ影響されるインスタンスのサブセットを引き続き解決します
AuraDB ProfessionalとFreeに依然として影響されるインスタンスのサブセットを修正し続けます
AuraDB Professional と Free tiers の下ではまだ影響されているインスタンスの小さなサブセットを修正し続けます.
AuraDB のプロフェッショナルなインスタンスで問題に対処しました。 Aura Freeは、まだ影響を受ける可能性があります。 引き続き、残りのデータベースを監視・修正します.
引き続き、影響を受けるフリーインスタンスの小さなサブセットを修正します.
今後も状況を監視し続けてまいります.
今後の問題がないか引き続き監視しています。
すべての識別されたインスタンスが修正され、監視し続けます。 さらなる問題に対するカスタマーサポートにお問い合わせください.
すべての修正が展開され、問題が解決されるようになりました.
##**何が起こったのか 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手動回復ツール**: 私たちは、影響を受けたインスタンスを識別し、手動で回復するために必要な時間を減らすために、私たちの回復ツーリングを改善しています。 被害を受けたお客さまに影響を及ぼすと、この事故が起こってお詫び申し上げます。 直近の是正措置をクリアし、上記の長期的改善は、将来同様の事件の可能性と影響を削減するために既に進行中です.
公式のインシデント更新を自動翻訳しています。
現在、Aura Consoleに影響する問題について調査中です。その場合、一部の顧客はそのインスタンスが表示されない場合があります。 この問題は、オーラが依存する第三者サービスの故障によるものです。 Affected インスタンスは正常に動作し、データベース接続は影響しません。 私たちのチームは積極的に問題を調査しています.
今後もこの問題について調査を続けてまいります.
Auraが依存するサードパーティサービスは、通常の操作を復元し、Neo4j Auraシステムが回復しました。 Aura Consoleが期待どおりに実行されていることを確認するために、当社のチームが積極的に問題を監視しています.
業務を遂行し、さらなる中断が予想されることはありません.
## 何が起こったのか 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の工学練習および生産レベルの欠陥の注入のテストを統合することによって建築弾性を強化し、潜在的障害経路を明らかにし、軽減します * オペレータ機能のフラグキャッシュでアドレスされたロジック制限, オペレータが評価されたフラグをローカルに保存する必要性を強調し、外部の依存関係が失敗した場合、運用継続を維持します.
公式のインシデント更新を自動翻訳しています。
CREATE VECTOR INDEXの実行はエラー51N31で失敗します error: システム構成または動作例外 - 未サポート V2026 02 では、提供された設定でベクトルインデックスを作成することはサポートされていません。 動作に必要なバージョンはV2026 06です。 DBMSをアップグレードしてください。 これは新しいインデックスにのみ影響します。, 既存のベクトルインデックスは影響しません。. 2026-06-30 時 09:00 までに作成されるベクターインデックスは正常に動作し続けます.
この問題に対処するために修正をデプロイし、進捗をすぐに更新します.
固定は転がり、うまく進行します。 進捗状況の更新を行います.
Fixは、すべての影響を受けたインスタンスに完全にデプロイされています。 この事件が解決しました.
## 何が起こったのか アップグレードされた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 インスタンスに展開され、エラーを完全に解決します。 将来の発生を防止するため、特にロールアウト前のステージング環境では、モニタリングとアラートシステムを強化しています。 同時に、顧客の衝撃および回復時間を最小にするために私達の配置プロセスを精製します また、ベクターインデックス作成などの重要な操作に特に自動化されたポストアップグレード検証テストを実施するオプションを調査しています
公式のインシデント更新を自動翻訳しています。
Aura コンソールは、いくつかの断続的なエラーが発生しています。: 「私たちのシステムは今問題を経験しています。 問題が解決しない場合は、もう一度お試しください。 これは、コンソールでナビゲートするためのリロードまたは待機時間を要求することができます 操作と Aura API は影響を受けないまま 修正に積極的に取り組んでいます
私たちは、問題の修正を継続的に調査しています
この問題の修正には引き続き取り組んでいます。
変更をデプロイします。 監視・更新を行います.
展開された変更を監視し続けます。 次回更新予定 6/24/2026 10am UTC.
問題が完全に対処されていることを確認し、確認しました.
この事件は解決しました.
## 何が起こったのか 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 呼び出しを最適化するための冗長リクエストミドルウェア処理を無効に
公式のインシデント更新を自動翻訳しています。
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.
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.
This incident has been resolved.
**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.
We identified an issue with the availability of console.neo4j.io - we are investigating
We have made a code change and we believe the console is available again.
We have checked and confirm that the issue is now fully addressed.
## 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
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.
The fix is being deployed and the status page will be updated upon completion of the full deployment of the fix.
The fix is being deployed and the status page will be updated upon completion of the full deployment
The fix has now been deployed to those instances impacted and we are monitoring the situation.
The fix has been fully deployed to all impacted instances. This incident is now resolved.
## 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
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.
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.
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.
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
## 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)
AuraDB Free、Professional、AuraDSのCypher 25のクエリの限られたセットに影響を与える可能性がある問題を特定しました。 これは影響します: - 条件クエリWHENを使用して、null値上の非グループ化集計と組み合わせてクエリWHENを使用してクエリは、返された行の誤った数になります。 - NEXT を使用した Queries は、いくつかのインスタンスで予期しない変数を定義しないエラーを生成することができます。 修正に積極的に取り組んでおり、より多くの情報が利用できるようにこのページを更新します.
私たちは、この問題の解決を識別し、オーラで転がります。 更新がデプロイされたら、このtatusページを更新します.
修正を施し、完了したら更新します.
修正は影響を受けたコンポーネントにロールアウトし、今回は状況を監視しています.
今後も状況を監視し続けています.
Fixは、すべての影響を受けたインスタンスに完全にデプロイされています。 この事件が解決しました.
## **何が起こっているか** Neo4j は、バージョン 2026.01.1 を Aura の無料インスタンスに 2026 年 1 月 26 日に UTC にデプロイしました。 内部テスト中にクエリの失敗の検出に続いて、オーラより高い層に達した前にロールアウトが停止されました。 プランナーフェーズの後に、条件付きクエリ\(例:WHEN ...THEN ...\)で発生した障害は、null値上の集計の場合には異なる動作をします。 根本原因を特定し、バージョン2026.01.2に統合された解像度を開発しました。 2026年1月27日、Auraインスタンス全体で2026.01.2を展開し、影響を受けたすべての環境を正しくバージョンアップしました。 ## サービスがどのように影響を受けたか ニュル値上の集計と組み合わせて2026.01.1でWHENを使用してクエリは、返された行の誤った数を取得します。 NEXT を使用した Queries は、一部のインスタンスでは、予期しない変数を定義しないエラーが発生します。 これは、null値に対する集計の場合には、書き換えクエリが異なる動作を引き起こしました。 条件クエリは、null値を含む受信行を受信し、グループ化なしで値を集計する必要があります。 お客様が、Cypher 25 で条件付きクエリーコンスを使用していた場合は、誤った結果が出ました。([https://neo4j.com/docs/aura/managing-instances/cypher-version/](https://neo4j.com/docs/aura/managing-instances/cypher-version/\))、Aura インスタンスの限られた数に制限されたインパクト。 ## 私たちが今何をしているか あらゆる製品分野における包括的なカバレッジを確保するため、テスト手順を強化しました。 これは、識別された問題と潜在的な将来のシナリオに対処するために設計された新しいテストケースの開発を含みます。 さらに、Aura内のCypherクエリテストを、回帰テストスイートの標準的なコンポーネントとして統合しました。 これらのチェックは、生産ロールアウト前の継続的な統合パイプラインおよびステージング環境内で必須です.
公式のインシデント更新を自動翻訳しています。
Impact is that currently it is not possible to load data into GDS via native projection. Customers using Aura Graph Analytics are not impacted. We have identified a packaging issue with the latest release of Aura. Our engineering team is working on a fix.
Our teams have a fix and initiated the work to get it ready to roll-out. No current ETA available. We will keep you updated soon.
The fix is currently rolling out to production. We will update you upon completion
All instances should have the fix applied and if not it should be in the next 60 minutes
### **What happened** On January 15, 2026 at 22:12 UTC we began rolling out an update that included an incompatible version of a key component, affecting customers using the GDS plugin. This issue was reported on January 16 at 12:59 UTC, and a fix was deployed within hours, restoring functionality for the majority of affected users by 20:03 UTC. The issue occurred because Neo4’s packaging automation process selected the wrong version of the GDS component. GDS 2.25 should have been selected but instead GDS 2.24 was included in the bundle, which caused a compatibility issue. Although a corrected package was created and labeled separately, the release pipeline selected the incorrect package for deployment. This issue highlighted a gap in the release validation process, where incompatible component versions were not detected before rollout. ### **How customers were affected** Customers using the GDS plugin were unable to use any of the functionality the plugin provides during the incident window. The system configuration has been updated to ensure compatibility with the intended component versions, restoring full functionality. ### **What we are doing now** The following mitigations have been implemented: * Enhanced testing procedures to automatically verify compatibility between Neo4j and all bundled components before release. * Improved release processes to ensure that only explicitly validated and correctly labeled packages can be selected for deployment.
Neo4j opened a ticket with Azure and is awaiting updates on their resolution of the Azure Infrastructure issues. Impact on Neo4j Aura Services: Create, Resize (CPU and Storage), Pause, Resume.
Neo4j continues working with Microsoft via an Azure cloud ticket and is awaiting updates on their resolution of the Azure Infrastructure issues. Some resources have been made available, and impacted Neo4j Services have resumed operation. Customers have been notified. The Neo4j Aura Service is impacted when performing the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j operations, the operation will fail, and the Neo4j instance will become unavailable until Azure is able to provision additional resources.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance will become unavailable until Azure is able to provision additional resources.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Clone, Resume. As Azure resources become available when performing some Aura operations, the impacted instances may progressively recover and operations successfully complete. We continue to monitor progress, work with Microsoft Azure Infrastructure issues and will update.
We continue to work with our cloud infrastructure provider . Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.
We continue to work with our cloud infrastructure provider. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.
We continue to work with Microsoft Azure. No expected improvements in addressing the issues around cloud resources in the affected regions before next week. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume. We will resume updates after this weekend or earlier if we have more information.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance may become unavailable or degraded until Azure is able to provision additional resources.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, affecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance may become unavailable or degraded until Azure is able to provision additional resources.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region. We are working with our cloud partner and will resume updates once we have an ETA to share.
Cloud resources have become available in USEAST2 and we will monitor for a few hours to ensure there is no further customer impact.
Cloud resources have become available in USEAST2 and no further customer impact has been detected. This incident is resolved.
### **What Happened** Starting at 13:26 UTC on November 24th Microsoft Azure region eastus experienced a stock out situation, which impacted operations for all tiers of Neo4j Aura in that specific region. Additional capacity was requested straight away, but not until 17:06 UTC on December 10th did enough additional resources become available to resume all normal operations. **How the service was affected** All tiers within the Neo4j Aura Service were impacted when performing the following operations during this incident: Create, Resize \(CPU and Storage\), Clone, Pause and Resume. If Microsoft Azure resources were unavailable when requesting these types of Neo4j operations, the operation would fail, and the Neo4j instance would become unavailable until Azure was able to provision additional resources. ### **What are we doing now** To mitigate the scope of impact of future regional stock out issues, Neo4j is implementing the following measures: * Closely monitoring resource capacity to improve stockout predictions. * Regular calls with with our Cloud Service Provider to: * Learn about where regional resource capacity restrictions are forecast. * Plan for more resources in restricted regions. * Investigating other deployment models to allow us to keep Aura running in situations where 3 Availability Zones are not available.
We have identified an issue resulting in Pause, Resume and Delete operations to fail in both Console and Aura API across all tiers of Aura. We are actively working to resolve the issue and will report progress.
We have released a fix to this issue and are monitoring to ensure all operations are back to normal.
After monitoring the fix for some time, we can confirm that the issue is resolved and normal operations have resumed.
### What happened On November 18, 2025, some customers experienced issues with the delete, pause, and resume operations in the Console. These actions failed due to a temporary system issue introduced during a sequence of updates. While the updates were intended to improve functionality, they unintentionally reintroduced a previously resolved defect. The issue was identified quickly, and our teams acted immediately to restore normal operation. The root cause was a misconfiguration in the data processing module. An outdated schema caused the data parsing logic to misinterpret certain input parameters, leading to incorrect behavior and data display within the Console. We have since corrected the schema and added stricter validation to ensure compatibility moving forward. ### How customers were affected During the incident, some users experienced service disruptions when accessing the Console. Impacts included: * Intermittent connectivity issues * Inability to log in * Temporary unavailability of specific Console features No customer data was lost. To prevent a recurrence, we have improved our release process to ensure updates are deployed in the correct order, eliminating overlapping or out-of-sequence changes. ### What we are doing now Neo4j takes service reliability seriously and is strengthening safeguards to prevent similar incidents. New mitigations being deployed include: * Enhanced monitoring to detect related issues earlier * Additional automated checks to block faulty configurations before deployment * Improvements to overall service resilience to better tolerate similar failures We apologize for the disruption and appreciate our customers’ patience as we continue to harden our systems.
Many core operations for instances in AWS region us-east-1 are degraded as a result of AWS incident in that region: https://health.aws.amazon.com/health/status Core operations include create, pause, resume, clone, backup, among others. We continue to monitor the AWS incident and will provide updates accordingly.
We are continuing to monitor the AWS incident, and can report some slow improvement of impacted Aura instances in the AWS us-east1 region, though the service remains degraded in this region at this time. We are continuing to monitor progress in the AWS incident: https://health.aws.amazon.com/health/status
Instance operations in AWS us-east-1 region are back to normal following the resolution of the AWS incident. We will continue to monitor but all data indicates that the issue is fully resolved at this time.
### **What Happened** Between 08:41 UTC on October 20th and 09:00 UTC on October 21st, Neo4j Aura experienced service disruptions affecting the us-east-1 \(N. Virginia\) region in AWS. The incident was triggered by a broad AWS regional outage impacting Identity and Access Management \(IAM\) and the EC2 control plane. This resulted in delayed backups, temporary loss of database fault tolerance for a subset of users, and internal delays in administrative actions due to toolchain failures. A detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/) ### **How the service was affected** The primary cause was several AWS regional service disruptions in us-east-1. We will cover how each of these affected Neo4j Aura and its users. Neo4j Aura is designed to isolate regional failures. This is achieved through deploying customer instances in Orchestras that have instances in three availability zones and no cross region dependencies. AWS IAM and Identity Center became unresponsive, preventing Neo4j Aura’s automated systems from authenticating with AWS resources in us-east-1. This affected Neo4j Aura backups to be written to AWS S3 buckets. Customers were also not able to resume paused instances during this period as the resume process was not able to authenticate with AWS S3 buckets to retrieve the paused data set. Neo4j Aura’s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. AWS Network Load Balancer health check system failures and AWS EC2 “request limit exceeded” or “insufficient capacity” errors in us-east-1 were false negatives with the NLB heath checks which resulted in some Neo4j Aura DB clusters in us-east-1 losing fault tolerance \(1 out of 3 cluster members unavailable\). When this happened instances were removed by kubernetes and we were not able to provision new ones due to the EC2 failures noted earlier, leaving the clusters without fault tolerance for a prolonged period of time. All of these clusters still had full availability of the other two cluster members. ### **What are we doing now** Largely Neo4j Aura responded as designed to these events, isolating failures to us-east-1, with no to minimal cross system failure propagation. The cross cloud impact of creating DNS records for new instances was the main outlier. To mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures: * Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies. * Remove identified cross-region dependencies.
An active issue on AWS us-east-1 is affecting Neo4j Aura operations in the regions where we have some dependency on an impacted AWS service. See more details https://health.aws.amazon.com/health/status Other regions not currently impacted.
Operations such as Create, Pause, Resume, Clone are affected globally due to a dependency. Backups in the affected region of AWS us-est-1 will be impacted The affected AWS service is now starting to recover and we are monitoring the situation
We see clear signs of recovery and our impacted service are progressively getting back to normal. We will monitor and update when we can confirm full recovery and normal operations.
We are continuing to see good recovery across the service. We will update when this is completed.
The underlying AWS incident has bene resolved and our services have now resumed and fully recovered
### **What Happened** Between 08:41 UTC on October 20th and 09:00 UTC on October 21st, Neo4j Aura experienced service disruptions affecting the us-east-1 \(N. Virginia\) region in AWS. The incident was triggered by a broad AWS regional outage impacting Identity and Access Management \(IAM\) and the EC2 control plane. This resulted in delayed backups, temporary loss of database fault tolerance for a subset of users, and internal delays in administrative actions due to toolchain failures. A detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/) ### **How the service was affected** The primary cause was several AWS regional service disruptions in us-east-1. We will cover how each of these affected Neo4j Aura and its users. Neo4j Aura is designed to isolate regional failures. This is achieved through deploying customer instances in Orchestras that have instances in three availability zones and no cross region dependencies. AWS IAM and Identity Center became unresponsive, preventing Neo4j Aura’s automated systems from authenticating with AWS resources in us-east-1. This affected Neo4j Aura backups to be written to AWS S3 buckets. Customers were also not able to resume paused instances during this period as the resume process was not able to authenticate with AWS S3 buckets to retrieve the paused data set. Neo4j Aura’s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. AWS Network Load Balancer health check system failures and AWS EC2 “request limit exceeded” or “insufficient capacity” errors in us-east-1 were false negatives with the NLB heath checks which resulted in some Neo4j Aura DB clusters in us-east-1 losing fault tolerance \(1 out of 3 cluster members unavailable\). When this happened instances were removed by kubernetes and we were not able to provision new ones due to the EC2 failures noted earlier, leaving the clusters without fault tolerance for a prolonged period of time. All of these clusters still had full availability of the other two cluster members. ### **What are we doing now** Largely Neo4j Aura responded as designed to these events, isolating failures to us-east-1, with no to minimal cross system failure propagation. The cross cloud impact of creating DNS records for new instances was the main outlier. To mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures: * Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies. * Remove identified cross-region dependencies.
We are currently investigating this issue.
We are aware of an issue that could result in a degradation in write performance for all Aura instance. We have identified the cause and are preparing a fix.
We are continuing to investigate this issue.
The issue impact has been refined and currently could impact AuraDB Virtual Dedicated Cloud and Business Critical instances only. We have identified the cause and the faulty component has been reverted for the majority of instances. We will continue to monitor the situation, while the full fix is prepared.
We continue to work towards the issue resolution.
We are continuing to investigate this issue.
We are continuing to monitor the situation whilst a full fix for the solution is prepared.
We are continuing to monitor the situation. The full fix for the solution is currently undergoing final testing and will start deployment once testing is completed.
The full fix for the solution is starting to be deployed across the estate and are continuing to monitor the situation.
We are continuing to monitor for any further issues.
The full fix for the solution is continuing to be deployed across the estate and are continuing to monitor the situation.
The full fix for the solution has now been deployed across the estate and this issue is now resolved.
### **What happened** Between August 22 and August 28, 2025, a performance issue affected some of our database services following a recent update. Our team quickly responded and discovered that the problem was due to a bug in the latest update, which caused certain memory settings to be incorrectly configured. We promptly applied the previous version of those settings to stabilize the affected databases. By August 28, all databases were successfully transferred to a new, stable version, and the incident was fully resolved. The issue was caused by a misconfiguration in the system's data processing module. Specifically, an incorrect parameter setting in the data pipeline led to a bottleneck, which slowed down the processing speed. This misconfiguration affected the way data was being queued and processed, resulting in delays. Our technical team has identified the root cause and implemented a fix to ensure that the data pipeline operates efficiently, preventing future occurrences of this issue. ### **How the service was affected** Some customers reported a performance change on their instance. ### **What we are doing now** Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. New mitigations being deployed: * Enhancing our monitoring systems to detect similar issues faster * Implementing additional automated checks to prevent service disruptions * Improving our service resilience to handle similar scenarios * Introducing dynamic configuration management to ensure seamless updates * Enabling multiple configuration defaults to better manage database priorities * Improving notification systems for faster response to potential issues * Enhancing our tools to streamline database management and transfers
Engineers are investigating an issue whereby instance actions are not working. You may be unable to import data, pause, resume, create, delete or run manual backups for your instances. Regular Neo4j scheduled backups are continuing to run as normal. You may be unable to see your instances in the Aura Console. CMI is also experiencing an outage, you may be unable to ingest metrics from your Aura instances.
A fix has been identified and implemented. Instances should be showing on the console and instance operations should now be available. You should now also be able to ingest metrics using CMI. We are continuing to monitor the status of these services.
This incident has been resolved.
### What happened On August 22, 2025, from 10:10 to 11:27 UTC, users experienced an issue with the Aura Console where instance operations were unavailable. This was due to a timing issue with refreshing security keys that affected the visibility and operations of instances in the Aura Console and also caused an outage in the Customer Metrics Integration \(CMI\) and Aura API. The issue was identified within 5 minutes and efforts to resolve it began promptly. The problem was traced back to a recent update and issues with authentication were resolved by refreshing the system cache, with the service fully restored by 11:27 UTC. The issue arose because of a timing mismatch between the creation of new security keys and their recognition by our system. When new keys were generated, they were quickly used by the Console API. However, another part of our system, the database manager, was still using an older set of keys to verify requests. This mismatch caused requests to fail because the database manager could not recognize the new keys. No unauthorized operations were allowed and this did not affect the security of the service in any way. After approximately an hour, the system automatically updated its keys, and everything started working correctly again. ### How customers were affected Aura Console features were impacted, including the visibility of instances and therefore ability to connect to instances through the console. Driver connections to instances were not impacted. The issue also impacted the use of parts of the service including Customer Metrics Integration \(CMI\) and the Aura API. ### What we are doing now Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. We are taking steps to prevent similar issues in the future by improving our processes and monitoring systems. Changes we are making: * Enhancing our caching mechanisms to ensure seamless updates and prevent similar issues in the future. * Designing a robust process for updating service accounts and keys to guarantee uninterrupted service reliability.
We are currently investigating an issue with backups. We will update shortly as we get more details
We are continuing to investigate the issue with backups. New backups after 0:00 last night are failing to complete. Existing backups are unaffected and remain available.
We are continuing to investigate this issue.
We continue to investigate and have identified the issue more clearly. Beyond backups, other operations are also affected: pause and clone. Operations may fail or take a long time to complete.
The fix has been deployed and we will continue to monitor this incident.
This incident has been resolved.
### What happened On August 18, 2025, at 19:18 UTC, the release of a faulty component in Neo4j Aura impacted the ability to perform backups of customer instances. The problem was identified when a critical component was updated without aligning with another dependent component, leading to failed backup attempts. This resulted in Neo4j not being able to take backups of customer instances for a period of approximately 17 hours. Our team quickly identified the root cause and began mitigation efforts early on August 19, 2025. By 11:54 UTC, the issue was fully resolved, and normal backup operations resumed. We apologize for any inconvenience this may have caused and are taking steps to prevent similar issues in the future. The issue arose because the deployment of the neo4j-backup system was not properly synchronized with the deployment of the neo4j-operator. This misalignment led to critical changes being introduced that impacted the ability to create new backups effectively. Essentially, the two components were not updated in harmony, which caused disruptions in the backup process. ### How customers were affected Customers were unable to get successful backups of their instances for 17 hours. We promptly addressed the issue by reverting the recent backup changes that caused disruptions and ensured the stability of our service by cleaning up old, failing backups. ### What we are doing now Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. New mitigations being deployed: * Enhancing our monitoring systems to detect similar issues faster * Implementing additional automated checks to prevent service disruptions * Improving our service resilience to handle similar scenarios