Neo4j Aura incident

Database instance write performance impacted

Minor Resolved View vendor source →

Neo4j Aura experienced a minor incident on August 26, 2025 affecting AuraDB Virtual Dedicated Cloud on AWS (*.databases.neo4j.io) and AuraDB Professional on AWS (*.databases.neo4j.io) and 1 more component, lasting 23h 28m. The incident has been resolved; the full update timeline is below.

Started
Aug 26, 2025, 05:17 PM UTC
Resolved
Aug 27, 2025, 04:46 PM UTC
Duration
23h 28m
Detected by Pingoru
Aug 26, 2025, 05:17 PM 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 AWSAura Graph Analytics 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)

Update timeline

  1. investigating Aug 25, 2025, 01:34 PM UTC

    We are currently investigating this issue.

  2. investigating Aug 25, 2025, 01:36 PM UTC

    We are aware of an issue that could result in a degradation in write performance for all Aura instance. We have identified the cause and are preparing a fix.

  3. investigating Aug 25, 2025, 01:47 PM UTC

    We are continuing to investigate this issue.

  4. monitoring Aug 25, 2025, 03:34 PM UTC

    The issue impact has been refined and currently could impact AuraDB Virtual Dedicated Cloud and Business Critical instances only. We have identified the cause and the faulty component has been reverted for the majority of instances. We will continue to monitor the situation, while the full fix is prepared.

  5. monitoring Aug 25, 2025, 05:40 PM UTC

    We continue to work towards the issue resolution.

  6. monitoring Aug 25, 2025, 09:44 PM UTC

    We continue to work towards the issue resolution.

  7. monitoring Aug 26, 2025, 04:06 AM UTC

    We are continuing to investigate this issue.

  8. monitoring Aug 26, 2025, 10:53 AM UTC

    We are continuing to monitor the situation whilst a full fix for the solution is prepared.

  9. monitoring Aug 26, 2025, 02:48 PM UTC

    We are continuing to monitor the situation. The full fix for the solution is currently undergoing final testing and will start deployment once testing is completed.

  10. monitoring Aug 26, 2025, 05:17 PM UTC

    The full fix for the solution is starting to be deployed across the estate and are continuing to monitor the situation.

  11. monitoring Aug 26, 2025, 08:13 PM UTC

    The full fix for the solution is starting to be deployed across the estate and are continuing to monitor the situation.

  12. monitoring Aug 26, 2025, 11:12 PM UTC

    The full fix for the solution is starting to be deployed across the estate and are continuing to monitor the situation.

  13. monitoring Aug 27, 2025, 06:36 AM UTC

    We are continuing to monitor for any further issues.

  14. monitoring Aug 27, 2025, 11:16 AM UTC

    The full fix for the solution is continuing to be deployed across the estate and are continuing to monitor the situation.

  15. resolved Aug 27, 2025, 04:46 PM UTC

    The full fix for the solution has now been deployed across the estate and this issue is now resolved.

  16. postmortem Oct 06, 2025, 01:32 PM UTC

    ### **What happened** Between August 22 and August 28, 2025, a performance issue affected some of our database services following a recent update. Our team quickly responded and discovered that the problem was due to a bug in the latest update, which caused certain memory settings to be incorrectly configured. We promptly applied the previous version of those settings to stabilize the affected databases. By August 28, all databases were successfully transferred to a new, stable version, and the incident was fully resolved. The issue was caused by a misconfiguration in the system's data processing module. Specifically, an incorrect parameter setting in the data pipeline led to a bottleneck, which slowed down the processing speed. This misconfiguration affected the way data was being queued and processed, resulting in delays. Our technical team has identified the root cause and implemented a fix to ensure that the data pipeline operates efficiently, preventing future occurrences of this issue. ### **How the service was affected** Some customers reported a performance change on their instance. ### **What we are doing now** Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. New mitigations being deployed: * Enhancing our monitoring systems to detect similar issues faster * Implementing additional automated checks to prevent service disruptions * Improving our service resilience to handle similar scenarios * Introducing dynamic configuration management to ensure seamless updates * Enabling multiple configuration defaults to better manage database priorities * Improving notification systems for faster response to potential issues * Enhancing our tools to streamline database management and transfers