Neo4j Aura Status Page

Aug 5, 2026 · resolved Aug 7

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

Jul 23, 2026 · resolved Jul 24

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

Jul 10, 2026 · resolved Jul 10

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

Jun 30, 2026 · resolved Jun 30

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

Jun 23, 2026 · resolved Jun 24

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

Is Neo4j Aura down right now?

No — Neo4j Aura is up. All systems operational as of Aug 19, 9:40 PM UTC.

What is Neo4j Aura's current status?

Neo4j Aura: All Systems Operational. Alert24 checks Neo4j Aura's status page continuously and can notify you the moment it changes.

How do I get alerted when Neo4j Aura goes down?

Alert24 monitors Neo4j Aura and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.