Is Neo4j Aura down?

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.

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.

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.

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 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 resolve the 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 for any further issues.

We are continuing to monitor for any further issues.

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

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.