Neo4j Aura incident

Issue impacting Aura instance operations

Resolved after 1 day 5 hours, affecting AuraDB Virtual Dedicated Cloud on AWS (*.databases.neo4j.io) and AuraDB Professional on AWS (*.databases.neo4j.io) and 1 more, on July 23, 2026.

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.

Started
Jul 23, 2026, 10:52 AM UTC
Resolved
Jul 24, 2026, 03:56 PM UTC
Duration
1d 5h
Detected by Pingoru
Jul 23, 2026, 10:52 AM UTC

Affected components

AuraDB Virtual Dedicated Cloud on AWS (*.databases.neo4j.io)AuraDB Professional on AWS (*.databases.neo4j.io)AuraDS on AWS (*.databases.neo4j.io)AuraDS Enterprise on AWS (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AWSAuraDB Virtual Dedicated Cloud on Azure (*.databases.neo4j.io)AuraDB Professional on Azure (*.databases.neo4j.io)AuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDS on Azure (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on Azure

Update timeline

  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.

Your product runs on more than Neo4j Aura

Add the vendors you depend on and get one message when any of them reports trouble. Free for 3 vendors, no card.

Add your stack →