Neo4j Aura driftsforstyrrelser

1. 3. september 2026 kl. 16.43 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 4. september 2026 kl. 10.23 UTCidentified

   Spørgsmålet er blevet identificeret, der er stadig tilfælde til rådighed, og der er taget skridt til at løse problemet for de tilfælde, der er berørt, og som er under revision i øjeblikket.

3. 4. september 2026 kl. 15.36 UTCresolved

   Alle tilfælde er tilgængelige, manuelle trin til at frigøre det resterende lille antal tilfælde blev truffet for at løse.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. august 2026 kl. 15.49 UTCinvestigating

   Vores team har identificeret et problem med at indsamle målinger til Aura tilfælde. Dette vil påvirke den metriske synlighed og videresendelse. Vi undersøger i øjeblikket spørgsmålet.

2. 20. august 2026 kl. 16.48 UTCinvestigating

   Vi fortsætter med at undersøge Aura målinger spørgsmål.

3. 20. august 2026 kl. 19.10 UTCresolved

   Siden sidste opdatering er efterforskningen kommet videre. Problemet blev identificeret, og vi overvågede tjenesten, da den kom sig efter nedbrydningen. Vi bekræfter, at spørgsmålet nu er løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 5. august 2026 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 09.44 UTCidentified

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

10. 7. august 2026 kl. 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 kl. 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 kl. 10.52 UTCinvestigating

   Vi undersøger i øjeblikket et spørgsmål.

2. 23. juli 2026 kl. 11.08 UTCinvestigating

   Vi arbejder med ingeniørhold og gør fremskridt med undersøgelserne på nuværende tidspunkt.

3. 23. juli 2026 kl. 11.24 UTCinvestigating

   Vi arbejder med ingeniørhold og fortsætter med at gøre fremskridt med undersøgelserne på nuværende tidspunkt.

4. 23. juli 2026 kl. 11.38 UTCidentified

   Vi har identificeret årsagen til det aktuelle problem og arbejder aktivt på at løse problemet i øjeblikket.

5. 23. juli 2026 kl. 11.53 UTCidentified

   Vi implementerer den første del af fixet og fortsætter aktivt med at arbejde på at rulle den fulde løsning ud. Vi forventer en ETA i størrelsesordenen 1 time fra nu.

6. 23. juli 2026 kl. 12.11 UTCidentified

   Vi har identificeret delmængden af tilfælde påvirket og fortsætter med at implementere fixet på dette tidspunkt.

7. 23. juli 2026 kl. 12.32 UTCidentified

   Vi har indsat en konfiguration fix og arbejder nu på at løse delmængden af tilfælde påvirket.

8. 23. juli 2026 kl. 12.49 UTCidentified

   Med den konfiguration fix indsat, vi fortsætter med at løse delmængden af sager stadig påvirket.

9. 23. juli 2026 kl. 14.07 UTCidentified

   Vi fortsætter med at løse det delsæt af sager, der stadig er påvirket.

10. 23. juli 2026 kl. 14.27 UTCidentified

    Vi fortsætter med at løse den delmængde af sager, der stadig er påvirket.

11. 23. juli 2026 kl. 14.44 UTCmonitoring

    Vi fortsætter med at løse den delmængde af sager, der stadig er påvirket.

12. 23. juli 2026 kl. 15.03 UTCmonitoring

    AuraDB Virtual Dedikeret Cloud og AuraDB Business Critical bør alle nu fastsættes. Vi fortsætter med at løse delmængden af tilfælde, der stadig er påvirket for AuraDB Professional og Free.

13. 23. juli 2026 kl. 15.29 UTCmonitoring

    Vi fortsætter med at løse delmængden af tilfælde, der stadig er påvirket for AuraDB Professional og Free.

14. 23. juli 2026 kl. 15.57 UTCmonitoring

    Vi fortsætter med at løse delmængden af tilfælde, der stadig er påvirket for AuraDB Professional og Free.

15. 23. juli 2026 kl. 16.32 UTCmonitoring

    Vi fortsætter med at løse delmængden af tilfælde, der stadig er påvirket for AuraDB Professional og Free

16. 23. juli 2026 kl. 17.01 UTCmonitoring

    Vi fortsætter med at fastsætte en delmængde af tilfælde, der stadig er påvirket for AuraDB Professional og Gratis

17. 23. juli 2026 kl. 17.31 UTCmonitoring

    Vi fortsætter med at fastsætte en lille delmængde af tilfælde, der stadig er påvirket under AuraDB Professionelle og gratis niveauer.

18. 23. juli 2026 kl. 18.07 UTCmonitoring

    Vi behandlede spørgsmålet i alle AuraDB Professionelle tilfælde. Aura Free kan stadig blive påvirket. Vi vil fortsat overvåge og fastsætte de resterende databaser.

19. 23. juli 2026 kl. 19.39 UTCmonitoring

    Vi fortsætter med at fastsætte en lille delmængde gratis tilfælde, der stadig er påvirket.

20. 24. juli 2026 kl. 06.00 UTCmonitoring

    Vi følger fortsat situationen nøje for alle andre spørgsmål.

21. 24. juli 2026 kl. 08.30 UTCmonitoring

    Vi fortsætter med at overvåge for yderligere spørgsmål.

22. 24. juli 2026 kl. 12.59 UTCmonitoring

    Alle identificerede tilfælde er blevet rettet, fortsætter med at overvåge. Kontakt kundesupport for yderligere spørgsmål.

23. 24. juli 2026 kl. 15.56 UTCresolved

    Alle rettelser er blevet gennemført, og problemet er nu markeret som løst.

24. 29. juli 2026 kl. 21.58 UTCpostmortem

    Hvad skete der? Torsdag, 23 jul, 2026 10: 33 UTC en konfiguration ændring blev indsat til Aura, der utilsigtet ændret, hvordan hukommelse tildelinger blev beregnet til database tilfælde. Som et resultat, en delmængde af tilfælde modtaget utilstrækkelig hukommelse, forårsager nogle database tilfælde til at blive utilgængelige eller ude af stand til at fuldføre opdateringer. Den justerede hukommelse allokering førte til out- of- memory betingelser, forårsager databasetilfælde til gentagne genstarter på grund af utilstrækkelige hukommelse ressourcer eller blive hængende opdatering. Dette spørgsmål berørte tilfælde på tværs af flere cloud-udbydere og flere produktniveauer. Da problemet blev identificeret, vendte vi straks konfigurationsændringen tilbage, hvilket forhindrede yderligere tilfælde i at modtage den forkerte konfiguration. En korrigeret konfiguration blev sat til produktion torsdag d. 23. jul 2026 11: 56 UTC. Databasen tilfælde, der allerede havde modtaget den forkerte konfiguration krævede individuelle recovery handlinger, før de kunne vende tilbage til normal drift. Ved torsdag jul 23, 2026 17: 59 UTC, alle kendte customer- impacing database tilfælde var blevet inddrevet. Overvågning fortsatte gennem den følgende dag, med hændelsen helt løst fredag 24 jul, 2026 16: 30 UTC. # # * * Hvordan tjenesten blev påvirket * * Den primære kunde virkning var, at flere AuraDB database tilfælde blev utilgængelige eller indtastet en forringet tilstand. Berørte tilfælde var ikke i stand til at fuldføre rutinemæssige softwareopdateringer og i nogle tilfælde gentagne gange genstartet, fordi der var blevet tildelt utilstrækkelig hukommelse. * * * Tjenestetilgængelighed: * * Kundeeffekt varieret efter serviceniveau. AuraDB Professionelle tilfælde, som ikke giver høj tilgængelighed, oplevede det største niveau af service afbrydelse, med en delsæt bliver utilgængelige og ude af stand til at behandle læser eller skriver. For berørte AuraDB Business Critical og Virtual Dedikeret Cloud\ (VDC\) tilfælde, virkningen var generelt begrænset til et midlertidigt tab af fejl tolerance, mens tjenesten tilgængelighed blev opretholdt. I et mindre antal tilfælde blev business-kritiske og VDC-tilfælde også ikke tilgængelige. * * * Stack opdateringer * *: Yderligere tilfælde forblev tilgængelige, men sad fast i en "Opdatering" tilstand, som blokerede customer-initierede operationer såsom resizes eller konfigurationsændringer. * * * Cross- platform scope * *: Virkningen spænder over alle tre understøttede cloud-udbydere og flere regioner, der påvirker kunderne globalt. Kundesupport sager blev rejst, og vores team triaged og manuelt inddrives berørte tilfælde i prioriteret rækkefølge. De fleste AuraDB tilfælde fortsatte med at fungere normalt. Kundeeffekten blev fuldt afbødet gennem konfigurationen tilbage og målrettet manuel genopretning af hver berørt instans. Hvad vi gør nu Vi har foretaget en grundig analyse af denne hændelse og identificeret følgende handlinger: * * * Forebyggelse * * * * * Forbedret implementeringsvalidering: * * Vi styrker vores valideringsproces for at identificere konfigurationsændringer. * * * Komponent afkobling * *: Vi evaluerer forbedringer i sekvenseringen af komponentinstallationer for at reducere risikoen for utilsigtede ændringer i udgivelser. * * * Progressiv udrulningsstrategi * *: Vi gennemgår udrulningsprocessen for de berørte komponenter, for at bringe dem i overensstemmelse med udrulningskontrollerne, der anvendes til andre kritiske komponenter. * * * påvisning * * * * * Bedre alarmering * *: Vi øger vores overvågning for at opdage unormale stigninger i fejlrater\ (såsom tab af fejltolerance eller tilgængelighed\) hurtigere og mere pålideligt. * * * Mitigation * * * * * Sikker indsætning: * * Vi forbedrer, hvordan produktionskonfiguration ændringer er indsat, så de kan deaktiveres eller rulles tilbage hurtigere uden at kræve en bredere software frigivelse. * * * Hurtigere manuelt opsving værktøj * *: Vi forbedrer vores opsving værktøj til at reducere den tid, der kræves til at identificere og manuelt gendanne berørte tilfælde. Vi anerkender den afbrydelse denne hændelse forårsaget og undskylde for virkningen til berørte kunder. Vi har gennemført de øjeblikkelige korrigerende foranstaltninger, og de forbedringer på længere sigt, der er beskrevet ovenfor, er allerede i gang for at reducere sandsynligheden for og virkningen af lignende hændelser i fremtiden.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 10. juli 2026 kl. 17.18 UTCinvestigating

   Vi er i øjeblikket ved at undersøge et problem, der påvirker Aura Console, hvor nogle kunder kan være ude af stand til at se deres tilfælde. Dette problem skyldes en fiasko i en tredjepartstjeneste, som Aura er afhængig af. Berørte tilfælde fortsætter med at køre normalt, og database forbindelse er ikke påvirket. Vores team undersøger sagen aktivt.

2. 10. juli 2026 kl. 17.23 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 10. juli 2026 kl. 17.51 UTCmonitoring

   Den tredje part service, som Aura afhænger af har genoprettet normale operationer og Neo4j Aura systemer er kommet sig. Vores team er aktivt at overvåge spørgsmålet for at bekræfte Aura Console udfører som forventet.

4. 10. juli 2026 kl. 19.23 UTCresolved

   Tjenesterne bekræftes at være operationelle, og der forventes ikke yderligere afbrydelser.

5. 27. juli 2026 kl. 04.28 UTCpostmortem

   Hvad skete der Aura Console og andre Aura komponenter oplevede forstyrrelser på 2026- 07- 10 ved 16: 14 UTC, hvilket resulterer i svigt og crashloops. Derfor stod et segment af kunder over for synlighedsspørgsmål vedrørende deres tilfælde. Det var forårsaget af en afbrydelse i en ekstern tredjeparts service integreret med Aura. Hovedsagen var, at databaseforbindelsen forblev upåvirket, og de ramte tilfælde fortsatte deres normale drift. LaunchDarkly service blev genoprettet for at løse problemet Hvordan tjenesten blev påvirket Flere Aura komponenter, herunder Aura Console, oplevede forstyrrelser. Brugerne stødte på HTTP 500 fejl på databaser-relaterede sider og operationer, selvom organisationer og projekter stadig kunne tilgås. Direkte forbindelser til specifikke databaseinstanser var fuldstændig upåvirket Kontrolplanet blev ikke tilgængelig, hvilket betød, at brugerne ikke kunne oprette, slette, ændre størrelse eller justere indstillinger for tilfælde via API eller Aura konsol. Eksisterende tilfælde forblev imidlertid operationelle. Problemet var forårsaget af en afbrydelse på LaunchDarkly og vores tjenester ikke håndtere, at afhængighed fiasko elegant under opstart. Alle berørte systemer returneres til normal drift i 2026- 07- 10 ved 17: 07 UTC Hvad laver vi nu Neo4j Engineering team hurtigt diagnosticeret roden årsag og restaureret service. Ved vurderingen af denne hændelse har vi identificeret nøgleområder, der kan fremskynde fremtidige resolutioner og mindske risikoen for gentagelse: * Analyseret nøgle hændelse målinger, med fokus på alarm- to- respons varighed til at identificere muligheder for at fremskynde respons effektivitet * Udførte en omfattende retrospektiv fremhæve succesfulde resultater, herunder hurtig root- årsag analyse via gennemsigtig logning, problemfri tilpasning via hændelsen management værktøj, og den robuste, yndefulde nedbrydning af flere komponenter, der holdt data plane konnektivitet intakt * Aktivt udvikle mere yndefulde fallback standard for feature flag til at sikre centrale operationer i løbet af leverandørens nedetider * Styrkelse af den arkitektoniske modstandsdygtighed ved at integrere avanceret planlægning, kaostteknik praksis, og produktions-niveau fejl injektion test til forebyggende afdække og afbøde potentielle svigt stier * Rettet logik begrænsninger i operatøren funktion flag caching, understreger nødvendigheden af, at operatørerne til at gemme evaluerede flag lokalt for at bevare driftsmæssig kontinuitet, hvis eksterne afhængigheder mislykkes.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 30. juni 2026 kl. 14.45 UTCidentified

   Kører CREATE VECTOR INDEX fejl 51N31 fejl: systemkonfiguration eller driftsundtagelse - ikke understøttet. Oprettelse af et vektorindeks med angivne indstillinger understøttes ikke i V2026 _ 02. Krævet version til drift er V2026 _ 06. Opgradering af DBMS.. Dette påvirker kun nye indeks, eksisterende VECTOR INDEX er upåvirket. Enhver vektor indeks oprettet før 2026- 06- 30 ved 09: 00 fortsætte med at fungere normalt.

2. 30. juni 2026 kl. 15.41 UTCidentified

   Vi begynder nu at implementere en rettelse til at løse dette problem og vil give en opdatering snart om fremskridt.

3. 30. juni 2026 kl. 16.05 UTCmonitoring

   Et fix er rullende ud og skrider godt. Vi vil opdatere med fremskridt.

4. 30. juni 2026 kl. 17.45 UTCresolved

   Fixet er blevet fuldt indsat til alle ramte tilfælde. Denne hændelse er nu løst.

5. 20. juli 2026 kl. 08.40 UTCpostmortem

   Hvad skete der Et problem blev identificeret efter indførelsen af version 2026.06 den 2026- 06- 30 kl 08: 00 UTC, hvor kører 'CREATE VECTOR INDEX' på opgraderede Aura tilfælde udløste en systemundtagelse. Denne fejl i indeks generation opstod, fordi den underliggende butik og kernen krævede yderligere opdateringer til at understøtte operationen Dette problem kun påvirket oprettelsen af nye indekser; eksisterende vektor indekser er ikke påvirket. Enhver vektor indeks oprettet før 09: 00 på 2026- 06- 30 var upåvirket og fortsatte med at arbejde normalt. Hvordan tjenesten blev påvirket Efter udrulningen af version 2026.06, udførelse af CREATE VECTOR INDEX erklæring mislykkedes, påvirker programmer, der afhang af at tilføje nye vektor indekser. Berørte kunder modtog fejlen: _ Oprettelse af et vektor indeks med givne indstillinger er ikke understøttet i V2026\ _ 02. Den ønskede version til drift er V2026\ _ 06. Opgradere venligst DBMS _. Eksisterende indeks\ (oprettet før denne hændelse\) og andre forespørgsler forblev helt upåvirket og fuldt funktionel. Hvad laver vi nu Neo4j teams identificerede roden som en fejl i Cypher planner og løste problemet med en kode fix. Denne rettelse er blevet indsat til alle berørte Aura tilfælde, fuldt løse fejlen For at forhindre fremtidige hændelser, vi øger vores overvågning og alarmering systemer til at opdage lignende spørgsmål tidligere, især i iscenesættelse miljøer, før udrulning forekommer. Samtidig er vi raffinere vores implementering processer til at minimere kundernes indvirkning og inddrivelse gange Derudover er vi ved at undersøge muligheder for at implementere automatiserede, efter-opgradering validering test specielt til kritiske operationer såsom vektor indeks skabelse

Automatisk oversat fra den officielle hændelsesopdatering.

1. 23. juni 2026 kl. 11.25 UTCidentified

   Aura konsol oplever nogle periodiske fejl: "Vores system oplever problemer lige nu. Prøv igen senere eller kontakt support, hvis problemet fortsætter". Dette kan kræve, at du genindlæser eller venter længere på at navigere i konsollen Operationer og Aura API forbliver upåvirket Vi arbejder aktivt på et fix

2. 23. juni 2026 kl. 13.03 UTCidentified

   Vi fortsætter med at undersøge et fix for spørgsmålet

3. 23. juni 2026 kl. 13.39 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

4. 23. juni 2026 kl. 15.43 UTCmonitoring

   Vi foretager en ændring. Vi vil overvåge og opdatere.

5. 23. juni 2026 kl. 19.27 UTCmonitoring

   Fortsætter med at overvåge de gennemførte ændringer. Næste opdatering forventes 6 / 24 / 2026 10am UTC.

6. 24. juni 2026 kl. 09.14 UTCmonitoring

   Vi har undersøgt og bekræftet, at spørgsmålet nu behandles fuldt ud.

7. 24. juni 2026 kl. 09.14 UTCresolved

   Denne hændelse er blevet løst.

8. 10. juli 2026 kl. 14.50 UTCpostmortem

   Hvad skete der Ved ca. 12: 00 UTC den 22 januar 2026, brugerne stødte intermitterende fejl bannere i Aura konsol viser, "Vi har et problem. Prøv igen.", som opstod sammen med 500 fejl fra konsol API endepunkter. Disse forstyrrelser var forbigående og forårsaget af intern API timing ud under TLS håndtryk proces, typisk løse inden for omkring 10 sekunder eller efter en side opdatering Hvordan tjenesten blev påvirket Aura Console og Aura API oplevede forringet ydeevne, som manifesterede sig som periodiske fejlbannere i Aura konsollen UI. En undersøgelse identificerede roden årsag som høj CPU-forbrug og væltning i konsollen API. Dette spørgsmål blev primært drevet af gentagne store enhed lister og dyre afstemning anmodninger For at løse problemet, målrettede rettelser blev med succes indsat til både Aura konsol og Aura API. Dette blev efterfulgt af justeringer af ressourcekonfigurationen for at øge det operationelle headroom og sikre stabilitet Hvad laver vi nu Der er gennemført følgende reaktive og proaktive foranstaltninger for at mindske sandsynligheden for lignende hændelser: * Udviklet en overvågning dashboard til at observere anmodninger dråber baseret på interne API log data til at gennemføre automatisk overvågning og advarsel om at fange problemer, før de opstår * Gennemført en forskudt forsinkelse mellem paginerede forsoningsanmodninger til at afbøde højt ressourceforbrug og forbedre API stabilitet * Forbedret infrastruktur bevidste ressourcer beregninger til at forbedre ydeevnen * Indførte et nyt filter til forespørgsler baseret på service niveauer til at optimere CPU overhead for hver opkald udført af consigliler * Deaktiveret overflødig anmodning middleware behandling til at optimere API-opkald

Automatisk oversat fra den officielle hændelsesopdatering.

1. 26. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 23.06 UTCresolved

   This incident has been resolved.

4. 9. juni 2026 kl. 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. marts 2026 kl. 10.18 UTCidentified

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

2. 6. marts 2026 kl. 10.24 UTCmonitoring

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

3. 6. marts 2026 kl. 10.25 UTCresolved

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

4. 30. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 04.52 UTCidentified

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

4. 4. marts 2026 kl. 14.07 UTCmonitoring

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

5. 4. marts 2026 kl. 15.19 UTCresolved

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

6. 8. april 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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 kl. 19.26 UTCidentified

   Vi har identificeret et problem, der kan påvirke et begrænset sæt af Cypher 25 forespørgsler til AuraDB Free, Professional og AuraDS. Dette kan påvirke: - Forespørgsler ved hjælp af den betingede forespørgsel WHEN i kombination med en ikke-gruppering aggregering over null værdier resulterer i et forkert antal rækker returneres. - Forespørgsler ved hjælp af NEXT kan producere en uventet variabel ikke defineret fejl i nogle tilfælde. Vi arbejder aktivt på en rettelse og vil opdatere denne side som mere information bliver tilgængelig.

2. 27. januar 2026 kl. 01.37 UTCidentified

   Vi har identificeret en løsning på dette spørgsmål og vil være rullende ud i Aura. Når opdateringen er blevet indsat vil vi opdatere denne tatus side.

3. 27. januar 2026 kl. 09.50 UTCidentified

   Vi ruller fixet ud og vil opdatere dig, når dette er afsluttet.

4. 27. januar 2026 kl. 11.10 UTCmonitoring

   Fixet er rullet ud til de berørte komponenter, vi nu overvåge situationen på dette tidspunkt.

5. 27. januar 2026 kl. 14.51 UTCmonitoring

   Vi følger fortsat situationen på nuværende tidspunkt.

6. 27. januar 2026 kl. 15.58 UTCresolved

   Fixet er blevet fuldt indsat til alle ramte tilfælde. Denne hændelse er nu løst.

7. 2. juli 2026 kl. 04.22 UTCpostmortem

   Hvad skete der? Neo4j begyndte indførelsen af version 2026.01.1 til Aura gratis tilfælde på 07: 49 AM UTC den 26 januar 2026. Efter påvisning af forespørgsel svigt under interne test, udrulningen blev stoppet, før det nåede Aura højere niveauer. Fejlene opstod på betingede forespørgsler\ (fx når... THEN...\) efter plannerfasen til at opføre sig anderledes i tilfælde af sammenlægning over null værdier. Vi identificerede årsagen og udviklede en resolution, som blev integreret i version 2026.01.2. Den 27. januar 2026 begyndte vi at implementere 2026.01.2 på tværs af Aura tilfælde, med succes opgradere alle berørte miljøer til den korrigerede version Hvordan tjenesten blev påvirket Forespørgsler som bruger WHEN i 2026.01.1 i kombination med aggregering over null værdier får et forkert antal rækker returneret. Forespørgsler, der bruger NEXT, kan i nogle tilfælde give en uventet variabel, der ikke er defineret fejl. Dette fik den omskrevne forespørgsel til at opføre sig anderledes i tilfælde af sammenlægning over null værdier. Den betingede forespørgsel skal modtage indkommende rækker indeholdende null-værdier og aggregere over værdierne uden at bruge en gruppering. Kunderne fik et forkert resultat, hvis de brugte den betingede forespørgselskonstruktion i Cypher 25\ (se [https: / / neo4j.com / docs / aura / managing-instances / cypher- version /] (https: / / neo4j.com / docs / aura / managing-instances / cypher- version /)\), en effekt, der var begrænset til et begrænset antal Aura-tilfælde. Hvad laver vi nu Vi har forbedret vores testprocedurer for at sikre omfattende dækning på tværs af alle produktområder. Dette omfatter udvikling af nye testsager, der er udformet til at håndtere både identificerede spørgsmål og potentielle fremtidige scenarier. Desuden har vi integreret Cypher forespørgsel test i Aura som en standard komponent i vores regression test suite. Disse kontroller er nu obligatoriske trin i vores løbende integrationsrørledning og iscenesættelse forud for enhver produktionsudrulning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 16. januar 2026 kl. 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 kl. 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 kl. 17.07 UTCmonitoring

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

4. 16. januar 2026 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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. december 2025 kl. 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. december 2025 kl. 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. december 2025 kl. 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. december 2025 kl. 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. december 2025 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 10.32 UTCmonitoring

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

5. 20. oktober 2025 kl. 11.13 UTCresolved

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

6. 15. januar 2026 kl. 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 kl. 13.34 UTCinvestigating

   We are currently investigating this issue.

2. 25. august 2025 kl. 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 kl. 13.47 UTCinvestigating

   We are continuing to investigate this issue.

4. 25. august 2025 kl. 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 kl. 21.44 UTCmonitoring

   We continue to work towards the issue resolution.

6. 26. august 2025 kl. 04.06 UTCmonitoring

   We are continuing to investigate this issue.

7. 26. august 2025 kl. 10.53 UTCmonitoring

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

8. 26. august 2025 kl. 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 kl. 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 kl. 06.36 UTCmonitoring

    We are continuing to monitor for any further issues.

11. 27. august 2025 kl. 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 kl. 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 kl. 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 kl. 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 kl. 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 kl. 13.31 UTCresolved

   This incident has been resolved.

4. 12. september 2025 kl. 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 kl. 09.19 UTCinvestigating

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

2. 19. august 2025 kl. 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 kl. 10.34 UTCinvestigating

   We are continuing to investigate this issue.

4. 19. august 2025 kl. 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 kl. 11.30 UTCmonitoring

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

6. 19. august 2025 kl. 12.04 UTCresolved

   This incident has been resolved.

7. 12. september 2025 kl. 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