Neo4j Aura Outage History

Started Oct 20, 2026, 07:35 AM UTC· resolved Oct 20, 2026, 02:50 PM UTC

1. investigating Oct 20, 2026, 07:35 AM UTC

   We are currently investigating an issue affecting the Europe West 2 region in GCP which is causing databases to become unavailable.

2. investigating Oct 20, 2026, 08:36 AM UTC

   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.

3. identified Oct 20, 2026, 09:15 AM UTC

   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.

4. identified Oct 20, 2026, 10:42 AM UTC

   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.

5. monitoring Oct 20, 2026, 12:38 PM UTC

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

6. monitoring Oct 20, 2026, 02:06 PM UTC

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

7. resolved Oct 20, 2026, 02:50 PM UTC

   This incident has been resolved

Read the full incident report →

Started Oct 13, 2026, 09:15 AM UTC· resolved Oct 13, 2026, 12:08 PM UTC

1. investigating Oct 13, 2026, 09:15 AM UTC

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

2. identified Oct 13, 2026, 10:13 AM UTC

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

3. monitoring Oct 13, 2026, 11:01 AM UTC

   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.

4. resolved Oct 13, 2026, 12:08 PM UTC

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

5. postmortem Oct 16, 2026, 05:06 PM UTC

   _**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._

Read the full incident report →

Started Oct 08, 2026, 02:58 PM UTC· resolved Oct 08, 2026, 07:11 PM UTC

1. investigating Oct 08, 2026, 02:58 PM UTC

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

2. identified Oct 08, 2026, 03:36 PM UTC

   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.

3. identified Oct 08, 2026, 04:30 PM UTC

   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.

4. identified Oct 08, 2026, 05:30 PM UTC

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

5. identified Oct 08, 2026, 06:41 PM UTC

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

6. resolved Oct 08, 2026, 07:11 PM UTC

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

7. postmortem Oct 16, 2026, 05:04 PM UTC

   _**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._

Read the full incident report →

Started Oct 06, 2026, 09:22 AM UTC· resolved Oct 06, 2026, 03:19 PM UTC

1. investigating Oct 06, 2026, 09:22 AM UTC

   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.

2. investigating Oct 06, 2026, 10:43 AM UTC

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

3. investigating Oct 06, 2026, 01:41 PM UTC

   We are continuing to investigate this issue.

4. investigating Oct 06, 2026, 01:41 PM UTC

   We are continuing to investigate the issue.

5. resolved Oct 06, 2026, 03:19 PM UTC

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

Read the full incident report →

Started Oct 06, 2026, 08:07 AM UTC· resolved Oct 06, 2026, 02:04 PM UTC

1. identified Oct 06, 2026, 08:07 AM UTC

   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.

2. identified Oct 06, 2026, 09:07 AM UTC

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

3. identified Oct 06, 2026, 10:03 AM UTC

   We continue to work on a fix for this issue.

4. identified Oct 06, 2026, 12:14 PM UTC

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

5. monitoring Oct 06, 2026, 01:35 PM UTC

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

6. resolved Oct 06, 2026, 02:04 PM UTC

   We have deployed the fix to all customers.

Read the full incident report →

Started Sep 17, 2026, 04:46 PM UTC· resolved Sep 17, 2026, 07:55 PM UTC

1. investigating Sep 17, 2026, 04:46 PM UTC

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

2. identified Sep 17, 2026, 05:11 PM UTC

   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.

3. monitoring Sep 17, 2026, 07:06 PM UTC

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

4. resolved Sep 17, 2026, 07:55 PM UTC

   After deploying the fix, we monitored the impacted instances, operational metrics, and errors. This incident is now resolved.

5. postmortem Oct 16, 2026, 04:23 PM UTC

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

Read the full incident report →

Started Sep 16, 2026, 08:50 AM UTC· resolved Sep 16, 2026, 02:31 PM UTC

1. identified Sep 16, 2026, 08:50 AM UTC

   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]

2. identified Sep 16, 2026, 09:16 AM UTC

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

3. identified Sep 16, 2026, 10:11 AM UTC

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

4. monitoring Sep 16, 2026, 11:30 AM UTC

   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

5. monitoring Sep 16, 2026, 12:29 PM UTC

   Our support portal provider continues to roll out a fix.

6. resolved Sep 16, 2026, 02:31 PM UTC

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

Read the full incident report →

Started Sep 09, 2026, 12:31 PM UTC· resolved Sep 09, 2026, 01:39 PM UTC

1. investigating Sep 09, 2026, 12:31 PM UTC

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

2. identified Sep 09, 2026, 12:54 PM UTC

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

3. identified Sep 09, 2026, 01:10 PM UTC

   We continue to work on addressing the issue.

4. identified Sep 09, 2026, 01:26 PM UTC

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

5. monitoring Sep 09, 2026, 01:36 PM UTC

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

6. resolved Sep 09, 2026, 01:39 PM UTC

   All affected components are now fully recovered.

Read the full incident report →

Started Sep 03, 2026, 04:43 PM UTC· resolved Sep 04, 2026, 03:36 PM UTC

1. investigating Sep 03, 2026, 04:43 PM UTC

   We are currently investigating this issue.

2. identified Sep 04, 2026, 10:23 AM UTC

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

3. resolved Sep 04, 2026, 03:36 PM UTC

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

Read the full incident report →

Started Aug 20, 2026, 03:49 PM UTC· resolved Aug 20, 2026, 07:10 PM UTC

1. investigating Aug 20, 2026, 03:49 PM UTC

   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.

2. investigating Aug 20, 2026, 04:18 PM UTC

   We continue to investigate the Aura metrics issue.

3. investigating Aug 20, 2026, 04:48 PM UTC

   We continue to investigate the Aura metrics issue.

4. resolved Aug 20, 2026, 07:10 PM UTC

   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.

5. postmortem Sep 17, 2026, 10:09 AM UTC

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

Read the full incident report →

Started Aug 05, 2026, 05:31 PM UTC· resolved Aug 07, 2026, 03:34 PM UTC

1. investigating Aug 05, 2026, 05:31 PM UTC

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

2. identified Aug 05, 2026, 07:27 PM UTC

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

3. identified Aug 06, 2026, 12:58 AM UTC

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

4. identified Aug 06, 2026, 07:13 AM UTC

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

5. identified Aug 06, 2026, 07:39 AM UTC

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

6. identified Aug 06, 2026, 11:17 AM UTC

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

7. identified Aug 06, 2026, 02:54 PM UTC

   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.

8. identified Aug 07, 2026, 01:15 AM UTC

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

9. identified Aug 07, 2026, 01:16 AM UTC

   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.

10. identified Aug 07, 2026, 09:44 AM UTC

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

11. monitoring Aug 07, 2026, 01:49 PM UTC

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

12. resolved Aug 07, 2026, 03:34 PM UTC

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

Read the full incident report →

Started Jul 23, 2026, 10:52 AM UTC· resolved Jul 24, 2026, 03:56 PM UTC

1. investigating Jul 23, 2026, 10:52 AM UTC

   We are currently investigating an issue at this time.

2. investigating Jul 23, 2026, 11:08 AM UTC

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

3. investigating Jul 23, 2026, 11:24 AM UTC

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

4. identified Jul 23, 2026, 11:38 AM UTC

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

5. identified Jul 23, 2026, 11:53 AM UTC

   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.

6. identified Jul 23, 2026, 12:11 PM UTC

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

7. identified Jul 23, 2026, 12:32 PM UTC

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

8. identified Jul 23, 2026, 12:49 PM UTC

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

9. identified Jul 23, 2026, 01:09 PM UTC

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

10. identified Jul 23, 2026, 01:35 PM UTC

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

11. identified Jul 23, 2026, 02:07 PM UTC

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

12. identified Jul 23, 2026, 02:27 PM UTC

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

13. monitoring Jul 23, 2026, 02:44 PM UTC

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

14. monitoring Jul 23, 2026, 03:03 PM UTC

    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.

15. monitoring Jul 23, 2026, 03:29 PM UTC

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

16. monitoring Jul 23, 2026, 03:57 PM UTC

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

17. monitoring Jul 23, 2026, 04:32 PM UTC

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

18. monitoring Jul 23, 2026, 05:01 PM UTC

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

19. monitoring Jul 23, 2026, 05:31 PM UTC

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

20. monitoring Jul 23, 2026, 06:07 PM UTC

    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.

21. monitoring Jul 23, 2026, 07:39 PM UTC

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

22. monitoring Jul 23, 2026, 10:28 PM UTC

    We are continuing to monitor for any further issues.

23. monitoring Jul 24, 2026, 01:02 AM UTC

    We are continuing to monitor for any further issues.

24. monitoring Jul 24, 2026, 02:56 AM UTC

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

25. monitoring Jul 24, 2026, 06:00 AM UTC

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

26. monitoring Jul 24, 2026, 08:30 AM UTC

    We are continuing to monitor for any further issues.

27. monitoring Jul 24, 2026, 12:59 PM UTC

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

28. resolved Jul 24, 2026, 03:56 PM UTC

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

29. postmortem Jul 29, 2026, 09:58 PM UTC

    ### **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.

Read the full incident report →

Started Jul 10, 2026, 05:41 PM UTC· resolved Jul 10, 2026, 05:53 PM UTC

1. monitoring Jul 10, 2026, 05:41 PM UTC

   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.

2. monitoring Jul 10, 2026, 05:42 PM UTC

   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.

Read the full incident report →

Started Jul 10, 2026, 05:18 PM UTC· resolved Jul 10, 2026, 07:23 PM UTC

1. investigating Jul 10, 2026, 05:18 PM UTC

   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.

2. investigating Jul 10, 2026, 05:23 PM UTC

   We are continuing to investigate this issue.

3. monitoring Jul 10, 2026, 05:51 PM UTC

   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.

4. resolved Jul 10, 2026, 07:23 PM UTC

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

5. postmortem Jul 27, 2026, 04:28 AM UTC

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

Read the full incident report →

Started Jun 30, 2026, 02:45 PM UTC· resolved Jun 30, 2026, 05:45 PM UTC

1. identified Jun 30, 2026, 02:45 PM UTC

   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.

2. identified Jun 30, 2026, 03:41 PM UTC

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

3. monitoring Jun 30, 2026, 04:05 PM UTC

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

4. resolved Jun 30, 2026, 05:45 PM UTC

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

5. postmortem Jul 20, 2026, 08:40 AM UTC

   ## 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

Read the full incident report →

Started Jun 23, 2026, 11:25 AM UTC· resolved Jun 24, 2026, 09:14 AM UTC

1. identified Jun 23, 2026, 11:25 AM UTC

   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

2. identified Jun 23, 2026, 01:03 PM UTC

   We are continuing to investigate a fix for the issue

3. identified Jun 23, 2026, 01:39 PM UTC

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

4. monitoring Jun 23, 2026, 03:43 PM UTC

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

5. monitoring Jun 23, 2026, 07:27 PM UTC

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

6. monitoring Jun 24, 2026, 09:14 AM UTC

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

7. resolved Jun 24, 2026, 09:14 AM UTC

   This incident has been resolved.

8. postmortem Jul 10, 2026, 02:50 PM UTC

   ## 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

Read the full incident report →

Started May 26, 2026, 06:23 PM UTC· resolved May 26, 2026, 11:06 PM UTC

1. investigating May 26, 2026, 06:23 PM UTC

   Aura Console is currently not accessible. Our team is investigating the issue. Aura instances are running normally and are not impacted. Console-related administration and configuration procedures may be unavailable. We will provide updates as soon as more information is available.

2. monitoring May 26, 2026, 07:19 PM UTC

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

3. resolved May 26, 2026, 11:06 PM UTC

   This incident has been resolved.

4. postmortem Jun 09, 2026, 04:50 PM UTC

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

Read the full incident report →

Started Mar 06, 2026, 10:18 AM UTC· resolved Mar 06, 2026, 10:25 AM UTC

1. identified Mar 06, 2026, 10:18 AM UTC

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

2. monitoring Mar 06, 2026, 10:24 AM UTC

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

3. resolved Mar 06, 2026, 10:25 AM UTC

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

4. postmortem Mar 30, 2026, 07:25 AM UTC

   ## 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

Read the full incident report →

Started Mar 03, 2026, 09:35 PM UTC· resolved Mar 04, 2026, 03:19 PM UTC

1. identified Mar 03, 2026, 09:35 PM UTC

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

2. identified Mar 04, 2026, 01:39 AM UTC

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

3. identified Mar 04, 2026, 04:52 AM UTC

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

4. monitoring Mar 04, 2026, 02:07 PM UTC

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

5. resolved Mar 04, 2026, 03:19 PM UTC

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

6. postmortem Apr 08, 2026, 06:39 AM UTC

   ## 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

Read the full incident report →

Started Mar 02, 2026, 07:55 PM UTC· resolved Mar 06, 2026, 04:06 PM UTC

1. identified Mar 02, 2026, 07:55 PM UTC

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

2. identified Mar 03, 2026, 06:19 AM UTC

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

3. identified Mar 03, 2026, 03:26 PM UTC

   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.

4. identified Mar 03, 2026, 10:43 PM UTC

   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.

5. identified Mar 04, 2026, 10:10 AM UTC

   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.

6. identified Mar 05, 2026, 02:42 AM UTC

   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.

7. identified Mar 05, 2026, 02:39 PM UTC

   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.

8. identified Mar 06, 2026, 02:08 AM UTC

   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.

9. identified Mar 06, 2026, 02:29 PM UTC

   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.

10. resolved Mar 06, 2026, 04:06 PM UTC

    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

11. postmortem Mar 29, 2026, 03:16 PM UTC

    ## 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)

Read the full incident report →

Started Jan 26, 2026, 07:26 PM UTC· resolved Jan 27, 2026, 03:58 PM UTC

1. identified Jan 26, 2026, 07:26 PM UTC

   We have identified an issue that may affect a limited set of Cypher 25 queries for AuraDB Free, Professional and AuraDS. This may affect: - Queries using the conditional query WHEN in combination with a non-grouping aggregation over null values result in an incorrect number of rows returned. - Queries using NEXT can produce an unexpected variable not defined error in some instances. We are actively working on a fix and will update this page as more information becomes available.

2. identified Jan 27, 2026, 01:37 AM UTC

   We have identified a solution for this issue and will be rolling out in Aura. Once the update has been deployed we will update this tatus page.

3. identified Jan 27, 2026, 09:50 AM UTC

   We are rolling out the fix and will update you when this is completed.

4. monitoring Jan 27, 2026, 11:10 AM UTC

   The fix has rolled out to the affected components, we are now monitoring the situation at this time.

5. monitoring Jan 27, 2026, 02:51 PM UTC

   We are continuing to monitor the situation at this time.

6. resolved Jan 27, 2026, 03:58 PM UTC

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

7. postmortem Jul 02, 2026, 04:22 AM UTC

   ## **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 incorrect number of rows returned. Queries using NEXT can in some instances produce an unexpected variable not defined error. This caused the rewritten query to behave differently in the case of aggregation over null values. The conditional query would need to receive incoming rows containing null values and be aggregating over the values without using a grouping. Customers received an incorrect result if they were using the conditional query construct in Cypher 25 \(see [https://neo4j.com/docs/aura/managing-instances/cypher-version/](https://neo4j.com/docs/aura/managing-instances/cypher-version/)\), an impact that was limited to a limited number of Aura instances. ## What are we doing now We have enhanced our testing procedures to ensure comprehensive coverage across all product areas. This includes the development of new test cases designed to address both identified issues and potential future scenarios. Furthermore, we have integrated Cypher query testing within Aura as a standard component of our regression testing suite. These checks are now mandatory stages within our Continuous Integration pipeline and staging environments prior to any production rollout.

Read the full incident report →

Started Jan 16, 2026, 02:25 PM UTC· resolved Jan 16, 2026, 07:36 PM UTC

1. identified Jan 16, 2026, 02:25 PM UTC

   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.

2. identified Jan 16, 2026, 03:13 PM UTC

   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.

3. monitoring Jan 16, 2026, 05:07 PM UTC

   The fix is currently rolling out to production. We will update you upon completion

4. resolved Jan 16, 2026, 07:36 PM UTC

   All instances should have the fix applied and if not it should be in the next 60 minutes

5. postmortem Apr 23, 2026, 01:27 PM UTC

   ### **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.

Read the full incident report →

Started Nov 26, 2025, 03:47 PM UTC· resolved Dec 11, 2025, 03:39 PM UTC

1. identified Nov 26, 2025, 03:47 PM UTC

   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.

2. identified Nov 26, 2025, 08:33 PM UTC

   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.

3. identified Nov 27, 2025, 10:52 AM UTC

   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.

4. identified Nov 27, 2025, 02:33 PM UTC

   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.

5. identified Nov 27, 2025, 05:07 PM UTC

   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.

6. identified Nov 27, 2025, 08:11 PM UTC

   We continue to work with our cloud infrastructure provider. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

7. identified Nov 28, 2025, 12:09 AM UTC

   We continue to work with our cloud infrastructure provider . Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

8. identified Nov 28, 2025, 04:54 AM UTC

   We continue to work with our cloud infrastructure provider. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

9. identified Nov 28, 2025, 08:54 AM UTC

   We continue to work with our cloud infrastructure provider. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

10. identified Nov 28, 2025, 10:55 AM UTC

    We continue to work with our cloud infrastructure provider. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

11. identified Nov 28, 2025, 04:23 PM UTC

    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.

12. identified Dec 01, 2025, 09:54 AM UTC

    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.

13. identified Dec 02, 2025, 10:03 AM UTC

    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.

14. identified Dec 03, 2025, 10:52 AM UTC

    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.

15. identified Dec 04, 2025, 09:52 AM UTC

    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.

16. identified Dec 05, 2025, 10:20 AM UTC

    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.

17. identified Dec 05, 2025, 04:59 PM UTC

    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.

18. monitoring Dec 11, 2025, 10:24 AM UTC

    Cloud resources have become available in USEAST2 and we will monitor for a few hours to ensure there is no further customer impact.

19. resolved Dec 11, 2025, 03:39 PM UTC

    Cloud resources have become available in USEAST2 and no further customer impact has been detected. This incident is resolved.

20. postmortem Feb 04, 2026, 03:18 PM UTC

    ### **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.

Read the full incident report →

Started Nov 18, 2025, 03:56 PM UTC· resolved Nov 18, 2025, 04:39 PM UTC

1. identified Nov 18, 2025, 03:56 PM UTC

   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.

2. monitoring Nov 18, 2025, 04:16 PM UTC

   We have released a fix to this issue and are monitoring to ensure all operations are back to normal.

3. resolved Nov 18, 2025, 04:39 PM UTC

   After monitoring the fix for some time, we can confirm that the issue is resolved and normal operations have resumed.

4. postmortem Jan 14, 2026, 02:05 PM UTC

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

Read the full incident report →

Started Oct 20, 2025, 04:43 PM UTC· resolved Oct 20, 2025, 09:28 PM UTC

1. identified Oct 20, 2025, 04:43 PM UTC

   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.

2. identified Oct 20, 2025, 07:14 PM UTC

   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

3. resolved Oct 20, 2025, 09:28 PM UTC

   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.

4. postmortem Jan 15, 2026, 05:48 PM UTC

   ### **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.

Read the full incident report →