https://approjects-vendor-status-watch.static.hf.space/v/neo4j-aura.htmlIncidents from Neo4j Aura's public status page, polled daily.Wed, 16 Sep 2026 12:28:20 +0000https://stspg.io/7n7b4bm9wbjmneo4j-aura:2026-09-16T08:50:58.001ZWed, 16 Sep 2026 08:50:58 +0000A fix is being rolled out and the portal should become less impacted by errors over time. See details https://status.salesforce.com/incidents/20004433https://stspg.io/x8rccw2ck809neo4j-aura:2026-09-09T12:31:50.233ZWed, 09 Sep 2026 12:31:50 +0000All affected components are now fully recovered.https://stspg.io/txy1c92n0b9mneo4j-aura:2026-09-03T16:43:28.850ZThu, 03 Sep 2026 16:43:28 +0000All instances are available, manual steps to unblock the remaining small number of instances was undertaken to resolve.https://stspg.io/n4gtks67r6gpneo4j-aura:2026-08-20T15:49:37.023ZThu, 20 Aug 2026 15:49:37 +0000Since the last update, the investigation has moved on. The issue was identified, and we monitored the service as it recovered from degradation. We confirm the issue is now resolved.https://stspg.io/fjp0c9ctq1bxneo4j-aura:2026-08-05T17:31:11.727ZWed, 05 Aug 2026 17:31:11 +0000We have monitored the fix and found the service to be stable. This incident is now considered resolved.https://stspg.io/f0r2mj7qz9cxneo4j-aura:2026-07-23T10:52:38.439ZThu, 23 Jul 2026 10:52:38 +0000### **What happened** On Thursday, Jul 23, 2026 10:33 UTC a configuration change was deployed to Aura that unintentionally altered how memory allocations were calculated for database instances. As a result, a subset of instances received insufficient memory, causing some database instances to become unavailable or unable to complete updates. The adjusted memory allocation led to out-of-memory conditions, causing database instances to repeatedly restart due to insufficient memory resources or become stuck updating. This issue affected instances across multiple cloud providers and multiple product tiers. Once the issue was identified, we immediately reverted the configuration change, preventing any additional instances from receiving the incorrect configuration. A corrected configuration https://stspg.io/fwjj9tdqq78kneo4j-aura:2026-07-10T17:18:26.938ZFri, 10 Jul 2026 17:18:26 +0000## What Happened Aura Console and other Aura components experienced disruptions on 2026-07-10 at 16:14 UTC, resulting in failures and crashloops. Consequently, a segment of customers faced visibility issues regarding their instances. It was caused by an outage in an external third-party service integrated with Aura. Crucially, database connectivity remained uncompromised, and the impacted instances continued their normal operations. LaunchDarkly service was restored to resolve the issue ## How the service was affected Multiple Aura components, including the Aura Console, experienced disruptions. Users encountered HTTP 500 errors on database-related pages and operations, though organizations and projects could still be accessed. Direct connections to specific database instances were comphttps://stspg.io/bfw41pvqwk7jneo4j-aura:2026-06-30T14:45:56.593ZTue, 30 Jun 2026 14:45:56 +0000## What Happened An issue was identified following the deployment of version 2026.06 on 2026-06-30 at 08:00 UTC, where running `CREATE VECTOR INDEX` on upgraded Aura instances triggered a system exception. This failure in index generation occurred because the underlying store and kernel required additional updates to support the operation This problem only impacted the creation of new indexes; existing vector indexes are not affected. Any vector index created before 09:00 on 2026-06-30 was unaffected and continued to work normally.  ## How the service was affected Following the rollout of version 2026.06, execution of the CREATE VECTOR INDEX statement failed, impacting applications that depended on adding new vector indexes. Affected clients received the error: _Creating a vector indexhttps://stspg.io/7tqbvt3xkd3rneo4j-aura:2026-06-23T11:25:47.835ZTue, 23 Jun 2026 11:25:47 +0000## What Happened At approximately 12:00 UTC on January 22, 2026, users encountered intermittent error banners within the Aura console displaying, "We're having a problem. Try again.," which occurred alongside 500 errors from console API endpoints. These disruptions were transient and caused by internal API timing out during the TLS handshake process, typically resolving within about 10 seconds or following a page refresh ## How the service was affected The Aura Console and Aura API experienced degraded performance, which manifested as intermittent error banners within the Aura console UI. An investigation identified the root cause as high CPU usage and throttling within the console API. This issue was primarily driven by repeated large entity listings and expensive reconciler requests https://stspg.io/1zcc4tqqzskmneo4j-aura:2026-05-26T18:23:22.000ZTue, 26 May 2026 18:23:22 +0000**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 thishttps://stspg.io/0l3qwfsg49bwneo4j-aura:2026-03-06T10:18:56.497ZFri, 06 Mar 2026 10:18:56 +0000## 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 implhttps://stspg.io/5dk93c72kc2tneo4j-aura:2026-03-03T21:35:35.749ZTue, 03 Mar 2026 21:35:35 +0000## 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 versihttps://stspg.io/0dz8yw87bs1zneo4j-aura:2026-03-02T19:55:47.600ZMon, 02 Mar 2026 19:55:47 +0000## 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/stahttps://stspg.io/s3qllcm4gv6gneo4j-aura:2026-01-26T19:26:32.605ZMon, 26 Jan 2026 19:26:32 +0000## **What Happened** Neo4j commenced the deployment of version 2026.01.1 to Aura free instances at 07:49 AM UTC on January 26, 2026. Following the detection of query failures during internal testing, the rollout was halted before it reached Aura higher tiers.  The failures occurred on conditional queries \(e.g. WHEN …THEN …\) after the planner phase to behave differently in the case of aggregation over null values. We identified the root cause and developed a resolution, which was integrated into version 2026.01.2. On January 27, 2026, we began deploying 2026.01.2 across Aura instances, successfully upgrading all affected environments to the corrected version ## How the service was affected Queries using WHEN in 2026.01.1 in combination with aggregation over null values get an incorrehttps://stspg.io/pzcv6h9c57cwneo4j-aura:2026-01-16T14:25:56.963ZFri, 16 Jan 2026 14:25:56 +0000### **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 incompatiblehttps://stspg.io/z76b3z3k80h2neo4j-aura:2025-11-26T15:47:58.305ZWed, 26 Nov 2025 15:47:58 +0000### **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 additihttps://stspg.io/2bnk6pt9m3srneo4j-aura:2025-11-18T15:56:12.929ZTue, 18 Nov 2025 15:56:12 +0000### 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 customershttps://stspg.io/8h32s5wy2r5fneo4j-aura:2025-10-20T16:43:35.114ZMon, 20 Oct 2025 16:43:35 +0000### **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 Nhttps://stspg.io/cclgmkdlytywneo4j-aura:2025-10-20T09:15:00.047ZMon, 20 Oct 2025 09:15:00 +0000### **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 Nhttps://stspg.io/qkm18s0mrzw7neo4j-aura:2025-08-25T13:34:19.372ZMon, 25 Aug 2025 13:34:19 +0000### **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 queuehttps://stspg.io/c7v46ysln3znneo4j-aura:2025-08-22T11:02:01.538ZFri, 22 Aug 2025 11:02:01 +0000### 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 qhttps://stspg.io/vztz2h95h13rneo4j-aura:2025-08-19T09:19:36.177ZTue, 19 Aug 2025 09:19:36 +0000### 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