Aura Console Impacted - Instance View

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.