Störungsverlauf von Neo4j Aura

1. 26. Oktober 2026 um 14:50 UTCinvestigating

   Uns ist derzeit ein Problem bekannt, das sich auf Kunden auswirkt, die Aura in Azure verwenden, wenn sie versuchen, Snapshots von Datenbankinstanzen herunterzuladen.

2. 26. Oktober 2026 um 15:09 UTCidentified

   Wir haben das Problem identifiziert und arbeiten derzeit an der Bereitstellung des Fixes.

3. 26. Oktober 2026 um 16:22 UTCidentified

   Der Fix wird derzeit in niedrigeren Umgebungen getestet, bevor er eingesetzt wird.

4. 26. Oktober 2026 um 17:43 UTCidentified

   Das Testen des Fixes ist im Gange und die Bereitstellung wird fortgesetzt, sobald das Testen abgeschlossen ist.

5. 26. Oktober 2026 um 19:14 UTCresolved

   Unsere Ingenieure haben erfolgreich einen Fix eingesetzt, und das Problem ist nun behoben. Aura-Kunden auf Azure können jetzt Datenbank-Snapshots ohne Probleme herunterladen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Oktober 2026 um 07:35 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das die Region Europe West 2 in GCP betrifft und sich auf einige Operationen auswirkt, einschließlich der Erstellung von Datenbankinstanzen in der Region.

2. 20. Oktober 2026 um 08:36 UTCinvestigating

   Wir untersuchen das Problem derzeit weiter und arbeiten mit der GCP zusammen, um eine Lösung zu finden. Zu diesem Zeitpunkt sind einige Operationen, einschließlich der Erstellung von Datenbankinstanzen in der Region, weiterhin betroffen.

3. 20. Oktober 2026 um 09:15 UTCidentified

   Wir haben die Quelle des Problems identifiziert, das derzeit Kunden auf europe-west2 auf GCP betrifft. Weitere Einzelheiten finden sich auf der GCP-Statusseite unter https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj. Zu diesem Zeitpunkt sind einige Operationen, einschließlich der Erstellung von Datenbankinstanzen in der Region, weiterhin betroffen.

4. 20. Oktober 2026 um 10:42 UTCidentified

   Wir setzen derzeit Abhilfemaßnahmen um, um das Problem in der Zwischenzeit zu mildern. Folgen Sie dem neuesten Stand von GCP auf der Statusseite unter https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.

5. 20. Oktober 2026 um 12:38 UTCmonitoring

   Die Funktionalität sollte nun in den betroffenen Aura-Diensten wiederhergestellt werden. Wir werden die Situation genau beobachten, bevor wir eine Lösung in Betracht ziehen.

6. 20. Oktober 2026 um 14:06 UTCmonitoring

   Wir beobachten die Situation mit GCP derzeit weiter und zu diesem Zeitpunkt haben wir keine neuen Probleme gesehen.

7. 20. Oktober 2026 um 14:50 UTCresolved

   Dieser Vorfall wurde behoben

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Oktober 2026 um 09:15 UTCinvestigating

   Wir untersuchen ein Problem, das sich auf Metriken in der Aura Console und über den metrischen Endpunkt auswirkt.

2. 13. Oktober 2026 um 10:13 UTCidentified

   Wir haben festgestellt, dass ein Problem mit Cloud Service Providern die aktuelle Situation beeinflusst. Wir haben einen Supportfall mit dem Cloud Service Provider eröffnet und werden weiter aktualisieren, sobald wir mehr Details haben.

3. 13. Oktober 2026 um 11:01 UTCmonitoring

   Wir glauben, dass das Problem mit dem Cloud Service Provider gelöst wurde, da wir keine Probleme mehr von unseren internen Systemen sehen. Wir werden die Situation weiterhin beobachten, während wir auf die Bestätigung durch den Cloud Service Provider warten.

4. 13. Oktober 2026 um 12:08 UTCresolved

   Wir haben vom Cloud Service Provider die Bestätigung erhalten, dass das Problem nun vollständig behoben ist.

5. 16. Oktober 2026 um 17:06 UTCpostmortem

   **Fehler beim Senden von Metriken von GCP europe-west1** **Was ist passiert ** Am Dienstag, den 13. Oktober 2026 um 08:54 UTC wurden die Metriken für Instanzen in GCP europe-west1 nicht mehr geliefert und konnten nicht gelesen werden. Die Ursache war ein Problem auf der Google Cloud-Seite, bei dem eine Kapazitätsreduzierung des Überwachungsdienstes dazu führte, dass gültige Anfragen falsch abgelehnt wurden. Die Metriken wurden um 10:49 UTC wieder normal, nachdem Google Cloud einen Fix angewendet hatte, und wir lösten den Vorfall um 12:08 UTC, nachdem Google Cloud die vollständige Auflösung bestätigt hatte. Instanzen blieben während dieser Veranstaltung verfügbar, ohne Auswirkungen auf die Abfrageleistung oder Datenintegrität. Nur die Sichtbarkeit der Metriken war betroffen. **Wie der Dienst betroffen war** Kunden sahen einige kurze Lücken in Instanzmetriken: * ** Konsolenmetriken:** Instanzen in GCP europe-west1 haben möglicherweise unvollständige oder fehlende metrische Daten während des Ereignisfensters angezeigt. * **Cloud Monitoring Integration \(CMI\):** Metriken, die an Ihre eigenen Überwachungssysteme aus dieser Region weitergeleitet wurden, können ebenfalls Lücken aufweisen. Nicht alle Instanzen in der Region waren betroffen, und andere Cloud-Anbieter und Regionen waren nicht betroffen. Metriken, die während des Vorfalls generiert wurden, wurden nicht aufgezeichnet, so dass die Lücke in historischen Charts für betroffene Instanzen verbleibt. **Was wir jetzt tun ** Der Fix kam diesmal von Google Cloud, aber unsere Metrik-Pipeline stützte sich auf einen einzelnen Regionspfad, so dass wir Schritte unternehmen, um diese Exposition zu reduzieren: * **Regionale Resilienz:** Wir evaluieren ein regionenübergreifendes Routing, so dass der Metrikenverkehr in eine gesunde Region ausfallen kann. * **Verkehrsroute:** Wir untersuchen Optionen in unserer Cloud-Netzwerkschicht, um sowohl Lesen (Konsole und CMI) als auch Schreiben (Eingabe) von einer betroffenen Region umzuleiten

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 14:58 UTCinvestigating

   Wir untersuchen ein Problem mit Metriken in der Aura Console und über den metrischen Endpunkt.

2. 8. Oktober 2026 um 15:36 UTCidentified

   Wir untersuchen weiterhin die Ursache. Das Problem beschränkt sich auf Kunden auf us-central1 auf GCP Aura-Instanzen laufen und keine Operation ist betroffen.

3. 8. Oktober 2026 um 16:30 UTCidentified

   Wir arbeiten mit dem Cloud-Dienstleister zusammen, um die Art des Problems zu untersuchen. Unsere Prüfungen bestätigen, dass nur eine Teilmenge der Kunden, die in den us-central1-Regionen tätig sind, betroffen sind.

4. 8. Oktober 2026 um 18:41 UTCidentified

   Wir arbeiten weiterhin mit dem Cloud-Dienstleister zusammen, um eine Lösung zu finden.

5. 8. Oktober 2026 um 19:11 UTCresolved

   Dieser Vorfall wurde nun behoben, Metriken sollten nun normal funktionieren.

6. 16. Oktober 2026 um 17:04 UTCpostmortem

   **Fehler beim Senden von Metriken von GCP us-central1** **Was ist passiert ** Am Donnerstag, den 8. Oktober 2026 um 14:05 UTC wurden die Metriken einiger Instanzen in GCP us-central1 nicht mehr geliefert. Die Ursache war ein Problem auf der Google Cloud-Seite, das gültige metrische Anfragen falsch abgelehnt hat. Die metrische Lieferung wurde um 18:00 UTC fortgesetzt, nachdem Google Cloud einen Fix angewendet hatte, und wir haben den Vorfall um 18:48 UTC behoben. Instanzen blieben während dieser Veranstaltung verfügbar, ohne Auswirkungen auf die Abfrageleistung oder Datenintegrität. Nur die Sichtbarkeit von Metriken war vorübergehend betroffen. **Wie der Dienst betroffen war** Kunden sahen Lücken in Instanzmetriken: * ** Konsolenmetriken:** Instanzen in GCP us-central1 haben möglicherweise unvollständige oder fehlende metrische Daten während des Ereignisfensters angezeigt. * **Cloud Monitoring Integration \(CMI\):** Metriken, die an Ihre eigenen Überwachungssysteme aus dieser Region weitergeleitet wurden, können ebenfalls Lücken aufweisen. Nicht alle Instanzen in der Region waren betroffen, und andere Cloud-Anbieter und Regionen waren nicht betroffen. **Was wir jetzt tun ** Der Fix kam von Google Cloud, aber wir unternehmen Schritte, um ähnliche Ereignisse früher zu erfassen und darauf zu reagieren: * **Alarmierung bei metrischen Lieferfehlern:** Wir fügen Alarmierung auf metrische Weiterleitungsfehlerraten hinzu, so dass anbieterseitige Fehler früher erkannt und von Routinelücken unterschieden werden. * **Weitere Überwachung:** Wir werden die Region mit Google Cloud weiterhin auf Wiederholungen überwachen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 09:22 UTCinvestigating

   Wir untersuchen ein Problem, bei dem trotz erfolgreicher Backups Snapshot-Downloads leere Dumps zurückgeben. Die Wiederherstellung von einem Snapshot durch die Aura-Konsole oder API wird nicht als betroffen angesehen, und wir überprüfen dies jetzt. Wir werden ein Update teilen, sobald wir mehr Informationen haben.

2. 6. Oktober 2026 um 10:43 UTCinvestigating

   Wir werden das Thema weiter untersuchen. Wiederherstellungsvorgänge sind im Rahmen dieses Problems nicht betroffen.

3. 6. Oktober 2026 um 13:41 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

4. 6. Oktober 2026 um 13:41 UTCinvestigating

   Wir untersuchen das Problem weiter.

5. 6. Oktober 2026 um 15:19 UTCresolved

   Ein Fix wurde bereitgestellt; Snapshot-Downloads enthalten jetzt die entsprechenden Daten.

6. 26. Oktober 2026 um 08:58 UTCpostmortem

   # Was passierte Am 18. September 2026 14:33 UTC stellten wir fest, dass Snapshot-Downloads für Aura-Instanzen, die in Azure gehostet wurden, Dateien von etwa 24 KB anstelle der erwarteten Größe von mehreren Gigabyte zurückgaben. Die in Azure gespeicherten Backups hatten die richtige Größe, aber der Download-Pfad in der Konsole diente fast leeren Dateien. Die Hauptursache war ein Azure-Anmeldeproblem, das während einer Bereitstellung aufgetreten ist und verhindert, dass Backup-Daten zum Download bereitgestellt werden. Ein erster Fix wurde auf Mon, 21 Sep 2026 10:31 UTC bereitgestellt, um die korrekten Download-Größen wiederherzustellen. Das gleiche Anmeldeproblem trat jedoch auf Tue, 06 Okt 2026 08:20 UTC auf und erzeugte erneut leere Snapshot-Downloads in allen Azure-Stufen. Unser Engineering-Team identifizierte die Wiederholung, verknüpfte sie mit der gleichen Ursache, setzte eine gezielte Anmeldekorrektur für die Produktion ein und verifizierte, dass die Downloads wieder in ihre erwartete Größe zurückkehrten. Wir haben am 18. September nicht auf die Statusseite gepostet, weil eine kleine Anzahl von Kunden betroffen war, und wir haben direkt mit ihnen zusammengearbeitet. Wir haben am 6. Oktober um 09:22 UTC gepostet, etwa eine Stunde nach Beginn des Wiederauftretens, sobald es deutlich breiter war. # Wie der Service betroffen war Snapshot-Downloads waren für AuraDS Professional und Enterprise, AuraDB Professional, Business Critical und Virtual Dedicated Cloud-Instanzen mit Azure betroffen. * Snapshot Downloads zurückgegeben unbrauchbare Dateien. Wenn Kunden Snapshots von der Konsole herunterladen, erhalten sie Dateien von etwa 24 KB anstelle der eigentlichen Backup-Daten, die mehrere Gigabyte groß sein können. Dadurch wurden die heruntergeladenen Snapshots für Offline-Wiederherstellungs- oder Migrationszwecke unbrauchbar. * Backups selbst gingen nicht verloren. Die in Azure gespeicherten Backup-Artefakte blieben intakt und korrekt dimensioniert. Das Problem lag ausschließlich im Download-Pfad, nicht im Backup-Erfassungs- oder Speicherprozess. * Die Wiederherstellung über die Konsole war nicht betroffen. In-Plattform-Wiederherstellungsvorgänge (im Gegensatz zum Herunterladen einer Dump-Datei) funktionierten weiterhin, da sie direkt auf die Backup-Daten zugriffen und nicht über den betroffenen Download-Pfad. # Was wir jetzt tun Wir haben mehrere Schritte unternommen, um das Problem zu lösen, und Sicherheitsvorkehrungen getroffen, um Wiederholungen zu verhindern. * Credential Fix bereitgestellt. Wir haben das Azure-Anmeldeproblem in der Produktion behoben, wodurch die Snapshot-Downloads für alle betroffenen Instanzen sofort wiederhergestellt wurden. * Verhindern unbeabsichtigter Credential Rotation. Es wurde eine Codeänderung eingereicht, um die Logik rückgängig zu machen, die die Azure-Anmeldeinformationen bei jeder Bereitstellung auslöste. Dies stellt sicher, dass zukünftige Bereitstellungen bestehende Anmeldeinformationen nicht versehentlich ungültig machen, was der Mechanismus war, der sowohl den ursprünglichen Vorfall als auch sein Wiederauftreten verursachte. * Laufende Überwachung. Wir überwachen Azure Snapshot-Downloads auf allen Ebenen, um zu bestätigen, dass sie stabil bleiben. Wir haben betroffene Kunden gebeten, zu überprüfen, ob ihre Downloads jetzt die erwarteten Dateigrößen zurückgeben. Diese Änderungen betreffen sowohl das unmittelbare Symptom als auch das zugrunde liegende Bereitstellungsverhalten, das das Wiederauftreten des Problems ermöglicht hat

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 08:07 UTCidentified

   Wir haben ein Problem identifiziert, wenn wir versuchen, aus Snapshots auf AuraDS wiederherzustellen. Wir haben eine Lösung bereit und werden diese bald einsetzen. In der Zwischenzeit können Sie stattdessen aus einem Backup wiederherstellen.

2. 6. Oktober 2026 um 09:07 UTCidentified

   Wir haben die Ursache eindeutig identifiziert und arbeiten weiterhin an einer Lösung für dieses Problem.

3. 6. Oktober 2026 um 10:03 UTCidentified

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

4. 6. Oktober 2026 um 12:14 UTCidentified

   Ein Fix wird bereitgestellt und wird in Kürze an betroffene Kunden ausgerollt.

5. 6. Oktober 2026 um 13:35 UTCmonitoring

   Der Fix wird eingeführt und betroffene Kunden sollten sehen, dass die Funktionalität schrittweise wiederhergestellt wird.

6. 6. Oktober 2026 um 14:04 UTCresolved

   Wir haben den Fix für alle Kunden bereitgestellt.

7. 26. Oktober 2026 um 08:51 UTCpostmortem

   # Was passierte Ein Softwarefehler in einer zentralen Verwaltungskomponente von Neo4j Aura Snapshot wird für AuraDS Professional- und AuraDS Enterprise-Instanzen, die auf AWS gehostet werden, wiederhergestellt. Wenn eine Wiederherstellung angefordert wurde, suchte das System die Instanz mit einem falschen Ressourcentyp nach und gab einen Fehler zurück. Der Vorfall wurde am Montag, 05 Okt 2026 21:52 UTC erklärt. Unser Engineering-Team identifizierte die Ursache, entwickelte und validierte eine Korrektur und setzte sie am Dienstag, 06 Okt 2026 13:37 UTC in Produktion ein. # Wie der Service betroffen war Die Auswirkungen wurden auf Snapshot-Wiederherstellungsoperationen für AuraDS Professional- und AuraDS Enterprise-Instanzen ausgerichtet. Betroffene Kunden konnten für die Dauer des Problems keine Snapshots über die Aura Console oder die Aura API wiederherstellen. * Wiederherstellung von zurückgegebenen Fehlern und Unterbrechung von Workflows, die von Snapshot-Wiederherstellungen abhängen. * Instanzen blieben während dieser Veranstaltung verfügbar. Die Datenintegrität wurde nicht beeinträchtigt. Die Wiederherstellung von vollständigen und exportierten Backups blieb als Workaround verfügbar. # Was wir jetzt tun * Wir haben den Fehler in der Managementschicht von Aura behoben, der AuraDS Professional und AuraDS Enterprise Snapshot betroffen hat, und den Fix in der Produktion bereitgestellt. * Optimierung der Deployment-Pipeline: Während dieses Vorfalls dauerte die Deployment-Pipeline aufgrund der sequenziellen Erstellung der Testinstanz länger als ideal. Wir haben die parallele Erstellung von Testinstanzen evaluiert, um die Wartezeiten bei kritischen Rollouts zu reduzieren. Diese Verbesserung zielt darauf ab, die Zeit zu verkürzen, die für die Validierung und Übermittlung einer Korrektur in zukünftigen Vorfällen benötigt wird, und die Auswirkungen auf den Kunden zu reduzieren

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. September 2026 um 16:46 UTCinvestigating

   Uns ist derzeit ein Problem bekannt, das sich auf bestimmte Datenbankoperationen auswirkt, z. B. Erstellen, Löschen und Klonen für Kunden, die Aura in Azure verwenden.

2. 17. September 2026 um 17:11 UTCidentified

   Wir haben das Problem erkannt und arbeiten an einer Lösung. Zu diesem Zeitpunkt sind bestimmte Datenbankvorgänge wie Erstellen, Löschen und Klonen für Kunden, die Neo4j Aura nur in Azure verwenden, weiterhin betroffen.

3. 17. September 2026 um 19:06 UTCmonitoring

   Ein Fix wurde für alle betroffenen Umgebungen bereitgestellt. Wir werden die Situation überwachen, um sicherzustellen, dass der Fix das Problem vollständig löst.

4. 17. September 2026 um 19:55 UTCresolved

   Nach der Bereitstellung des Fixes haben wir die betroffenen Instanzen, Betriebsmetriken und Fehler überwacht. Dieser Vorfall ist nun gelöst. Ein Post-Mortem wird verfügbar sein, sobald es abgeschlossen ist.

5. 16. Oktober 2026 um 16:23 UTCpostmortem

   # Was passierte Am Donnerstag, den 17. September 2026 um 13:52 Uhr UTC führte ein Bereitstellungs-Zeit-Konflikt zwischen gleichzeitigen Operationen dazu, dass ein Berechtigungsnachweis, der von einer Aura-Kernkomponente zur Authentifizierung mit der Azure-gehosteten Infrastruktur verwendet wurde, entfernt wurde. Da vorhandene Authentifizierungstoken abgelaufen waren, begann die Komponente, Fehler für einige in Azure gehostete Aura-Instanzen zurückzugeben, was sich auf bestimmte Datenbankvorgänge auswirkte. Wir verfolgten die Fehler auf den fehlenden Nachweis, erstellten einen neuen, speicherten ihn sicher und führten einen rollenden Einsatz der betroffenen Komponente durch, der um 18:39 UTC abgeschlossen wurde. Eine kleine Anzahl von Datenbankerstellungsanforderungen, die während des Ausfalls im Gange waren, wurden in einem unvollständigen Zustand belassen und mussten manuell behoben werden. Dies wurde um 19:48 UTC abgeschlossen, und der Vorfall wurde um 19:55 UTC aufgelöst. # Wie der Service betroffen war Die Auswirkungen beschränkten sich auf Aura-Instanzen, die in Azure gehostet wurden. Andere Cloud-Anbieter waren nicht betroffen. * **Datenbankoperationen:** Kunden konnten bestimmte Datenbankoperationen wie Erstellen, Löschen und Klonen in einigen Azure-Instanzen während des Incident-Fensters nicht ausführen. Eine kleine Anzahl von Kreationen, die im Gange waren, blieb stecken und wurde manuell wiederhergestellt. * **Verwaltungssichtbarkeit:** Einige von Azure gehostete Instanzen waren in der Aura Console vorübergehend nicht sichtbar oder verwaltbar. * **Metrikenlücken:** Metrikendpunkte für einige Azure-Instanzen gaben intermittierende Fehler zurück, so dass kurze Lücken in den Metrikdaten für den betroffenen Zeitraum blieben. Diese Daten werden nicht hinterlegt. Azure-Instanzen, die bereits ausgeführt wurden, blieben weiterhin verfügbar und dienten weiterhin normal den Workloads. # Was wir jetzt tun Wir unternehmen die folgenden Schritte, um eine Wiederholung zu verhindern und unsere Reaktion zu verbessern: * **Frühere Erkennung und Kommunikation:** Wir werden die Überwachung und Alarmierung verbessern und automatisierte Nachweisprüfungen auswerten, damit Probleme erkannt und Kunden schneller informiert werden. * **Wiederherstellung aus unvollständiger Datenbankerstellung:** Wir werden einen Defekt beheben, der eine Datenbankerstellung hängen lassen kann, wenn ein Infrastrukturaufruf teilweise fehlschlägt, so dass sich das System von selbst erholt. * **Authentication Review:** Wir werden prüfen, wie sich diese Komponente bei Cloud-Anbietern authentifiziert, um Single Points of Failure zu entfernen und das Risiko einer Wiederholung dieser Art von Konflikt zu verringern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. September 2026 um 08:50 UTCidentified

   Unser Service-Provider für das Support-Portal erlebt einige Ausfälle - siehe https://status.salesforce.com/products/Salesforce Services Wenn Sie Probleme haben, einen neuen Supportfall einzureichen, senden Sie bitte eine E-Mail an [email protected]

2. 16. September 2026 um 09:16 UTCidentified

   Unser Support-Portal-Anbieter arbeitet noch daran, das Problem anzugehen. Siehe Einzelheiten hier: https://status.salesforce.com/incidents/20004433

3. 16. September 2026 um 10:11 UTCidentified

   Unser Support-Portal-Anbieter arbeitet weiterhin daran, das Problem anzugehen. Siehe Einzelheiten hier: https://status.salesforce.com/incidents/20004433

4. 16. September 2026 um 11:30 UTCmonitoring

   Ein Fix wird ausgerollt und das Portal sollte im Laufe der Zeit weniger von Fehlern betroffen sein. Siehe https://status.salesforce.com/incidents/20004433

5. 16. September 2026 um 12:29 UTCmonitoring

   Unser support-portal-anbieter rollt weiterhin einen fix aus.

6. 16. September 2026 um 14:31 UTCresolved

   Ein Fix wurde bereitgestellt und alle Funktionen sollten nun wiederhergestellt werden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 9. September 2026 um 12:31 UTCinvestigating

   Wir untersuchen derzeit ein Problem mit der Aura-Konsole console.neo4j.io und der API api.neo4j.io

2. 9. September 2026 um 12:54 UTCidentified

   Wir haben die Ursache des Problems identifiziert und arbeiten derzeit an einer Lösung.

3. 9. September 2026 um 13:10 UTCidentified

   Wir arbeiten weiter daran, das Problem anzugehen.

4. 9. September 2026 um 13:26 UTCidentified

   Wir haben gute Fortschritte gemacht und kehren die problematische Komponente zurück.

5. 9. September 2026 um 13:36 UTCmonitoring

   Wir haben einen Fix bereitgestellt und die betroffenen Dienste erholen sich.

6. 9. September 2026 um 13:39 UTCresolved

   Alle betroffenen Komponenten sind nun vollständig wiederhergestellt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

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.

4. 17. September 2026 um 10:09 UTCpostmortem

   # Was passierte Am Donnerstag, den 20. August 2026 14:58:00 UTC, begann unsere Metrik-Ingestion-Pipeline beim Senden von Daten an Google Managed Prometheus \(GMP\) erhöhte Exportausfälle zu erleben. Die zugrunde liegende Ursache war ein Vorfall mit Google Cloud Platform-Diensten in der "us-west1"-Region, der den Exportpfad unserer Infrastruktur zur Erfassung von Metriken störte. Infolgedessen begannen sich metrische Exportwarteschlangen in einer Teilmenge von Produktionsumgebungen aufzubauen. Die Fehler manifestierten sich in erster Linie als Netzwerk-Timeouts, wenn versucht wurde, metrische Daten an GMP zu liefern, wodurch die normale Aufnahme für betroffene Cluster verhindert wurde. Unser Engineering-Team identifizierte die geografische Konzentration der betroffenen Systeme - AWS "us-west-2", Google Cloud "us-west1" und Azure "westus2" - die alle durch die Infrastruktur in der Region Oregon geleitet werden. Sobald der regionale GCP-Vorfall von Google gemildert wurde, ließen die Exportfehler nach und die Warteschlangen begannen zu leeren. # Wie der Service betroffen war Die Auswirkungen beschränkten sich auf die **metrische Sichtbarkeit** für eine Teilmenge von Aura-Umgebungen. Etwa 45 Kundenumgebungen waren betroffen, was bedeutete, dass metrische Daten aus Datenbanken während des Vorfallfensters nicht in unsere Überwachungsplattform aufgenommen wurden. Die am stärksten betroffene Region war AWS `us-west-2`, mit zusätzlichen Auswirkungen in Google Cloud `us-west1` und Azure `westus2`. Kunden mit Datenbanken in diesen Regionen haben möglicherweise Lücken in ihren Metriken-Dashboards und Überwachungsdaten für die Dauer des Vorfalls. Kerndatenbankoperationen - einschließlich Lesen, Schreiben und Verfügbarkeit - waren **nicht betroffen **; nur die Erfassung und Sichtbarkeit von Leistungsmetriken wurde unterbrochen. Sobald Google das zugrunde liegende regionale Problem gemildert hatte, wurde die metrische Aufnahme wieder aufgenommen und der Rückstand der in die Warteschlange gestellten Daten verarbeitet. # Was wir jetzt tun Wir haben diesen Vorfall gründlich überprüft und unternehmen die folgenden Schritte, um unsere Widerstandsfähigkeit und Reaktionsfähigkeit zu verbessern: * **Verbesserte Observability Dashboards**: Wir verbessern unsere Metrik-Exporter-Dashboards, um eine klarere und schnellere Sichtbarkeit des Warteschlangenzustands und der Exportfehlerquoten zu ermöglichen und eine schnellere Erkennung und Diagnose ähnlicher Probleme zu ermöglichen. * **Verbessern Sie die Alarmaggregation**: Wir implementieren eine automatische Alarmgruppierung, damit ein regionaler Vorfall, der mehrere Cluster betrifft, besser als ein einzelnes korreliertes Ereignis aufgetaucht und mit angemessener Schwere und Aufmerksamkeit behandelt wird. * **Proaktive Warnung bei Einnahmefehlerraten:** Wir fügen spezielle Warnmeldungen hinzu, die auf erhöhte GMP-Einnahmefehlerraten hindeuten und unserem Team ein früheres Signal geben, bevor Exporteurwarteschlangen die Kapazität erreichen. Diese Verbesserungen sollen die Erkennungszeit verkürzen, die Störfall-Triage vereinfachen und unsere Metrik-Pipeline gegen zukünftige Störungen durch Upstream-Anbieter stärken.

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)