Is Neo4j Aura down?

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.

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.

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.

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.

We are continuing to investigate this issue.

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.

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

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

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.

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

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

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

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

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

We are continuing to investigate a fix for the issue

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

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

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

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

This incident has been resolved.

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