Störungsverlauf von Neo4j Aura

1. 3. September 2026 um 16:43 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 4. September 2026 um 10:23 UTCidentified

   Das Problem wurde identifiziert, Instanzen bleiben verfügbar und Schritte zur Lösung für die betroffenen Instanzen werden derzeit überprüft.

3. 4. September 2026 um 15:36 UTCresolved

   Alle Instanzen sind verfügbar, manuelle Schritte zur Freigabe der verbleibenden kleinen Anzahl von Instanzen wurden unternommen, um sie zu lösen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. August 2026 um 15:49 UTCinvestigating

   Unser Team hat ein Problem mit dem Sammeln der Metriken für Aura-Instanzen identifiziert. Dies wirkt sich auf die metrische Sichtbarkeit und Weiterleitung aus. Wir untersuchen derzeit das Problem.

2. 20. August 2026 um 16:48 UTCinvestigating

   Wir untersuchen weiterhin das Problem der Aura-Metriken.

3. 20. August 2026 um 19:10 UTCresolved

   Seit dem letzten Update hat sich die Untersuchung weiterentwickelt. Das Problem wurde identifiziert und wir überwachten den Service, als er sich von der Verschlechterung erholte. Wir bestätigen, dass das Problem nun gelöst ist.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 5. August 2026 um 17:31 UTCinvestigating

   We have identified an issue currently that could result in unexpected query failures when using the trim() Cypher function. Investigations into the cause are in progress.

2. 5. August 2026 um 19:27 UTCidentified

   We have found the issue and are working on a fix. A small percentatge of queries using trim may still err. VDC customers with databases set to highest are not impacted at all unless they pause and start their instances.

3. 6. August 2026 um 00:58 UTCidentified

   We are testing the fix for the trim() Cypher function issue. We will update before we begin our deployment into the Aura environment.

4. 6. August 2026 um 07:13 UTCidentified

   We are actively validating the fix for the trim() Cypher function. Further updates will be provided before we begin deploying to Aura instances

5. 6. August 2026 um 11:17 UTCidentified

   We continue to validate the fix for the trim() Cypher function. Further updates will be provided before we begin deploying it to Aura instances.

6. 6. August 2026 um 14:54 UTCidentified

   The fix for the trim() Cypher function is undergoing testing and validation before deployment. Further updates will be provided before we begin deploying it to Aura instances.

7. 7. August 2026 um 01:15 UTCidentified

   Development has completed on the hot-fix for this issue, and we are finalizing the rollout plan for Aura.

8. 7. August 2026 um 01:16 UTCidentified

   We are actively working on addressing the issue. The fix for the trim() Cypher function is undergoing testing and validation currently before deployment. Further updates will be provided before we begin deploying it to Aura instances.

9. 7. August 2026 um 09:44 UTCidentified

   The fix to the trim() Cypher function has passed testing and validation and is now being deployed.

10. 7. August 2026 um 13:49 UTCmonitoring

    The fix to resolve the issue has now completed deployment to the Aura service and we are monitoring the situation.

11. 7. August 2026 um 15:34 UTCresolved

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

1. 23. Juli 2026 um 10:52 UTCinvestigating

   Wir untersuchen derzeit ein Problem.

2. 23. Juli 2026 um 11:08 UTCinvestigating

   Wir arbeiten mit Ingenieurteams zusammen und machen derzeit Fortschritte bei den Untersuchungen.

3. 23. Juli 2026 um 11:24 UTCinvestigating

   Wir arbeiten mit Ingenieurteams zusammen und machen die Untersuchungen derzeit weiter voran.

4. 23. Juli 2026 um 11:38 UTCidentified

   Wir haben die Ursache des aktuellen Problems identifiziert und arbeiten derzeit aktiv an der Lösung.

5. 23. Juli 2026 um 11:53 UTCidentified

   Wir setzen den ersten Teil des Fixes ein und arbeiten weiterhin aktiv an der Einführung der vollständigen Lösung. Wir erwarten eine ETA in der Größenordnung von 1 Stunde.

6. 23. Juli 2026 um 12:11 UTCidentified

   Wir haben die Teilmenge der betroffenen Instanzen identifiziert und setzen den Fix zu diesem Zeitpunkt weiterhin bereit.

7. 23. Juli 2026 um 12:32 UTCidentified

   Wir haben eine Konfigurationskorrektur bereitgestellt und arbeiten nun daran, die Teilmenge der betroffenen Instanzen zu beheben.

8. 23. Juli 2026 um 12:49 UTCidentified

   Mit dem bereitgestellten Konfigurationsfix werden wir die Teilmenge der noch betroffenen Instanzen weiter auflösen.

9. 23. Juli 2026 um 14:07 UTCidentified

   Wir werden weiterhin die Teilmenge der noch betroffenen Instanzen lösen.

10. 23. Juli 2026 um 14:27 UTCidentified

    Wir lösen weiterhin die Teilmenge der Instanzen, die immer noch betroffen sind.

11. 23. Juli 2026 um 14:44 UTCmonitoring

    Wir lösen weiterhin die Teilmenge der Instanzen, die immer noch betroffen sind.

12. 23. Juli 2026 um 15:03 UTCmonitoring

    AuraDB Virtual Dedicated Cloud und AuraDB Business Critical sollten nun alle behoben werden. Wir werden weiterhin die Teilmenge der Instanzen auflösen, die immer noch für AuraDB Professional und Free betroffen sind.

13. 23. Juli 2026 um 15:29 UTCmonitoring

    Wir werden weiterhin die Teilmenge der Instanzen auflösen, die immer noch für AuraDB Professional und Free betroffen sind.

14. 23. Juli 2026 um 15:57 UTCmonitoring

    Wir lösen weiterhin die Teilmenge der Instanzen, die immer noch für AuraDB Professional und Free betroffen sind.

15. 23. Juli 2026 um 16:32 UTCmonitoring

    Wir lösen weiterhin die Teilmenge der Instanzen, die immer noch für AuraDB Professional und Free betroffen sind

16. 23. Juli 2026 um 17:01 UTCmonitoring

    Wir beheben weiterhin eine Teilmenge von Instanzen, die immer noch für AuraDB Professional und Free betroffen sind

17. 23. Juli 2026 um 17:31 UTCmonitoring

    Wir werden weiterhin eine kleine Teilmenge von Instanzen beheben, die immer noch unter den AuraDB Professional und Free-Stufen betroffen sind.

18. 23. Juli 2026 um 18:07 UTCmonitoring

    Wir haben das Problem in allen AuraDB Professional Instanzen angesprochen. Aura Free kann immer noch betroffen sein. Wir werden die verbleibenden Datenbanken weiterhin überwachen und reparieren.

19. 23. Juli 2026 um 19:39 UTCmonitoring

    Wir beheben weiterhin eine kleine Untergruppe von freien Instanzen, die immer noch betroffen sind.

20. 24. Juli 2026 um 06:00 UTCmonitoring

    Wir verfolgen die Situation weiterhin aufmerksam auf weitere Fragen.

21. 24. Juli 2026 um 08:30 UTCmonitoring

    Wir werden weiterhin auf weitere Probleme achten.

22. 24. Juli 2026 um 12:59 UTCmonitoring

    Alle identifizierten Instanzen wurden behoben und werden weiterhin überwacht. Kontaktieren Sie den Kundensupport für weitere Probleme.

23. 24. Juli 2026 um 15:56 UTCresolved

    Alle Fixes wurden bereitgestellt und das Problem wird nun als behoben markiert.

24. 29. Juli 2026 um 21:58 UTCpostmortem

    ### **Was ist passiert ** Am Donnerstag, 23. Juli 2026 10:33 UTC wurde eine Konfigurationsänderung in Aura bereitgestellt, die unbeabsichtigt die Berechnung von Speicherzuweisungen für Datenbankinstanzen veränderte. Infolgedessen erhielt eine Teilmenge von Instanzen keinen ausreichenden Speicher, was dazu führte, dass einige Datenbankinstanzen nicht verfügbar waren oder keine Updates abschließen konnten. Die angepasste Speicherzuweisung führte zu Out-of-Memory-Bedingungen, was dazu führte, dass Datenbankinstanzen aufgrund unzureichender Speicherressourcen wiederholt neu gestartet oder aktualisiert wurden. Dieses Problem betraf Instanzen mehrerer Cloud-Anbieter und mehrerer Produktebenen. Sobald das Problem identifiziert wurde, haben wir die Konfigurationsänderung sofort rückgängig gemacht und verhindert, dass zusätzliche Instanzen die falsche Konfiguration erhalten haben. Eine korrigierte Konfiguration wurde bis Donnerstag, 23. Juli 2026 11:56 UTC in Produktion genommen. Datenbankinstanzen, die bereits die falsche Konfiguration erhalten hatten, erforderten jedoch individuelle Wiederherstellungsaktionen, bevor sie zum normalen Betrieb zurückkehren konnten. Bis Donnerstag, 23. Juli 2026 17:59 UTC waren alle bekannten kundenrelevanten Datenbankinstanzen wiederhergestellt worden. Die Überwachung wurde bis zum nächsten Tag fortgesetzt, wobei der Vorfall am Freitag, 24. Juli 2026 16:30 UTC, vollständig gelöst wurde. ### **Wie der Service betroffen war** Der primäre Einfluss des Kunden war, dass mehrere AuraDB-Datenbankinstanzen nicht verfügbar waren oder in einen degradierten Zustand gelangten. Betroffene Instanzen waren nicht in der Lage, routinemäßige Software-Updates abzuschließen und in einigen Fällen wiederholt neu zu starten, weil unzureichender Speicher zugewiesen wurde. * ** Serviceverfügbarkeit:** Kundenwirkung variiert je nach Servicestufe. AuraDB Professional-Instanzen, die keine hohe Verfügbarkeit bieten, erlebten die größte Störung des Dienstes, wobei eine Teilmenge nicht mehr verfügbar war und keine Lese- oder Schreibvorgänge verarbeiten konnte. Für betroffene AuraDB Business Critical- und Virtual Dedicated Cloud-Instanzen (VDC) beschränkten sich die Auswirkungen im Allgemeinen auf einen vorübergehenden Verlust der Fehlertoleranz, während die Serviceverfügbarkeit aufrechterhalten wurde. In einer kleineren Anzahl von Fällen wurden auch Business Critical- und VDC-Instanzen nicht verfügbar. *** Updates**: Zusätzliche Instanzen blieben verfügbar, blieben aber in einem "Aktualisierungszustand" stecken, der kundeninitiierte Operationen wie Größenänderungen oder Konfigurationsänderungen blockierte. * **Plattformübergreifender Umfang**: Die Auswirkungen erstreckten sich auf alle drei unterstützten Cloud-Anbieter und mehrere Regionen und betrafen Kunden weltweit. Kunden-Support-Fälle wurden angesprochen und unser Team triaged und manuell wiederhergestellt betroffenen Instanzen in der Reihenfolge der Priorität. Die meisten AuraDB-Instanzen arbeiteten weiterhin normal. Die Kundenauswirkungen wurden durch die Konfigurationsumstellung und gezielte manuelle Wiederherstellung jeder betroffenen Instanz vollständig gemindert. ### **Was wir jetzt tun** Wir haben eine gründliche Analyse dieses Vorfalls durchgeführt und die folgenden Maßnahmen identifiziert: ***Prävention** * **Verbesserte Bereitstellungsvalidierung:** Wir verstärken unseren Release-Validierungsprozess, um Konfigurationsänderungen besser zu erkennen. * **Entkopplung der Komponenten**: Wir prüfen Verbesserungen bei der Sequenzierung von Komponentenbereitstellungen, um das Risiko zu verringern, dass unbeabsichtigte Änderungen in Releases enthalten sind. * **Progressive Rollout-Strategie**: Wir überprüfen den Rollout-Prozess für die betroffenen Komponenten, um sie mit den Rollout-Kontrollen für andere kritische Komponenten in Einklang zu bringen. * **Erkennung** * ** Bessere Warnung**: Wir verbessern unsere Überwachung, um abnorme Anstiege der Ausfallraten (wie Verlust der Fehlertoleranz oder Verfügbarkeit) schneller und zuverlässiger zu erkennen. ***Abschwächung** * **Sichere Konfigurationsbereitstellung:** Wir verbessern, wie Änderungen der Produktionskonfiguration bereitgestellt werden, damit sie schneller deaktiviert oder zurückgesetzt werden können, ohne dass eine breitere Softwareversion erforderlich ist. * **Schnelleres manuelles Recovery Tooling**: Wir verbessern unser Recovery-Tooling, um die Zeit für die Identifizierung und manuelle Wiederherstellung betroffener Instanzen zu reduzieren. Wir erkennen die Störung an, die dieser Vorfall verursacht hat, und entschuldigen uns für die Auswirkungen auf die betroffenen Kunden. Wir haben die sofortigen Korrekturmaßnahmen abgeschlossen, und die oben beschriebenen längerfristigen Verbesserungen sind bereits im Gange, um die Wahrscheinlichkeit und die Auswirkungen ähnlicher Vorfälle in der Zukunft zu reduzieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. Juli 2026 um 17:18 UTCinvestigating

   Wir untersuchen derzeit ein Problem mit der Aura Console, bei dem einige Kunden ihre Instanzen möglicherweise nicht sehen können. Dieses Problem wird durch einen Fehler in einem Drittanbieter-Dienst verursacht, von dem Aura abhängt. Betroffene Instanzen laufen weiterhin normal und die Datenbankverbindung ist nicht betroffen. Unser Team untersucht das Problem aktiv.

2. 10. Juli 2026 um 17:23 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 10. Juli 2026 um 17:51 UTCmonitoring

   Der Drittanbieter-Service, von dem Aura abhängig ist, hat den normalen Betrieb wiederhergestellt und die Neo4j-Aura-Systeme haben sich wiederhergestellt. Unser Team überwacht das Problem aktiv, um zu bestätigen, dass die Aura Console wie erwartet funktioniert.

4. 10. Juli 2026 um 19:23 UTCresolved

   Die Dienste werden als funktionsfähig bestätigt und es werden keine weiteren Unterbrechungen erwartet.

5. 27. Juli 2026 um 04:28 UTCpostmortem

   ## Was geschah Aura Console und andere Aura-Komponenten erlebten Störungen am 2026-07-10 um 16:14 UTC, was zu Ausfällen und Crashloops führte. Folglich sah sich ein Segment von Kunden mit Sichtbarkeitsproblemen in Bezug auf ihre Instanzen konfrontiert. Es wurde durch einen Ausfall in einem mit Aura integrierten externen Drittanbieterdienst verursacht. Entscheidend ist, dass die Datenbankverbindung kompromisslos blieb und die betroffenen Instanzen ihren normalen Betrieb fortsetzten. LaunchDarkly-Service wurde wiederhergestellt, um das Problem zu beheben ## Wie der Service beeinflusst wurde Mehrere Aura-Komponenten, einschließlich der Aura Console, erlebten Störungen. Benutzer stießen auf HTTP 500-Fehler auf datenbankbezogenen Seiten und Operationen, obwohl Organisationen und Projekte weiterhin aufgerufen werden konnten. Direkte Verbindungen zu bestimmten Datenbankinstanzen waren völlig unberührt Die Steuerungsebene wurde nicht verfügbar, was bedeutete, dass Benutzer Einstellungen für Instanzen über die API oder die Aura-Konsole nicht erstellen, löschen, ändern oder anpassen konnten. Bestehende Instanzen blieben jedoch funktionsfähig. Das Problem wurde durch einen Ausfall bei LaunchDarkly verursacht und unsere Dienste haben diesen Abhängigkeitsfehler während des Starts nicht anmutig behandelt. Alle betroffenen Systeme kehrten bis 2026-07-10 um 17:07 UTC zum Normalbetrieb zurück ## Was wir jetzt tun Das Neo4j Engineering Team diagnostizierte schnell die Ursache und stellte den Service wieder her. Bei der Bewertung dieses Vorfalls haben wir Schlüsselbereiche identifiziert, um zukünftige Lösungen zu beschleunigen und Rezidivrisiken zu mindern: * Analysierte Key-Incident-Metriken, die sich auf die Alarm-to-Response-Dauer konzentrieren, um Möglichkeiten zur Beschleunigung der Reaktionseffizienz zu identifizieren * Durchführung einer umfassenden Retrospektive, die erfolgreiche Ergebnisse hervorhebt, einschließlich einer schnellen Ursachenanalyse durch transparente Protokollierung, nahtloser Ausrichtung durch das Incident Management Tool und der belastbaren, anmutigen Degradation mehrerer Komponenten, die die Konnektivität der Datenebene intakt hielten * Aktive Entwicklung anmutigerer Fallback-Standards für Feature-Flags zur Sicherung des Kernbetriebs während der Ausfallzeiten des Anbieters * Stärkung der architektonischen Resilienz durch Integration von fortschrittlicher Planung, Chaos Engineering-Praktiken und Fehlerinjektionstests auf Produktionsebene, um mögliche Fehlerpfade präventiv aufzudecken und zu mindern * Adressierte Logikbeschränkungen beim Flag-Caching von Operator-Features, wobei die Notwendigkeit betont wird, dass Operator ausgewertete Flags lokal speichern müssen, um die Betriebskontinuität zu erhalten, wenn externe Abhängigkeiten ausfallen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 30. Juni 2026 um 14:45 UTCidentified

   CREATE VECTOR INDEX fehlschlägt mit Fehler 51N31 Fehler: Systemkonfiguration oder Betriebsausnahme - nicht unterstützt. Das Erstellen eines Vektorindex mit bereitgestellten Einstellungen wird in V2026 02 nicht unterstützt. Die für den Betrieb erforderliche Version ist V2026 06. Bitte aktualisieren Sie DBMS.. Dies betrifft nur den neuen Index, der bestehende VECTOR INDEX ist nicht betroffen. Jeder Vektorindex, der vor 2026-06-30 um 09:00 Uhr erstellt wurde, funktioniert weiterhin normal.

2. 30. Juni 2026 um 15:41 UTCidentified

   Wir beginnen jetzt, einen Fix zu implementieren, um dieses Problem zu beheben, und werden bald ein Update über den Fortschritt bereitstellen.

3. 30. Juni 2026 um 16:05 UTCmonitoring

   Ein Fix wird eingeführt und schreitet gut voran. Wir werden mit dem Fortschritt aktualisieren.

4. 30. Juni 2026 um 17:45 UTCresolved

   Der Fix wurde vollständig für alle betroffenen Instanzen bereitgestellt. Dieser Vorfall ist nun gelöst.

5. 20. Juli 2026 um 08:40 UTCpostmortem

   ## Was geschah Ein Problem wurde nach der Bereitstellung von Version 2026.06 am 2026-06-30 um 08:00 UTC identifiziert, bei der das Ausführen von "CREATE VECTOR INDEX" auf aktualisierten Aura-Instanzen eine Systemausnahme auslöste. Dieser Fehler bei der Indexgenerierung trat auf, weil der zugrunde liegende Speicher und Kernel zusätzliche Updates benötigten, um den Betrieb zu unterstützen. Dieses Problem wirkte sich nur auf die Schaffung neuer Indizes aus; bestehende Vektorindizes sind nicht betroffen. Jeder Vektorindex, der vor 09:00 Uhr am 2026-06-30 erstellt wurde, war nicht betroffen und arbeitete weiterhin normal. ## Wie der Service beeinflusst wurde Nach dem Rollout der Version 2026.06 ist die Ausführung der CREATE VECTOR INDEX-Anweisung fehlgeschlagen, was sich auf Anwendungen auswirkte, die auf das Hinzufügen neuer Vektorindizes angewiesen waren. Betroffene Clients haben den Fehler erhalten: Das Erstellen eines Vektorindex mit bereitgestellten Einstellungen wird in V2026\ 02 nicht unterstützt. Die erforderliche Version für den Betrieb ist V2026\ 06. Bitte aktualisieren Sie DBMS . Bestehende Indizes \(erstellt vor diesem Vorfall\) und andere Abfragen blieben völlig unberührt und voll funktionsfähig. ## Was wir jetzt tun Neo4j-Teams identifizierten die Ursache als Fehler im Cypher-Planer und lösten das Problem mit einem Code-Fix. Dieser Fix wurde für alle betroffenen Aura-Instanzen bereitgestellt und löst den Fehler vollständig Um zukünftige Ereignisse zu verhindern, verbessern wir unsere Überwachungs- und Warnsysteme, um ähnliche Probleme früher zu erkennen, insbesondere in Staging-Umgebungen, bevor Rollouts auftreten. Gleichzeitig verfeinern wir unsere Bereitstellungsprozesse, um die Auswirkungen auf die Kunden und die Wiederherstellungszeiten zu minimieren. Darüber hinaus untersuchen wir Optionen zur Implementierung automatisierter, post-upgrade-Validierungstests speziell für kritische Operationen wie die Erstellung von Vektorindexen

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Juni 2026 um 11:25 UTCidentified

   Die Aura-Konsole hat einige intermittierende Fehler: „Unser System hat derzeit Probleme. Versuchen Sie es später erneut oder kontaktieren Sie den Support, wenn das Problem weiterhin besteht. Dies kann erfordern, dass Sie neu laden oder länger warten, bis Sie in der Konsole navigieren Operationen und die Aura API bleiben unberührt Wir arbeiten aktiv an einem Fix

2. 23. Juni 2026 um 13:03 UTCidentified

   Wir untersuchen weiterhin eine Lösung für das Problem

3. 23. Juni 2026 um 13:39 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

4. 23. Juni 2026 um 15:43 UTCmonitoring

   Wir setzen eine Veränderung ein. Wir werden überwachen und aktualisieren.

5. 23. Juni 2026 um 19:27 UTCmonitoring

   Weitere Überwachung der eingesetzten Änderungen. Nächstes Update erwartet 6/24/2026 10am UTC.

6. 24. Juni 2026 um 09:14 UTCmonitoring

   Wir haben überprüft und bestätigt, dass das Problem nun vollständig angegangen ist.

7. 24. Juni 2026 um 09:14 UTCresolved

   Dieser Vorfall wurde behoben.

8. 10. Juli 2026 um 14:50 UTCpostmortem

   ## Was geschah Um ungefähr 12:00 Uhr UTC am 22. Januar 2026 stießen die Benutzer auf intermittierende Fehlerbanner in der Aura-Konsole, die anzeigen: Wir haben ein Problem. Try again., das neben 500 Fehlern von Konsolen-API-Endpunkten aufgetreten ist. Diese Störungen waren vorübergehend und wurden durch internes API-Timing während des TLS-Handshake-Prozesses verursacht, die typischerweise innerhalb von etwa 10 Sekunden oder nach einer Aktualisierung der Seite aufgelöst wurden. ## Wie der Service beeinflusst wurde Die Aura-Konsole und die Aura-API erlebten eine verschlechterte Leistung, die sich als intermittierende Fehlerbanner innerhalb der Aura-Konsole-Benutzeroberfläche manifestierte. Eine Untersuchung identifizierte die Ursache als hohe CPU-Auslastung und Drosselung innerhalb der Konsolen-API. Dieses Problem wurde in erster Linie durch wiederholte große Entity-Listings und teure Consalizer-Anfragen verursacht Um das Problem zu beheben, wurden gezielte Korrekturen erfolgreich sowohl für die Aura-Konsole als auch für die Aura-API bereitgestellt. Es folgten Anpassungen an der Ressourcenkonfiguration, um den operativen Headroom zu erhöhen und Stabilität zu gewährleisten. ## Was wir jetzt tun Folgende reaktive und proaktive Maßnahmen wurden umgesetzt, um die Wahrscheinlichkeit ähnlicher Vorfälle zu verringern: * Entwickelt ein Monitoring-Dashboard, um Request Drops basierend auf internen API-Logdaten zu beobachten, um automatisierte Überwachung und Alarmierung zu implementieren, um Probleme zu erkennen, bevor sie auftreten * Implementierte eine gestaffelte Verzögerung zwischen paginierten Consalcer-Anforderungen, um den hohen Ressourcenverbrauch zu verringern und die API-Stabilität zu verbessern * Verbesserte infrastrukturbewusste Ressourcenberechnungen zur Verbesserung der Leistung * Einführung eines neuen Filters für Abfragen basierend auf Service-Tiers zur Optimierung des CPU-Overheads für jeden Anruf, der vom Consalizer ausgeführt wird * Deaktivierte redundante Anfrage-Middleware-Verarbeitung zur Optimierung von API-Aufrufen

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. Mai 2026 um 18:23 UTCinvestigating

   Aura Console is currently not accessible. Our team is investigating the issue. Aura instances are running normally and are not impacted. They remain accessible via https://browser.neo4j.io/ and https://bloom.neo4j.io/ Console-related administration and configuration procedures may be unavailable. We will provide updates as soon as more information is available.

2. 26. Mai 2026 um 19:19 UTCmonitoring

   The Aura Console issue has now been resolved. The root cause was a failure while fetching public certificates from Auth0. We are reaching out to the Auth0 team to gather more detailed information about the incident.

3. 26. Mai 2026 um 23:06 UTCresolved

   This incident has been resolved.

4. 9. Juni 2026 um 16:50 UTCpostmortem

   **What Happened** During the incident window, users attempting to log in to the Aura Console were unable to do so. Auth0, the authentication provider for Aura Console, experienced an issue that prevented new authentication requests from completing. Existing sessions with valid cached tokens were largely unaffected. Aura database instances were running normally throughout and were not impacted, and access via the Aura API to database instances was also unaffected. **How the service was affected** Authentication requests from the Aura Console to Auth0 began failing, preventing new logins and session refreshes. Affected users received 503 errors when accessing the Aura Console. Once Auth0 recovered, access was restored. **What are we doing now** We've made two changes as a result of this incident: * Client identification: Authentication requests now include a clearer client identifier, reducing the chance of requests being incorrectly blocked in the future. * Observability: We've improved logging and alerting for authentication failures, including better visibility into errors from external services,so we can detect and escalate issues like this faster.

1. 6. März 2026 um 10:18 UTCidentified

   We identified an issue with the availability of console.neo4j.io - we are investigating

2. 6. März 2026 um 10:24 UTCmonitoring

   We have made a code change and we believe the console is available again.

3. 6. März 2026 um 10:25 UTCresolved

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

4. 30. März 2026 um 07:25 UTCpostmortem

   ## What Happened On March 6, at 10:04 AM UTC,  the Aura Console became inaccessible following a recent deployment. The deployment included changes related to user organizations and switching to an org memberships entity. This change caused the console to become inaccessible for a short period. ## How the service was affected A deployment to the Aura Console introduced an issue that caused an unexpected increase in backend requests related to access validation. This led to elevated CPU usage, which impacted the availability of the console and dependent services. We rolled back to a previous version to restore access. The rollback ensured the full restoration of access to the Aura Console, resolving the core issue within the incident window ## What are we doing now We are currently implementing a comprehensive strategy to bolster system resilience and prevent future recurrence. Our immediate actions include integrating stricter and more robust safeguards into the deployment pipeline. Crucially, we are significantly enhancing our validation processes to proactively detect and flag any potential performance impacts _before_ code is promoted to the production environment

1. 3. März 2026 um 21:35 UTCidentified

   A recent update resulted in MERGE queries which referenced the same merged property on both the left and right hand side of an ON MATCH SET or ON CREATE SET clause deleting that property from the node, or setting it to an invalid value during query runtime. The node being matched against must have had at least one property uniqueness constraint present. A fix has been identified and will be applied as soon as possible. Instances marked as "Production" are not impacted.

2. 4. März 2026 um 01:39 UTCidentified

   The fix is being deployed and the status page will be updated upon completion of the full deployment of the fix.

3. 4. März 2026 um 04:52 UTCidentified

   The fix is being deployed and the status page will be updated upon completion of the full deployment

4. 4. März 2026 um 14:07 UTCmonitoring

   The fix has now been deployed to those instances impacted and we are monitoring the situation.

5. 4. März 2026 um 15:19 UTCresolved

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

6. 8. April 2026 um 06:39 UTCpostmortem

   ## What Happened An issue was introduced in the Neo4j 2026.02 release where MERGE queries that referenced the same property on both the left and right sides of an `ON MATCH SET` or `ON CREATE SET` clause could potentially delete that property from the node or set it to an invalid value during query execution. This behaviour was observed specifically when the node being matched had at least one property uniqueness constraint. ## How the service was affected A change in the Neo4j 2026.02 release introduced a potential risk of writes failing or invalid data being returned for queries using MERGE together with `ON MATCH`. This issue affected instances across Aura tiers and required immediate investigation by Neo4j Engineering. The team identified the root cause and deployed a fix in version 2026.02.1. ## What are we doing now The following proactive measures have been implemented to reduce the likelihood of similar incidents: * We have strengthened test coverage for `ON CREATE` and `ON MATCH` clauses, particularly those involving more complex expressions. * We are investigating additional safeguards to improve our ability to control MergeInto/MergeUnique behaviour more flexibly, as well as potential rollback capabilities to support recovery in future incidents

1. 2. März 2026 um 19:55 UTCidentified

   We are aware of issues in the Middle East regions via our cloud partner AWS, affecting AWS me-central-1 (United Arab Emirates) and AWS me-south-1 (Bahrain). The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We are actively working to limit the impact on the Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels. Our team is available to advise and assist as needed.

2. 3. März 2026 um 15:26 UTCidentified

   We continue to monitor the situation in the affected AWS Middle East regions. The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as soon as more information becomes available.

3. 6. März 2026 um 14:29 UTCidentified

   We continue to monitor the situation in the affected AWS Middle East regions. The latest information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as more information becomes available. Please review the AWS recommendation on the website above.

4. 6. März 2026 um 16:06 UTCresolved

   While AWS continues working on this situation, we are closing this incident and invite our customers to monitor the AWS Status on our main Neo4j Status Page under AWS (Amazon Web Services). The latest information from AWS can be found at: https://health.aws.amazon.com/health/status

5. 29. März 2026 um 15:16 UTCpostmortem

   ## What Happened On March 1, at 12:51 PM UTC, AWS services in the ME-CENTRAL-1 & ME-SOUTH-1 Region were impacted. Connectivity and power issues affected APIs and AWS core services essential to run Neo4j Aura prompting AWS to initiate an investigation ## How the service was affected Operations \(clone, backup, resuming/pausing, resizing\) that require additional resources like EC2 Instances, EBS Volumes, and other resources were impaired in the ME-CENTRAL-1 and ME-SOUTH-1 Region. Other AWS Services also experienced error rates and latencies for some workflows. Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure. A detailed summary of the AWS regional incident can be found here:[ https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status) ## What are we doing now We are actively working to limit the impact on the Neo4j Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels Please visit AWS Status page for more info:[https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status)

1. 26. Januar 2026 um 19:26 UTCidentified

   Wir haben ein Problem identifiziert, das eine begrenzte Anzahl von Cypher 25-Abfragen für AuraDB Free, Professional und AuraDS betreffen kann. Dies kann Folgendes betreffen: Abfragen, die die bedingte Abfrage verwenden, WANN in Kombination mit einer nicht gruppierenden Aggregation über Nullwerte zu einer falschen Anzahl zurückgegebener Zeilen führen. Abfragen mit NEXT können in einigen Fällen eine unerwartete Variable erzeugen, die keinen Fehler definiert. Wir arbeiten aktiv an einem Fix und werden diese Seite aktualisieren, sobald weitere Informationen verfügbar sind.

2. 27. Januar 2026 um 01:37 UTCidentified

   Wir haben eine Lösung für dieses Problem gefunden und werden in Aura eingeführt. Sobald das Update bereitgestellt wurde, aktualisieren wir diese Tatus-Seite.

3. 27. Januar 2026 um 09:50 UTCidentified

   Wir führen den Fix aus und werden Sie aktualisieren, wenn dies abgeschlossen ist.

4. 27. Januar 2026 um 11:10 UTCmonitoring

   Der Fix ist auf die betroffenen Komponenten ausgerollt, wir überwachen jetzt die Situation zu diesem Zeitpunkt.

5. 27. Januar 2026 um 14:51 UTCmonitoring

   Wir beobachten die Situation derzeit weiter.

6. 27. Januar 2026 um 15:58 UTCresolved

   Der Fix wurde vollständig für alle betroffenen Instanzen bereitgestellt. Dieser Vorfall ist nun gelöst.

7. 2. Juli 2026 um 04:22 UTCpostmortem

   ## **Was geschah ** Neo4j begann die Bereitstellung der Version 2026.01.1 für Aura-freie Instanzen um 07:49 Uhr UTC am 26. Januar 2026. Nach der Erkennung von Abfragefehlern während interner Tests wurde der Rollout gestoppt, bevor er die höheren Ebenen von Aura erreichte. Die Fehler traten bei bedingten Abfragen \(z.B. WANN ... DANN ...\) nach der Planerphase auf, sich bei einer Aggregation über Nullwerte anders zu verhalten. Wir haben die Ursache identifiziert und eine Auflösung entwickelt, die in Version 2026.01.2 integriert wurde. Am 27. Januar 2026 haben wir mit der Bereitstellung von 2026.01.2 in Aura-Instanzen begonnen und alle betroffenen Umgebungen erfolgreich auf die korrigierte Version aktualisiert. ## Wie der Service beeinflusst wurde Abfragen mit WHEN in 2026.01.1 in Kombination mit Aggregation über Nullwerte erhalten eine falsche Anzahl von Zeilen zurückgegeben. Abfragen, die NEXT verwenden, können in einigen Fällen einen unerwarteten Variablenfehler erzeugen, der nicht definiert ist. Dies führte dazu, dass sich die neu geschriebene Abfrage im Falle einer Aggregation über Nullwerte unterschiedlich verhält. Die bedingte Abfrage müsste eingehende Zeilen mit Nullwerten empfangen und über die Werte aggregiert werden, ohne eine Gruppierung zu verwenden. Kunden erhielten ein falsches Ergebnis, wenn sie das bedingte Abfragekonstrukt in Cypher 25 verwendeten (siehe [https://neo4j.com/docs/aura/managing-instances/cypher-version/](https://neo4j.com/docs/aura/managing-instances/cypher-version/]\), eine Auswirkung, die auf eine begrenzte Anzahl von Aura-Instanzen beschränkt war. ## Was wir jetzt tun Wir haben unsere Testverfahren verbessert, um eine umfassende Abdeckung in allen Produktbereichen zu gewährleisten. Dazu gehört die Entwicklung neuer Testfälle, die sowohl identifizierte Probleme als auch mögliche Zukunftsszenarien betreffen. Darüber hinaus haben wir Cypher-Abfragetests in Aura als Standardkomponente unserer Regressionstest-Suite integriert. Diese Überprüfungen sind nun obligatorische Phasen innerhalb unserer Continuous Integration-Pipeline und Staging-Umgebungen vor jeder Produktionseinführung.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Januar 2026 um 14:25 UTCidentified

   Impact is that currently it is not possible to load data into GDS via native projection. Customers using Aura Graph Analytics are not impacted. We have identified a packaging issue with the latest release of Aura. Our engineering team is working on a fix.

2. 16. Januar 2026 um 15:13 UTCidentified

   Our teams have a fix and initiated the work to get it ready to roll-out. No current ETA available. We will keep you updated soon.

3. 16. Januar 2026 um 17:07 UTCmonitoring

   The fix is currently rolling out to production. We will update you upon completion

4. 16. Januar 2026 um 19:36 UTCresolved

   All instances should have the fix applied and if not it should be in the next 60 minutes

5. 23. April 2026 um 13:27 UTCpostmortem

   ### **What happened** On January 15, 2026 at 22:12 UTC we began rolling out an update that included an incompatible version of a key component, affecting customers using the GDS plugin. This issue was reported on January 16 at 12:59 UTC, and a fix was deployed within hours, restoring functionality for the majority of affected users by 20:03 UTC.  The issue occurred because Neo4’s packaging automation process selected the wrong version of the GDS component. GDS 2.25 should have been selected but instead GDS 2.24 was included in the bundle, which caused a compatibility issue. Although a corrected package was created and labeled separately, the release pipeline selected the incorrect package for deployment.  This issue highlighted a gap in the release validation process, where incompatible component versions were not detected before rollout. ### **How customers were affected** Customers using the GDS plugin were unable to use any of the functionality the plugin provides during the incident window.  The system configuration has been updated to ensure compatibility with the intended component versions, restoring full functionality. ### **What we are doing now** The following mitigations have been implemented:  * Enhanced testing procedures to automatically verify compatibility between Neo4j and all bundled components before release. * Improved release processes to ensure that only explicitly validated and correctly labeled packages can be selected for deployment.

1. 26. November 2025 um 15:47 UTCidentified

   Neo4j opened a ticket with Azure and is awaiting updates on their resolution of the Azure Infrastructure issues. Impact on Neo4j Aura Services: Create, Resize (CPU and Storage), Pause, Resume.

2. 26. November 2025 um 20:33 UTCidentified

   Neo4j continues working with Microsoft via an Azure cloud ticket and is awaiting updates on their resolution of the Azure Infrastructure issues. Some resources have been made available, and impacted Neo4j Services have resumed operation. Customers have been notified. The Neo4j Aura Service is impacted when performing the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j operations, the operation will fail, and the Neo4j instance will become unavailable until Azure is able to provision additional resources.

3. 27. November 2025 um 14:33 UTCidentified

   The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance will become unavailable until Azure is able to provision additional resources.

4. 27. November 2025 um 17:07 UTCidentified

   The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Clone, Resume. As Azure resources become available when performing some Aura operations, the impacted instances may progressively recover and operations successfully complete. We continue to monitor progress, work with Microsoft Azure Infrastructure issues and will update.

5. 28. November 2025 um 00:09 UTCidentified

   We continue to work with our cloud infrastructure provider . Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

6. 28. November 2025 um 10:55 UTCidentified

   We continue to work with our cloud infrastructure provider. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

7. 28. November 2025 um 16:23 UTCidentified

   We continue to work with Microsoft Azure. No expected improvements in addressing the issues around cloud resources in the affected regions before next week. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume. We will resume updates after this weekend or earlier if we have more information.

8. 1. Dezember 2025 um 09:54 UTCidentified

   The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance may become unavailable or degraded until Azure is able to provision additional resources.

9. 5. Dezember 2025 um 10:20 UTCidentified

   The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, affecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance may become unavailable or degraded until Azure is able to provision additional resources.

10. 5. Dezember 2025 um 16:59 UTCidentified

    The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region. We are working with our cloud partner and will resume updates once we have an ETA to share.

11. 11. Dezember 2025 um 10:24 UTCmonitoring

    Cloud resources have become available in USEAST2 and we will monitor for a few hours to ensure there is no further customer impact.

12. 11. Dezember 2025 um 15:39 UTCresolved

    Cloud resources have become available in USEAST2 and no further customer impact has been detected. This incident is resolved.

13. 4. Februar 2026 um 15:18 UTCpostmortem

    ### **What Happened** Starting at 13:26 UTC on November 24th Microsoft Azure region eastus experienced a stock out situation, which impacted operations for all tiers of Neo4j Aura in that specific region. Additional capacity was requested straight away, but not until 17:06 UTC on December 10th did enough additional resources become available to resume all normal operations. **How the service was affected** All tiers within the Neo4j Aura Service were impacted when performing the following operations during this incident: Create, Resize \(CPU and Storage\), Clone, Pause and Resume. If Microsoft Azure resources were unavailable when requesting these types of Neo4j operations, the operation would fail, and the Neo4j instance would become unavailable until Azure was able to provision additional resources.  ### **What are we doing now** To mitigate the scope of impact of future regional stock out issues, Neo4j is implementing the following measures: * Closely monitoring resource capacity to improve stockout predictions. * Regular calls with with our Cloud Service Provider to: * Learn about where regional resource capacity restrictions are forecast. * Plan for more resources in restricted regions. * Investigating other deployment models to allow us to keep Aura running in situations where 3 Availability Zones are not available.

1. 18. November 2025 um 15:56 UTCidentified

   We have identified an issue resulting in Pause, Resume and Delete operations to fail in both Console and Aura API across all tiers of Aura. We are actively working to resolve the issue and will report progress.

2. 18. November 2025 um 16:16 UTCmonitoring

   We have released a fix to this issue and are monitoring to ensure all operations are back to normal.

3. 18. November 2025 um 16:39 UTCresolved

   After monitoring the fix for some time, we can confirm that the issue is resolved and normal operations have resumed.

4. 14. Januar 2026 um 14:05 UTCpostmortem

   ### What happened On November 18, 2025, some customers experienced issues with the delete, pause, and resume operations in the Console. These actions failed due to a temporary system issue introduced during a sequence of updates. While the updates were intended to improve functionality, they unintentionally reintroduced a previously resolved defect. The issue was identified quickly, and our teams acted immediately to restore normal operation. The root cause was a misconfiguration in the data processing module. An outdated schema caused the data parsing logic to misinterpret certain input parameters, leading to incorrect behavior and data display within the Console. We have since corrected the schema and added stricter validation to ensure compatibility moving forward. ### How customers were affected During the incident, some users experienced service disruptions when accessing the Console. Impacts included: * Intermittent connectivity issues * Inability to log in * Temporary unavailability of specific Console features No customer data was lost. To prevent a recurrence, we have improved our release process to ensure updates are deployed in the correct order, eliminating overlapping or out-of-sequence changes. ### What we are doing now Neo4j takes service reliability seriously and is strengthening safeguards to prevent similar incidents. New mitigations being deployed include: * Enhanced monitoring to detect related issues earlier * Additional automated checks to block faulty configurations before deployment * Improvements to overall service resilience to better tolerate similar failures We apologize for the disruption and appreciate our customers’ patience as we continue to harden our systems.

1. 20. Oktober 2025 um 16:43 UTCidentified

   Many core operations for instances in AWS region us-east-1 are degraded as a result of AWS incident in that region: https://health.aws.amazon.com/health/status Core operations include create, pause, resume, clone, backup, among others. We continue to monitor the AWS incident and will provide updates accordingly.

2. 20. Oktober 2025 um 19:14 UTCidentified

   We are continuing to monitor the AWS incident, and can report some slow improvement of impacted Aura instances in the AWS us-east1 region, though the service remains degraded in this region at this time. We are continuing to monitor progress in the AWS incident: https://health.aws.amazon.com/health/status

3. 20. Oktober 2025 um 21:28 UTCresolved

   Instance operations in AWS us-east-1 region are back to normal following the resolution of the AWS incident. We will continue to monitor but all data indicates that the issue is fully resolved at this time.

4. 15. Januar 2026 um 17:48 UTCpostmortem

   ### **What Happened** Between 08:41 UTC on October 20th and 09:00 UTC on October 21st, Neo4j Aura experienced service disruptions affecting the us-east-1 \(N. Virginia\) region in AWS. The incident was triggered by a broad AWS regional outage impacting Identity and Access Management \(IAM\) and the EC2 control plane. This resulted in delayed backups, temporary loss of database fault tolerance for a subset of users, and internal delays in administrative actions due to toolchain failures. A detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/) ### **How the service was affected** The primary cause was several AWS regional service disruptions in us-east-1. We will cover how each of these affected Neo4j Aura and its users. Neo4j Aura is designed to isolate regional failures. This is achieved through deploying customer instances in Orchestras that have instances in three availability zones and no cross region dependencies. AWS IAM and Identity Center became unresponsive, preventing Neo4j Aura’s automated systems from authenticating with AWS resources in us-east-1. This affected Neo4j Aura backups to be written to AWS S3 buckets. Customers were also not able to resume paused instances during this period as the resume process was not able to authenticate with AWS S3 buckets to retrieve the paused data set. Neo4j Aura’s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. AWS Network Load Balancer health check system failures and AWS EC2 “request limit exceeded” or “insufficient capacity” errors in us-east-1 were false negatives with the NLB heath checks which resulted in some Neo4j Aura DB clusters in us-east-1 losing fault tolerance \(1 out of 3 cluster members unavailable\). When this happened instances were removed by kubernetes and we were not able to provision new ones due to the EC2 failures noted earlier, leaving the clusters without fault tolerance for a prolonged period of time. All of these clusters still had full availability of the other two cluster members. ### **What are we doing now** Largely Neo4j Aura responded as designed to these events, isolating failures to us-east-1, with no to minimal cross system failure propagation. The cross cloud impact of creating DNS records for new instances was the main outlier.  To mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures: * Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies.  * Remove identified cross-region dependencies.

1. 20. Oktober 2025 um 09:15 UTCidentified

   An active issue on AWS us-east-1 is affecting Neo4j Aura operations in the regions where we have some dependency on an impacted AWS service. See more details https://health.aws.amazon.com/health/status Other regions not currently impacted.

2. 20. Oktober 2025 um 09:39 UTCidentified

   Operations such as Create, Pause, Resume, Clone are affected globally due to a dependency. Backups in the affected region of AWS us-est-1 will be impacted The affected AWS service is now starting to recover and we are monitoring the situation

3. 20. Oktober 2025 um 09:58 UTCmonitoring

   We see clear signs of recovery and our impacted service are progressively getting back to normal. We will monitor and update when we can confirm full recovery and normal operations.

4. 20. Oktober 2025 um 10:32 UTCmonitoring

   We are continuing to see good recovery across the service. We will update when this is completed.

5. 20. Oktober 2025 um 11:13 UTCresolved

   The underlying AWS incident has bene resolved and our services have now resumed and fully recovered

6. 15. Januar 2026 um 17:34 UTCpostmortem

   ### **What Happened** Between 08:41 UTC on October 20th and 09:00 UTC on October 21st, Neo4j Aura experienced service disruptions affecting the us-east-1 \(N. Virginia\) region in AWS. The incident was triggered by a broad AWS regional outage impacting Identity and Access Management \(IAM\) and the EC2 control plane. This resulted in delayed backups, temporary loss of database fault tolerance for a subset of users, and internal delays in administrative actions due to toolchain failures. A detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/) ### **How the service was affected** The primary cause was several AWS regional service disruptions in us-east-1. We will cover how each of these affected Neo4j Aura and its users. Neo4j Aura is designed to isolate regional failures. This is achieved through deploying customer instances in Orchestras that have instances in three availability zones and no cross region dependencies. AWS IAM and Identity Center became unresponsive, preventing Neo4j Aura’s automated systems from authenticating with AWS resources in us-east-1. This affected Neo4j Aura backups to be written to AWS S3 buckets. Customers were also not able to resume paused instances during this period as the resume process was not able to authenticate with AWS S3 buckets to retrieve the paused data set. Neo4j Aura’s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. AWS Network Load Balancer health check system failures and AWS EC2 “request limit exceeded” or “insufficient capacity” errors in us-east-1 were false negatives with the NLB heath checks which resulted in some Neo4j Aura DB clusters in us-east-1 losing fault tolerance \(1 out of 3 cluster members unavailable\). When this happened instances were removed by kubernetes and we were not able to provision new ones due to the EC2 failures noted earlier, leaving the clusters without fault tolerance for a prolonged period of time. All of these clusters still had full availability of the other two cluster members. ### **What are we doing now** Largely Neo4j Aura responded as designed to these events, isolating failures to us-east-1, with no to minimal cross system failure propagation. The cross cloud impact of creating DNS records for new instances was the main outlier.  To mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures: * Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies.  * Remove identified cross-region dependencies.

1. 25. August 2025 um 13:34 UTCinvestigating

   We are currently investigating this issue.

2. 25. August 2025 um 13:36 UTCinvestigating

   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. 25. August 2025 um 13:47 UTCinvestigating

   We are continuing to investigate this issue.

4. 25. August 2025 um 15:34 UTCmonitoring

   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. 25. August 2025 um 21:44 UTCmonitoring

   We continue to work towards the issue resolution.

6. 26. August 2025 um 04:06 UTCmonitoring

   We are continuing to investigate this issue.

7. 26. August 2025 um 10:53 UTCmonitoring

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

8. 26. August 2025 um 14:48 UTCmonitoring

   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.

9. 26. August 2025 um 23:12 UTCmonitoring

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

10. 27. August 2025 um 06:36 UTCmonitoring

    We are continuing to monitor for any further issues.

11. 27. August 2025 um 11:16 UTCmonitoring

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

12. 27. August 2025 um 16:46 UTCresolved

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

13. 6. Oktober 2025 um 13:32 UTCpostmortem

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

1. 22. August 2025 um 11:02 UTCinvestigating

   Engineers are investigating an issue whereby instance actions are not working. You may be unable to import data, pause, resume, create, delete or run manual backups for your instances. Regular Neo4j scheduled backups are continuing to run as normal. You may be unable to see your instances in the Aura Console. CMI is also experiencing an outage, you may be unable to ingest metrics from your Aura instances.

2. 22. August 2025 um 11:42 UTCmonitoring

   A fix has been identified and implemented. Instances should be showing on the console and instance operations should now be available. You should now also be able to ingest metrics using CMI. We are continuing to monitor the status of these services.

3. 22. August 2025 um 13:31 UTCresolved

   This incident has been resolved.

4. 12. September 2025 um 15:45 UTCpostmortem

   ### What happened On August 22, 2025, from 10:10 to 11:27 UTC, users experienced an issue with the Aura Console where instance operations were unavailable. This was due to a timing issue with refreshing security keys that affected the visibility and operations of instances in the Aura Console and also caused an outage in the Customer Metrics Integration \(CMI\) and Aura API. The issue was identified within 5 minutes and efforts to resolve it began promptly. The problem was traced back to a recent update and issues with authentication were resolved by refreshing the system cache, with the service fully restored by 11:27 UTC.  The issue arose because of a timing mismatch between the creation of new security keys and their recognition by our system. When new keys were generated, they were quickly used by the Console API. However, another part of our system, the database manager, was still using an older set of keys to verify requests. This mismatch caused requests to fail because the database manager could not recognize the new keys. No unauthorized operations were allowed and this did not affect the security of the service in any way. After approximately an hour, the system automatically updated its keys, and everything started working correctly again. ### How customers were affected Aura Console features were impacted, including the visibility of instances and therefore ability to connect to instances through the console. Driver connections to instances were not impacted. The issue also impacted the use of parts of the service including Customer Metrics Integration \(CMI\) and the Aura API. ### What we are doing now Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. We are taking steps to prevent similar issues in the future by improving our processes and monitoring systems. Changes we are making: * Enhancing our caching mechanisms to ensure seamless updates and prevent similar issues in the future. * Designing a robust process for updating service accounts and keys to guarantee uninterrupted service reliability.

1. 19. August 2025 um 09:19 UTCinvestigating

   We are currently investigating an issue with backups. We will update shortly as we get more details

2. 19. August 2025 um 10:05 UTCinvestigating

   We are continuing to investigate the issue with backups. New backups after 0:00 last night are failing to complete. Existing backups are unaffected and remain available.

3. 19. August 2025 um 10:34 UTCinvestigating

   We are continuing to investigate this issue.

4. 19. August 2025 um 10:51 UTCinvestigating

   We continue to investigate and have identified the issue more clearly. Beyond backups, other operations are also affected: pause and clone. Operations may fail or take a long time to complete.

5. 19. August 2025 um 11:30 UTCmonitoring

   The fix has been deployed and we will continue to monitor this incident.

6. 19. August 2025 um 12:04 UTCresolved

   This incident has been resolved.

7. 12. September 2025 um 19:41 UTCpostmortem

   ### What happened On August 18, 2025, at 19:18 UTC, the release of a faulty component in Neo4j Aura impacted the ability to perform backups of customer instances. The problem was identified when a critical component was updated without aligning with another dependent component, leading to failed backup attempts. This resulted in Neo4j not being able to take backups of customer instances for a period of approximately 17 hours. Our team quickly identified the root cause and began mitigation efforts early on August 19, 2025. By 11:54 UTC, the issue was fully resolved, and normal backup operations resumed. We apologize for any inconvenience this may have caused and are taking steps to prevent similar issues in the future. The issue arose because the deployment of the neo4j-backup system was not properly synchronized with the deployment of the neo4j-operator. This misalignment led to critical changes being introduced that impacted the ability to create new backups effectively. Essentially, the two components were not updated in harmony, which caused disruptions in the backup process. ### How customers were affected Customers were unable to  get successful backups of their instances for 17 hours. We promptly addressed the issue by reverting the recent backup changes that caused disruptions and ensured the stability of our service by cleaning up old, failing backups. ### 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