Resolved after 2 hours 5 minutes, affecting Aura Console (console.neo4j.io), on July 10, 2026.
## 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.
Affected components
Update timeline
- investigating Jul 10, 2026, 05:18 PM UTC
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.
- investigating Jul 10, 2026, 05:23 PM UTC
We are continuing to investigate this issue.
- monitoring Jul 10, 2026, 05:51 PM UTC
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.
- resolved Jul 10, 2026, 07:23 PM UTC
Services are confirmed to be operational and no further interruptions are expected.
- postmortem Jul 27, 2026, 04:28 AM UTC
## 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.
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.
Amazon Web Services