Neo4j Aura outage history

We are currently aware of an issue that is impacting customers using Aura on Azure, when attempting to download database instance snapshots.

We have identified the issue and are currently working on the deployment of the fix.

The fix is currently being tested in lower environments, prior to being deployed.

Testing of the fix is ongoing and deployment will proceed once the testing has been completed.

Our engineers have successfully deployed a fix, and the issue is now resolved. Aura customers on Azure can now download database snapshots without issues.

We are currently investigating an issue affecting the Europe West 2 region in GCP which is impacting some operations, including database instance creation in the region.

We are continuing to investigate the issue currently, working with the GCP to find a resolution. At this time some operations, including database instance creation in the region continue to remain impacted.

We have identified the source of the issue currently affecting customers on europe-west2 on GCP. Further details available from GCP statuspage at https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj. At this time some operations, including database instance creation in the region continue to remain impacted.

We are currently implementing remedial action to mitigate the issue in the meantime. Follow the latest from GCP in the statuspage at https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.

Functionality should now be restored across the affected Aura services. We will monitor the situation closely before considering this resolved.

We are continuing to monitor the situation with GCP at the current time and at this point we have seen no new issues.

This incident has been resolved

We are investigating an issue impacting metrics in the Aura Console and via the metric endpoint.

We have identified that a Cloud Service Provider related issue is impacting the current situation. We have opened a support case with the Cloud Service Provider and will update further once we have more detail.

We believe that the Cloud Service Provider issue has been resolved, as we are no longer seeing issues from our internal systems. We will continue to monitor the situation, while we wait for confirmation from the Cloud Service provider.

We have had confirmation from the Cloud Service Provider that the issue has now been fully resolved.

_**Errors when sending metrics from GCP europe-west1**_ _**What happened**_ _On Tuesday, October 13, 2026 at 08:54 UTC, metrics for instances in GCP europe-west1 stopped being delivered and could not be read. The cause was an issue on the Google Cloud side, where a capacity reduction in its monitoring service led to valid requests being incorrectly rejected. Metrics returned to normal at 10:49 UTC after Google Cloud applied a fix, and we resolved the incident at 12:08 UTC once Google Cloud confirmed full resolution._ _Instances remained available throughout this event, with no impact to query performance or data integrity. Only metrics visibility was affected._ _**How the service was affected**_ _Customers saw some short gaps in instance metrics:_ * _**Console metrics:** Instances in GCP europe-west1 may have shown incomplete or missing metric data during the incident window._ * _**Cloud Monitoring Integration \(CMI\):** Metrics forwarded to your own monitoring systems from this region may also have had gaps._ _Not all instances in the region were impacted, and other cloud providers and regions were unaffected. Metrics generated during the incident were not recorded, so the gap will remain in historical charts for affected instances._ _**What we are doing now**_ _The fix came from Google Cloud on this occasion, but our metrics pipeline relied on a single-region path, so we are taking steps to reduce that exposure:_ * _**Regional resilience:** We are evaluating cross-region routing so metrics traffic can fail over to a healthy region._ * _**Traffic routing:** We are exploring options in our cloud networking layer to reroute both reads \(Console and CMI\) and writes \(ingestion\) away from an impacted region._

We are investigating an issue with metrics in the Aura Console and via the metric endpoint.

We continue to investigate the root cause. The issue is limited to customers on us-central1 on GCP Aura instances are running and no operation is affected.

We are working with the cloud service provider to investigate the nature of the issue. Our checks confirm that only a subset of customers running in the us-central1 regions are affected.

We continue to work with the cloud service provider to get a solution.

This incident has now been resolved, metrics should now operate as normal.

_**Errors when sending metrics from GCP us-central1**_ _**What happened**_ _On Thursday, October 8, 2026 at 14:05 UTC, metrics from some instances in GCP us-central1 stopped being delivered. The cause was an issue on the Google Cloud side that incorrectly rejected valid metric requests. Metric delivery resumed at 18:00 UTC after Google Cloud applied a fix, and we resolved the incident at 18:48 UTC._ _Instances remained available throughout this event, with no impact to query performance or data integrity. Only metrics visibility was temporarily affected._ _**How the service was affected**_ _Customers saw gaps in instance metrics:_ * _**Console metrics:** Instances in GCP us-central1 may have shown incomplete or missing metric data during the incident window._ * _**Cloud Monitoring Integration \(CMI\):** Metrics forwarded to your own monitoring systems from this region may also have had gaps._ _Not all instances in the region were affected, and other cloud providers and regions were unaffected._ _**What we are doing now**_ _The fix came from Google Cloud, but we are taking steps to catch and respond to similar events sooner:_ * _**Alerting on metric delivery errors:** We are adding alerting on metric forwarding error rates, so provider-side failures are detected earlier and distinguished from routine gaps._ * _**Continued monitoring:** We will keep monitoring the region with Google Cloud for any recurrence._

We are investigating an issue where, despite backups completing successfully, snapshot downloads are returning blank dumps. Restoring from a snapshot through the Aura console or API is not believed to be affected, and we are verifying this now. We will share an update as soon as we have more information.

We are continuing to investigate the issue. Restore operations are not affected as part of this issue.

We are continuing to investigate this issue.

We are continuing to investigate the issue.

A fix has been deployed; snapshot downloads now contain the appropriate data.

# What happened On Fri, 18 Sep 2026 14:33 UTC, we identified that snapshot downloads for Aura instances hosted on Azure were returning files of approximately 24KB instead of the expected multi-gigabyte size. The underlying backups stored in Azure were the correct size, but the download path in the console was serving near-empty files. The root cause was an Azure credential issue that occurred during a deployment and prevented backup data from being served for download. An initial fix was deployed on Mon, 21 Sep 2026 10:31 UTC, restoring correct download sizes. However, the same credential issue recurred on Tue, 06 Oct 2026 08:20 UTC, again producing blank snapshot downloads across all Azure tiers. Our engineering team identified the recurrence, linked it to the same root cause, deployed a targeted credential fix to production, and verified that downloads returned to their expected size. We did not post to the status page on September 18 because a small number of customers were affected, and we worked with them directly. We posted on October 6 at 09:22 UTC, about an hour after the recurrence began, once it was clearly broader. # How the service was affected Snapshot downloads were impacted for AuraDS Professional and Enterprise, AuraDB Professional, Business Critical and Virtual Dedicated Cloud instances running on Azure. * Snapshot downloads returned unusable files. When customers downloaded snapshots from the console, they received files of roughly 24KB instead of the actual backup data, which could be several gigabytes in size. This made the downloaded snapshots unusable for offline restore or migration purposes. * Backups themselves were not lost. The underlying backup artifacts stored in Azure remained intact and correctly sized. The issue was strictly in the download path, not in the backup capture or storage process. * Restoring via the console was unaffected. In-platform restore operations \(as opposed to downloading a dump file\) continued to function because they accessed the backup data directly rather than through the affected download path. # What we are doing now We have taken multiple steps to resolve the issue and have implemented safeguards to prevent recurrence. * Credential fix deployed. We corrected the Azure credential issue in production, which immediately restored snapshot downloads for all affected instances. * Preventing unintended credential rotation. A code change has been submitted to revert the logic that was triggering Azure credential rotation on every deployment. This ensures that future deployments will not inadvertently invalidate existing credentials, which was the mechanism that caused both the initial incident and its recurrence. * Ongoing monitoring. We are monitoring Azure snapshot downloads across all tiers to confirm they remain stable. We have asked affected customers to verify that their downloads now return the expected file sizes. These changes address both the immediate symptom and the underlying deployment behavior that allowed the issue to recur

We have identified an issue when attempting to restore from snapshots on AuraDS. We have a fix ready and will deploy this soon. In the meantime you can restore from a backup instead.

We have clearly identified the root cause and continue to work on a fix for this issue.

We continue to work on a fix for this issue.

A fix is being deployed and will roll out to affected customers shortly.

The fix is rolling out and affected customers should see the functionality restored progressively.

We have deployed the fix to all customers.

# What happened A software defect in a central management component of Neo4j Aura snapshot restores to fail for AuraDS Professional and AuraDS Enterprise instances hosted on AWS. When a restore was requested, the system looked up the instance using an incorrect resource type and returned an error. The incident was declared on Monday, 05 Oct 2026 21:52 UTC. Our engineering team identified the root cause, developed and validated a fix, and deployed it to production on Tuesday, 06 Oct 2026 13:37 UTC. # How the service was affected The impact was scoped to snapshot restore operations for AuraDS Professional and AuraDS Enterprise instances. Affected customers were unable to restore snapshots via the Aura Console or the Aura API for the duration of the issue. * Restore attempts returned errors, disrupting workflows that depend on snapshot restores. * Instances remained available throughout this event. Data integrity was not impacted. Restoring from full and exported backups remained available as a workaround. # What we are doing now * We have fixed the defect in Aura's management layer that affected AuraDS Professional and AuraDS Enterprise snapshot restores and deployed the fix to production. * Deployment pipeline optimization: During this incident, the deployment pipeline took longer than ideal due to sequential test instance creation. We have evaluated parallelizing test instance creation to reduce wait times during critical rollouts. This improvement aims to shorten the time it takes to validate and ship a fix in future incidents, reducing customer-facing impact

We are currently aware of an issue that is impacting certain database operations, such as create, delete, clone for customers using Aura on Azure.

We have identified the issue and are working towards a solution. At this time, certain database operations, such as create, delete, and clone for customers using Neo4j Aura on Azure only, continue to be impacted.

A fix has been deployed to all affected environments. We will monitor the situation to ensure that the fix fully resolves the issue.

After deploying the fix, we monitored the impacted instances, operational metrics, and errors. This incident is now resolved. A post-mortem will be available as soon as it’s been completed.

# What happened On Thursday, 17 September 2026 at 13:52 UTC, a deployment-time conflict between concurrent operations caused a credential used by a core Aura component to authenticate with Azure-hosted infrastructure to be removed. As existing authentication tokens expired, the component began returning errors for some Aura instances hosted on Azure, affecting certain database operations. We traced the errors to the missing credential, created a new one, stored it securely, and performed a rolling deployment of the affected component, which completed at 18:39 UTC. A small number of database creation requests that were in progress during the outage were left in an incomplete state and needed manual remediation. This was completed at 19:48 UTC, and the incident was marked resolved at 19:55 UTC. # How the service was affected The impact was limited to Aura instances hosted on Azure. Other cloud providers were not affected. * **Database operations:** Customers were unable to perform certain database operations, such as create, delete, and clone, on some Azure instances during the incident window. A small number of creates that were in progress became stuck and were recovered manually. * **Management visibility:** Some Azure-hosted instances were temporarily not visible or manageable in Aura Console. * **Metrics gaps:** Metrics endpoints for some Azure instances returned intermittent errors, leaving short gaps in metrics data for the affected period. This data will not be backfilled. Azure instances that were already running remained available and continued to serve workloads normally. # What we are doing now We are taking the following steps to help prevent a recurrence and improve our response: * **Earlier detection and communication:** We will improve monitoring and alerting, and evaluate automated credential checks, so issues are detected and customers are informed sooner. * **Recovery from incomplete database creation:** We will fix a defect that can leave a database creation stuck if an infrastructure call fails partway through, so the system recovers on its own. * **Authentication review:** We will review how this component authenticates with cloud providers, to remove single points of failure and reduce the risk of this type of conflict recurring.

Our service provider for the support portal is experiencing some outage - See https://status.salesforce.com/products/Salesforce_Services If you experience issues submitting a new support case, please send email to [email protected]

Our support portal provider is still working on addressing the issue. See details here https://status.salesforce.com/incidents/20004433

Our support portal provider continues to work on addressing the issue. See details here https://status.salesforce.com/incidents/20004433

A fix is being rolled out and the portal should become less impacted by errors over time. See details https://status.salesforce.com/incidents/20004433

Our support portal provider continues to roll out a fix.

A fix has been deployed and all functionality should now be recovered.

We are currently investigating an issue affecting the Aura console console.neo4j.io and the API api.neo4j.io

We have identified the source of the issue and are currently working on a solution.

We continue to work on addressing the issue.

We have made good progress and are recovering the problematic component.

We have deployed a fix and the affected services are recovering.

All affected components are now fully recovered.

We are currently investigating this issue.

The issue has been identified, instances remain available and steps to resolve for the instances impacted being reviewed currently.

All instances are available, manual steps to unblock the remaining small number of instances was undertaken to resolve.

Our team has identified an issue with collecting the metrics for Aura instances. This will impact the metric visibility and forwarding. We are currently investigating the issue.

We continue to investigate the Aura metrics issue.

Since 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.

# What happened On Thursday, 20 Aug 2026 14:58:00 UTC, our metrics ingestion pipeline began experiencing elevated export failures when sending data to Google Managed Prometheus \(GMP\). The underlying cause was a Google Cloud Platform service incident in the `us-west1` region, which disrupted the export path used by our metrics collection infrastructure. As a result, metric export queues began building up across a subset of production environments. The failures manifested primarily as network timeouts when attempting to deliver metric data to GMP, preventing normal ingestion for affected clusters. Our engineering team identified the geographic concentration of affected systems — spanning AWS `us-west-2`, Google Cloud `us-west1`, and Azure `westus2` — all of which route through infrastructure in the Oregon area. Once the GCP regional incident was mitigated by Google, export errors subsided and queues began draining. # How the service was affected The impact was limited to **metrics visibility** for a subset of Aura environments. Approximately 45 customer environments were affected, meaning that metric data from databases was not being ingested into our monitoring platform during the incident window. The most affected region was AWS `us-west-2`, with additional impact in Google Cloud `us-west1` and Azure `westus2`. Customers with databases in these regions may have experienced gaps in their metrics dashboards and monitoring data for the duration of the incident. Core database operations — including reads, writes, and availability — were **not affected**; only the collection and visibility of performance metrics was disrupted. Once Google mitigated the underlying regional issue, metric ingestion resumed and the backlog of queued data was processed. # What we are doing now We have conducted a thorough review of this incident and are taking the following steps to improve our resilience and response capabilities: * **Improved observability dashboards**: We are enhancing our metrics exporter dashboards to provide clearer, faster visibility into queue health and export error rates, enabling quicker detection and diagnosis of similar issues. * **Improve alert aggregation**: We are implementing automatic alert grouping so that a regional incident affecting multiple clusters is better surfaced as a single correlated event and treated with appropriate severity and attention. * **Proactive alerting on ingestion error rates:** We are adding dedicated alerts that fire on elevated GMP ingestion error rates, giving our team an earlier signal before exporter queues reach capacity. These improvements are designed to reduce detection time, simplify incident triage, and strengthen our metrics pipeline against future upstream provider disruptions.

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.

We are currently investigating an issue at this time.

We are working with engineering teams and making progress with the investigations at the current time.

We are working with engineering teams and continuing to make progress with the investigations at the current time.

We have identified the cause of the current issue and are actively working on the fix currently.

We are deploying the first part of the fix and continue actively working on rolling out the full solution. We expect an ETA in the order of 1hour from now.

We have identified the subset of instances impacted and continue to deploy the fix at this time.

We have deployed a configuration fix and are now working to resolve the subset of instances impacted.

With the configuration fix deployed, we are continuing to resolve the subset of instances still impacted.

We are continuing to resolve the subset of instances still impacted.

We continue to resolve the subset of instances which are still impacted.

We continue to resolve the subset of instances which are still impacted.

AuraDB Virtual Dedicated Cloud and AuraDB Business Critical should all now be fixed. We continue to resolve the subset of instances which are still impacted for AuraDB Professional and Free.

We continue to resolve the subset of instances which are still impacted for AuraDB Professional and Free.

We continue to resolve the subset of instances that are still impacted for AuraDB Professional and Free.

We continue to resolve the subset of instances that are still impacted for AuraDB Professional and Free

We continue to fix a subset of instances that are still impacted for AuraDB Professional and Free

We continue to fix a small subset of instances that are still impacted under the AuraDB Professional and Free tiers.

We addressed the issue in all AuraDB Professional instances. Aura Free can still be affected. We will continue to monitor and fix the remaining databases.

We continue to fix a small subset of Free instances that are still impacted.

We are continuing to monitor the situation closely for any further issues.

We are continuing to monitor for any further issues.

All identified instances have been fix, continuing to monitor. Contact customer support for any further issues.

All fixes have been deployed and issue is now marked as resolved.

### **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 was deployed to production by Thursday, Jul 23, 2026 11:56 UTC. However, database instances that had already received the incorrect configuration required individual recovery actions before they could return to normal operation. By Thursday Jul 23, 2026 17:59 UTC, all known customer-impacting database instances had been recovered. Monitoring continued through the following day, with the incident fully resolved on Friday, Jul 24, 2026 16:30 UTC. ### **How the service was affected** The primary customer impact was that several AuraDB database instances became unavailable or entered a degraded state. Affected instances were unable to complete routine software updates and, in some cases, repeatedly restarted because insufficient memory had been allocated. * **Service availability:** Customer impact varied by service tier. AuraDB Professional instances, which do not provide High Availability, experienced the greatest level of service disruption, with a subset becoming unavailable and unable to process reads or writes. For affected AuraDB Business Critical and Virtual Dedicated Cloud \(VDC\) instances, the impact was generally limited to a temporary loss of fault tolerance while service availability was maintained. In a smaller number of cases, Business Critical and VDC instances also became unavailable. * **Stuck updates**: Additional instances remained available but were stuck in an "Updating" state, which blocked customer-initiated operations such as resizes or configuration changes. * **Cross-platform scope**: The impact spanned all three supported cloud providers and multiple regions, affecting customers globally. Customer Support cases were raised and our team triaged and manually recovered affected instances in priority order. The majority of AuraDB instances continued to operate normally. Customer impact was fully mitigated through the configuration revert and targeted manual recovery of each affected instance. ### **What we are doing now** We have carried out a thorough analysis of this incident and have identified the following actions: * **Prevention** * **Improved deployment validation:** We are strengthening our release validation process to better identify configuration changes. * **Component decoupling**: We are evaluating improvements to the sequencing of component deployments to reduce the risk of unintended changes being included in releases. * **Progressive rollout strategy**: We are reviewing the rollout process for the affected components, to bring them in line with the rollout controls used for other critical components. * **Detection** * **Better alerting**: We are enhancing our monitoring to detect abnormal increases in failure rates \(such as loss of fault tolerance or availability\) more quickly and reliably. * **Mitigation** * **Safer configuration deployment:** We are improving how production configuration changes are deployed so they can be disabled or rolled back more quickly without requiring a broader software release. * **Faster manual recovery tooling**: We are improving our recovery tooling to reduce the time required to identify and manually recover affected instances. We recognize the disruption this incident caused and apologize for the impact to affected customers. We have completed the immediate corrective actions, and the longer-term improvements described above are already underway to reduce the likelihood and impact of similar incidents in the future.

We are currently investigating an issue affecting the Aura Console where some customers may be unable to see their instances. This issue is caused by a failure in a third-party service that Aura depends on. Affected instances continue to run normally, and database connectivity is not impacted. Our team is actively investigating the issue.

We are continuing to investigate this issue.

The third-party service that Aura depends on has restored normal operations and the Neo4j Aura systems have recovered. Our team is actively monitoring the issue to confirm Aura Console is performing as expected.

Services are confirmed to be operational and no further interruptions are expected.

## 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 completely unaffected The control plane became unavailable, which meant that users could not create, delete, resize, or adjust settings for instances via the API or the Aura console. Existing instances, however, remained operational. The issue was caused by an outage on LaunchDarkly and our services did not handle that dependency failure gracefully during startup. All affected systems returned to normal operation by  2026-07-10 at 17:07 UTC ## What are we doing now The Neo4j Engineering team swiftly diagnosed the root cause and restored service. In evaluating this incident, we have identified key areas to accelerate future resolutions and mitigate recurrence risks: * Analyzed key incident metrics, focusing on alert-to-response duration to identify opportunities for accelerating response efficiency * Conducted a comprehensive retrospective highlighting successful outcomes, including swift root-cause analysis via transparent logging, seamless alignment via the incident management tool, and the resilient, graceful degradation of multiple components that kept data plane connectivity intact * Actively developing more graceful fallback defaults for feature flags to safeguard core operations during vendor downtimes * Strengthening architectural resilience by integrating advanced planning, chaos engineering practices, and production-level fault injection testing to preemptively uncover and mitigate potential failure paths * Addressed logic limitations in operator feature flag caching, emphasizing the necessity for operators to store evaluated flags locally to preserve operational continuity if external dependencies fail.

Running CREATE VECTOR INDEX fails with error 51N31 error: system configuration or operation exception - not supported. Creating a vector index with provided settings is not supported in V2026_02. Required version for operation is V2026_06. Please upgrade DBMS.. This only affects new index, existing VECTOR INDEX are unaffected. Any vector index created prior to 2026-06-30 at 09:00 continue to operate normally.

We are starting now to deploy a fix to address this issue and will provide an update soon on progress.

A fix is rolling out and progressing well. We will update with progress.

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

## 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 index with provided settings is not supported in V2026\_02. The required version for operation is V2026\_06. Please upgrade DBMS_. Existing indexes \(created prior to this incident\) and other queries remained entirely unaffected and fully functional. ## What are we doing now Neo4j teams identified the root cause as a bug in the Cypher planner and resolved the issue with a code fix. This fix has been deployed to all affected Aura instances, fully resolving the error To prevent future occurrences, we are enhancing our monitoring and alerting systems to detect similar issues earlier, particularly within staging environments, before rollouts occur. Simultaneously, we are refining our deployment processes to minimize customer impact and recovery times Additionally, we are investigating options to implement automated, post-upgrade validation tests specifically for critical operations such as vector index creation

Aura console is experiencing some intermittent errors: "Our system is experiencing problems right now. try again later or contact support if the problem persists." This may require you to reload or wait longer for navigating in the console Operations and the Aura API remain unaffected We are actively working on a fix

We are continuing to investigate a fix for the issue

We are continuing to work on a fix for this issue.

We are deploying a change. We will monitor and update.

Continuing to monitor the deployed changes. Next update expected 6/24/2026 10am UTC.

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

This incident has been resolved.

## 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 To address the issue, targeted fixes were successfully deployed to both the Aura console and Aura API. This was followed by adjustments to the resource configuration to increase operational headroom and ensure stability ## What are we doing now The following reactive and proactive measures have been implemented to reduce the likelihood of similar incidents: * Developed a monitoring dashboard to observe request drops based on internal API log data to implement automated monitoring and alerting to catch issues before they occur * Implemented a staggered delay between paginated reconciler requests to mitigate high resource consumption and improve API stability * Enhanced infrastructure aware resources calculations to improve performance * Introduced a new filter for queries based on service tiers to optimize CPU overhead for each calls performed by the reconciler * Deactivated redundant request middleware processing to optimize API calls

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)