Neo4j Aura driftsforstyrrelser

1. 26. oktober 2026 kl. 14.50 UTCinvestigating

   Vi er i øjeblikket klar over et problem, der påvirker kunderne ved hjælp af Aura på Azure, når du forsøger at downloade database instance snapshots.

2. 26. oktober 2026 kl. 15.09 UTCidentified

   Vi har identificeret problemet og arbejder i øjeblikket på at implementere fixet.

3. 26. oktober 2026 kl. 16.22 UTCidentified

   Fixet er i øjeblikket ved at blive testet i lavere miljøer, før det bliver indsat.

4. 26. oktober 2026 kl. 17.43 UTCidentified

   Test af fixet er i gang og implementering vil fortsætte, når testen er afsluttet.

5. 26. oktober 2026 kl. 19.14 UTCresolved

   Vores ingeniører har med succes indsat et fix, og problemet er nu løst. Aura kunder på Azure kan nu downloade database snapshots uden problemer.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. oktober 2026 kl. 07.35 UTCinvestigating

   Vi er i øjeblikket ved at undersøge et spørgsmål, der berører regionen Europa West 2 i GCP, og som påvirker nogle operationer, herunder oprettelse af databaser i regionen.

2. 20. oktober 2026 kl. 08.36 UTCinvestigating

   Vi fortsætter med at undersøge spørgsmålet i øjeblikket i samarbejde med GCP for at finde en løsning. På nuværende tidspunkt er nogle operationer, herunder oprettelse af databaser i regionen fortsat påvirket.

3. 20. oktober 2026 kl. 09.15 UTCidentified

   Vi har identificeret kilden til det problem, der i øjeblikket påvirker kunderne på europe- west2 på GCP. Yderligere oplysninger fra GCP statusside på https: / / status.cloud.google.com / hændelser / Xs2XTHzAVC9YnafnPyzj. På nuværende tidspunkt er nogle operationer, herunder oprettelse af databaser i regionen fortsat påvirket.

4. 20. oktober 2026 kl. 10.42 UTCidentified

   Vi gennemfører i øjeblikket afhjælpende foranstaltninger for at afbøde problemet i mellemtiden. http: / / europa.eu.int / comm / commerce / index _ en.htm.

5. 20. oktober 2026 kl. 12.38 UTCmonitoring

   Funktionaliteten bør nu genoprettes på tværs af de berørte Aura-tjenester. Vi vil overvåge situationen nøje, før vi overvejer at løse dette problem.

6. 20. oktober 2026 kl. 14.06 UTCmonitoring

   Vi fortsætter med at overvåge situationen med GCP på nuværende tidspunkt, og på nuværende tidspunkt har vi ikke set nogen nye spørgsmål.

7. 20. oktober 2026 kl. 14.50 UTCresolved

   Denne hændelse er blevet løst

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. oktober 2026 kl. 09.15 UTCinvestigating

   Vi undersøger et problem, der påvirker målinger i Aura Console og via det metriske endepunkt.

2. 13. oktober 2026 kl. 10.13 UTCidentified

   Vi har identificeret, at en Cloud Service Provider relateret problem påvirker den aktuelle situation. Vi har åbnet en støttesag med Cloud Service Provider og vil opdatere yderligere, når vi har flere detaljer.

3. 13. oktober 2026 kl. 11.01 UTCmonitoring

   Vi mener, at Cloud Service Provider-spørgsmålet er løst, da vi ikke længere ser problemer fra vores interne systemer. Vi vil fortsat overvåge situationen, mens vi venter på bekræftelse fra Cloud Service udbyder.

4. 13. oktober 2026 kl. 12.08 UTCresolved

   Vi har fået bekræftet fra Cloud Service Provider, at problemet nu er blevet løst fuldt ud.

5. 16. oktober 2026 kl. 17.06 UTCpostmortem

   _ * * Fejl ved afsendelse af målinger fra GCP europe- west1 * * _ Hvad skete der? _ Tirsdag den 13. oktober 2026 kl 08: 54 UTC, målinger for tilfælde i GCP europe- west1 stoppet med at blive leveret og kunne ikke læses. Årsagen var et problem på Google Cloud-siden, hvor en kapacitetsreduktion i sin overvågningstjeneste førte til, at gyldige anmodninger blev afvist forkert. Metrics vendte tilbage til normal på 10: 49 UTC efter Google Cloud anvendt en rettelse, og vi løst hændelsen på 12: 08 UTC, når Google Cloud bekræftet fuld opløsning. _ _ Tilfælde forblev tilgængelige under hele denne begivenhed, uden betydning for forespørgsel ydeevne eller dataintegritet. Kun målinger blev påvirket. Hvordan blev tjenesten påvirket? _ Kunder så nogle korte huller i eksempel målinger: _ * _ * * Konsol målinger: * * Tilfælde i GCP europe- west1 kan have vist ufuldstændige eller manglende metriske data under hændelsesvinduet. _ * _ * * Cloud Overvågning Integration\ (CMI\): * * Metrics sendt til dine egne overvågningssystemer fra denne region kan også have haft huller. _ _ Ikke alle tilfælde i regionen blev påvirket, og andre cloud-udbydere og regioner blev ikke påvirket. Metrics genereret under hændelsen blev ikke registreret, så hullet vil forblive i historiske diagrammer for berørte tilfælde. _ Hvad vi gør nu _ Fixet kom fra Google Cloud ved denne lejlighed, men vores målinger pipeline baseret på en enkelt-region sti, så vi tager skridt til at reducere denne eksponering: _ * _ * * Regional modstandsdygtighed: * * Vi er ved at evaluere cross-region routing så metrics trafik kan mislykkes over til en sund region. _ * _ * * Trafikrute: * * Vi er ved at udforske muligheder i vores cloud netværk lag at omdirigere både læser\ (Console og CMI\) og skriver\ (indtagelse\) væk fra en påvirket region. _

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. oktober 2026 kl. 14.58 UTCinvestigating

   Vi undersøger et problem med målinger i Aura Console og via det metriske endepunkt.

2. 8. oktober 2026 kl. 15.36 UTCidentified

   Vi fortsætter med at undersøge årsagen. Spørgsmålet er begrænset til kunder på us- central1 på GCP Aura tilfælde kører og ingen operation er påvirket.

3. 8. oktober 2026 kl. 16.30 UTCidentified

   Vi arbejder med cloud-tjenesteudbyderen for at undersøge problemets art. Vores kontrol bekræfter, at kun en undergruppe af kunder, der kører i vores centrale regioner, er berørt.

4. 8. oktober 2026 kl. 18.41 UTCidentified

   Vi fortsætter med at arbejde med cloud-udbyder for at få en løsning.

5. 8. oktober 2026 kl. 19.11 UTCresolved

   Denne hændelse er nu løst, målinger bør nu fungere som normalt.

6. 16. oktober 2026 kl. 17.04 UTCpostmortem

   _ * * Fejl ved afsendelse af målinger fra GCP us- central1 * * _ Hvad skete der? _ Torsdag den 8. oktober 2026 kl 14: 05 UTC, målinger fra nogle tilfælde i GCP us- central1 stoppet med at blive leveret. Årsagen var et problem på Google Cloud side, der fejlagtigt afvist gyldige metriske anmodninger. Metric levering genoptaget kl 18: 00 UTC efter Google Cloud anvendt en rettelse, og vi løst hændelsen kl 18: 48 UTC. _ _ Tilfælde forblev tilgængelige under hele denne begivenhed, uden betydning for forespørgsel ydeevne eller dataintegritet. Kun målinger synlighed blev midlertidigt påvirket. Hvordan blev tjenesten påvirket? _ Kunder så huller i eksempel målinger: _ * _ * * Konsol målinger: * * Tilfælde i GCP us- central 1 kan have vist ufuldstændige eller manglende metriske data under hændelsesvinduet. _ * _ * * Cloud Overvågning Integration\ (CMI\): * * Metrics sendt til dine egne overvågningssystemer fra denne region kan også have haft huller. _ _ Ikke alle tilfælde i regionen blev påvirket, og andre cloud-udbydere og regioner var upåvirket. _ Hvad vi gør nu _ Rettet kom fra Google Cloud, men vi tager skridt til at fange og reagere på lignende begivenheder tidligere: _ * _ * * Indberetning af leveringsfejl: * * Vi tilføjer advarsel om metriske fremsendelsesfejlrater, så provider- side fejl opdages tidligere og adskiller sig fra rutinemæssige huller. _ * _ * * Fortsat overvågning: * * Vi vil holde overvågning af regionen med Google Cloud for enhver gentagelse. _

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. oktober 2026 kl. 09.22 UTCinvestigating

   Vi er ved at undersøge et problem, hvor, på trods af sikkerhedskopier udfylde succes, snapshot downloads vender tilbage tomme dumps. Gendannelse fra et øjebliksbillede gennem Aura konsol eller API menes ikke at blive påvirket, og vi er ved at kontrollere dette nu. Vi vil dele en opdatering, så snart vi har flere oplysninger.

2. 6. oktober 2026 kl. 10.43 UTCinvestigating

   Vi fortsætter med at undersøge spørgsmålet. Genopretning af operationer berøres ikke som en del af dette spørgsmål.

3. 6. oktober 2026 kl. 13.41 UTCinvestigating

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

4. 6. oktober 2026 kl. 13.41 UTCinvestigating

   Vi fortsætter med at undersøge problemet.

5. 6. oktober 2026 kl. 15.19 UTCresolved

   Et fix er blevet indsat; snapshot downloads indeholder nu de relevante data.

6. 26. oktober 2026 kl. 08.58 UTCpostmortem

   Hvad skete der? På Fri, 18 Sep 2026 14: 33 UTC, vi identificerede, at snapshots downloads for Aura tilfælde hostet på Azure returnerede filer på omkring 24KB i stedet for den forventede multi-gigabyte størrelse. De underliggende sikkerhedskopier gemt i Azure var den korrekte størrelse, men download-stien i konsollen serverede næsten tomme filer. Den grundlæggende årsag var en Azure creditial problem, der opstod under en implementering og forhindrede backup-data i at blive serveret til download. Et første fix blev indsat på Mon, 21 Sep 2026 10: 31 UTC, genoprette korrekte download størrelser. Men den samme kreditværdige problem dukkede op på Tue, 06 Okt 2026 08: 20 UTC, igen producerer blank snapshot downloads på tværs af alle Azure niveauer. Vores ingeniørhold identificerede tilbagefald, knyttet det til den samme rodårsag, indsat en målrettet kreditmæssig rettelse til produktionen, og verificeret, at downloads returneres til deres forventede størrelse. Vi skrev ikke til statussiden den 18. september, fordi et lille antal kunder blev berørt, og vi arbejdede direkte med dem. Vi skrev den 6. oktober kl 09: 22 UTC, omkring en time efter gentagelse begyndte, når det var klart bredere. Hvordan tjenesten blev påvirket Snapshot downloads blev påvirket for AuraDS Professional og Enterprise, AuraDB Professional, Business Critical og Virtual Dedikeret Cloud tilfælde kører på Azure. * Snapshot downloads returneret ubrugelige filer. Når kunderne downloadede snapshots fra konsollen, de modtog filer på omkring 24KB i stedet for den faktiske backup data, som kunne være flere gigabyte i størrelse. Dette gjorde de downloadede snapshots ubrugelige til offline gendannelse eller migration formål. * Backup selv var ikke tabt. De underliggende backup artefakter gemt i Azure forblev intakt og korrekt størrelse. Problemet var strengt i download-stien, ikke i backup capture eller opbevaring proces. * Gendannelse via konsollen var upåvirket. In- platform gendanne operationer\ (i modsætning til at downloade en dump fil\) fortsatte med at fungere, fordi de fik adgang til backup data direkte snarere end gennem den berørte download sti. "What we 're doing now Vi har taget flere skridt til at løse problemet og har gennemført sikkerhedsforanstaltninger for at forhindre gentagelser. * Creditial fix indsat. Vi korrigerede Azure creditial problem i produktionen, som straks restaurerede snapshot downloads for alle berørte tilfælde. * Forebyggelse utilsigtet credential rotation. Der er indgivet en kodeændring for at vende den logik, der udløste Azure kreditmæssig rotation på hver deployering. Dette sikrer, at fremtidige implementeringer ikke uforvarende ugyldiggør eksisterende legitimation, som var den mekanisme, der forårsagede både den første hændelse og dens gentagelse. * Løbende overvågning. Vi overvåger Azure snapshot downloads på tværs af alle niveauer for at bekræfte, at de forbliver stabile. Vi har bedt berørte kunder om at kontrollere, at deres downloads nu returnere de forventede filstørrelser. Disse ændringer omhandler både det umiddelbare symptom og den underliggende implementering adfærd, der tillod problemet at gentage

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. oktober 2026 kl. 08.07 UTCidentified

   Vi har identificeret et problem, når vi forsøger at genoprette fra snapshots på AuraDS. Vi har et fix klar og vil implementere dette snart. I mellemtiden kan du gendanne fra en backup i stedet.

2. 6. oktober 2026 kl. 09.07 UTCidentified

   Vi har klart identificeret årsagen og fortsætter med at arbejde på en løsning på dette spørgsmål.

3. 6. oktober 2026 kl. 10.03 UTCidentified

   Vi arbejder fortsat på en løsning på dette spørgsmål.

4. 6. oktober 2026 kl. 12.14 UTCidentified

   En rettelse er ved at blive indsat og vil rulle ud til berørte kunder snart.

5. 6. oktober 2026 kl. 13.35 UTCmonitoring

   Fixet er rullende ud og berørte kunder bør se funktionaliteten restaureret gradvist.

6. 6. oktober 2026 kl. 14.04 UTCresolved

   Vi har sendt fixet til alle kunder.

7. 26. oktober 2026 kl. 08.51 UTCpostmortem

   Hvad skete der? En software defekt i en central management komponent i Neo4j Aura snapshot genopretter at mislykkes for AuraDS Professional og AuraDS Enterprise tilfælde hostet på AWS. Når en gendannelse blev bedt om, systemet kiggede op instans ved hjælp af en forkert ressource type og returneret en fejl. Hændelsen blev erklæret mandag, 05 okt 2026 21: 52 UTC. Vores ingeniørhold identificerede rodårsagen, udviklede og validerede et fix, og indsatte det til produktion tirsdag 06 okt 2026 13: 37 UTC. Hvordan tjenesten blev påvirket Virkningen blev opfanget til snapshot gendanne operationer for AuraDS Professional og AuraDS Enterprise tilfælde. Berørte kunder var ude af stand til at gendanne snapshots via Aura Console eller Aura API for varigheden af problemet. * Gendanne forsøg returnerede fejl, forstyrre arbejdsgange, der afhænger af snapshot genopretter. * Tilfælde forblev tilgængelige under hele denne hændelse. Dataintegriteten blev ikke påvirket. Gendannelse fra fuld og eksporteret sikkerhedskopier forblev tilgængelig som en workout. "What we 're doing now * Vi har rettet fejlen i Aura ledelse lag, der påvirkede AuraDS Professional og AuraDS Enterprise snapshot genopretter og indsat fix til produktion. * Implementering pipeline optimering: Under denne hændelse, implementering pipeline tog længere end ideel på grund af sekventiel test instans skabelse. Vi har evalueret parallelisering test instans skabelse til at reducere ventetider under kritiske udrulninger. Denne forbedring har til formål at forkorte den tid, det tager at validere og sende en rettelse i fremtidige hændelser, reducere customer-ansigt indvirkning

Automatisk oversat fra den officielle hændelsesopdatering.

1. 17. september 2026 kl. 16.46 UTCinvestigating

   Vi er i øjeblikket klar over et problem, der påvirker visse databaseoperationer, såsom oprette, slette, klon for kunder, der bruger Aura på Azure.

2. 17. september 2026 kl. 17.11 UTCidentified

   Vi har identificeret spørgsmålet og arbejder hen imod en løsning. På dette tidspunkt, visse database operationer, såsom oprette, slette og klon for kunder, der bruger Neo4j Aura på Azure kun, fortsætter med at blive påvirket.

3. 17. september 2026 kl. 19.06 UTCmonitoring

   Et fix er blevet indsat i alle berørte miljøer. Vi vil overvåge situationen for at sikre, at problemet løses fuldt ud.

4. 17. september 2026 kl. 19.55 UTCresolved

   Efter indsættelse af fix, vi overvåget de ramte tilfælde, operationelle målinger, og fejl. Denne hændelse er nu løst. En post-mortem vil være tilgængelig, så snart det er afsluttet.

5. 16. oktober 2026 kl. 16.23 UTCpostmortem

   Hvad skete der? Torsdag den 17. september 2026 kl. 13: 52 UTC, en deployeringstid konflikt mellem samtidige operationer forårsaget en kreditiel anvendes af en kerne Aura komponent til at godkende med Azure-hostede infrastruktur til at blive fjernet. Da eksisterende autentificering tokens udløb, komponenten begyndte at returnere fejl for nogle Aura tilfælde hostet på Azure, påvirker visse database operationer. Vi sporede fejlene til det manglende creditial, skabte et nyt, gemte det sikkert, og udførte en rullende implementering af den berørte komponent, som sluttede kl 18: 39 UTC. Et lille antal anmodninger om oprettelse af databaser, der var i gang under udfald blev efterladt i en ufuldstændig tilstand og havde brug for manuel oprydning. Dette blev afsluttet kl 19: 48 UTC, og hændelsen blev markeret kl 19: 55 UTC. Hvordan tjenesten blev påvirket Virkningen var begrænset til Aura tilfælde hostet på Azure. Andre cloud-udbydere blev ikke påvirket. * * * Databaseoperationer: * * Kunder var ude af stand til at udføre visse databaseoperationer, såsom oprette, slette og klone, på nogle Azure tilfælde under hændelsesvinduet. Et lille antal af de skabninger, der var i gang blev fast og blev inddrevet manuelt. * * * Management synlighed: * * Nogle Azure- hostede tilfælde var midlertidigt ikke synlige eller håndterbare i Aura Konsole. * * * Metrics huller: * * Metrics endpoints for nogle Azure tilfælde returnerede periodiske fejl, efterlader korte huller i metrics data for den berørte periode. Disse data vil ikke blive udfyldt. Azure tilfælde, der allerede kørte forblev tilgængelige og fortsatte med at tjene arbejdsbyrder normalt. "What we 're doing now Vi tager følgende skridt for at hjælpe med at forhindre en gentagelse og forbedre vores reaktion: * * * Tidligere detektion og kommunikation: * * Vi vil forbedre overvågning og varsling, og evaluere automatiserede kreditkort kontroller, så problemer er opdaget, og kunderne bliver informeret tidligere. * * * Inddrivelse fra ufuldstændige database oprettelse: * * Vi vil løse en defekt, der kan efterlade en database skabelse sidder fast, hvis en infrastruktur opkald mislykkes delvejs igennem, så systemet genopretter på egen hånd. * * * Autentificering: * * Vi vil gennemgå, hvordan denne komponent autentificerer med cloud-udbydere, at fjerne enkelte punkter af fiasko og reducere risikoen for denne type konflikt tilbagevendende.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 16. september 2026 kl. 08.50 UTCidentified

   Vores serviceudbyder til supportportalen oplever et vist udfald - Se https: / / status.seleckraft.com / products / Salesforce _ Services Hvis du oplever problemer med at indsende en ny støttesag, bedes du sende e-mail til support @ neo4j.com

2. 16. september 2026 kl. 09.16 UTCidentified

   Vores portaludbyder arbejder stadig på at løse problemet. Se detaljer her https: / / status.seleckraft.com / equipments / 20004433

3. 16. september 2026 kl. 10.11 UTCidentified

   Vores støtte portal udbyder fortsætter med at arbejde på at løse problemet. Se detaljer her https: / / status.seleckraft.com / equipments / 20004433

4. 16. september 2026 kl. 11.30 UTCmonitoring

   En rettelse er ved at blive rullet ud og portalen bør blive mindre påvirket af fejl over tid. Se nærmere oplysninger https: / / status.selectrow.com / equipments / 20004433

5. 16. september 2026 kl. 12.29 UTCmonitoring

   Vores support portal udbyder fortsætter med at rulle ud en rettelse.

6. 16. september 2026 kl. 14.31 UTCresolved

   En rettelse er blevet indsat, og alle funktioner skal nu inddrives.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 9. september 2026 kl. 12.31 UTCinvestigating

   Vi undersøger i øjeblikket et problem, der påvirker Aura konsollen console.neo4j.io og API api.neo4j.io

2. 9. september 2026 kl. 12.54 UTCidentified

   Vi har identificeret kilden til spørgsmålet og arbejder i øjeblikket på en løsning.

3. 9. september 2026 kl. 13.10 UTCidentified

   Vi arbejder fortsat på at løse problemet.

4. 9. september 2026 kl. 13.26 UTCidentified

   Vi har gjort gode fremskridt og er ved at finde den problematiske komponent.

5. 9. september 2026 kl. 13.36 UTCmonitoring

   Vi har indsat et fix, og de berørte tjenester er ved at komme sig.

6. 9. september 2026 kl. 13.39 UTCresolved

   Alle berørte komponenter er nu fuldt genvundet.

Automatisk oversat fra den officielle hændelsesopdatering.

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.

4. 17. september 2026 kl. 10.09 UTCpostmortem

   Hvad skete der? På torsdag, 20 Aug 2026 14: 58: 00 UTC, vores målinger indtagelse rørledning begyndte at opleve forhøjede eksport svigt, når du sender data til Google Managed Prometheus\ (GMP\). Den underliggende årsag var en Google Cloud Platform service hændelse i "us- west1" regionen, som forstyrrede eksport sti, der anvendes af vores metrics indsamling infrastruktur. Som følge heraf begyndte metriske eksportkøer at bygge op på tværs af en delmængde af produktionsmiljøer. Fejlene manifesteret primært som netværk timeouts, når de forsøger at levere metriske data til GMP, forhindre normal indtagelse for berørte klynger. Vores ingeniørhold identificerede den geografiske koncentration af de berørte systemer - spanning AWS 'us- west-2', Google Cloud 'us- west1', og Azure 'westus2' - alt sammen via infrastrukturen i Oregon-området. Når GCP regionale hændelse blev afbødet af Google, eksportfejl forsvandt og køer begyndte dræning. Hvordan tjenesten blev påvirket Virkningen var begrænset til * * målesynlighed * * for en delmængde af Aura-miljøer. Omkring 45 kundemiljøer blev påvirket, hvilket betyder, at metriske data fra databaser ikke blev indtaget i vores overvågningsplatform under hændelsesvinduet. Den mest berørte region var AWS 'us- west-2', med yderligere indvirkning på Google Cloud 'us- west1' og Azure 'westus2'. Kunder med databaser i disse regioner kan have oplevet huller i deres metriske dashboards og overvågningsdata under hele hændelsen. Hoveddatabaseoperationer - herunder læsning, skriver og tilgængelighed - blev * * ikke påvirket * *; kun indsamling og synlighed af præstationsmålinger blev afbrudt. Når Google mildnet den underliggende regionale problem, metrisk indtagelse genoptaget, og backlog af queued data blev behandlet. "What we 're doing now Vi har foretaget en grundig gennemgang af denne hændelse og tager følgende skridt til at forbedre vores modstandsdygtighed og reaktionsevne: * * * Forbedret observerbarhed dashboards * *: Vi forbedrer vores metrics eksportør dashboards for at give klarere, hurtigere synlighed i kø sundhed og eksport fejlrater, hvilket muliggør hurtigere detektion og diagnose af lignende spørgsmål. * * * Forbedre alarmaggregering * *: Vi gennemfører automatisk alarmgruppering, så en regional hændelse, der påvirker flere klynger, bedre kommer frem som en enkelt korreleret hændelse og behandles med passende strenghed og opmærksomhed. * * * Proaktiv advarsel om fejlrater ved indtagelse: * * Vi tilføjer dedikerede advarsler, at brand på forhøjede GMP indtagelse fejlrater, giver vores team et tidligere signal, før eksportør køer nå kapacitet. Disse forbedringer er designet til at reducere detekteringstid, forenkle hændelsesforløb, og styrke vores metrics rørledning mod fremtidige opstrøms-udbyder forstyrrelser.

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)