Istoricul incidentelor Neo4j Aura

1. 26 octombrie 2026 la 14:50 UTCinvestigating

   În prezent, suntem conştienţi de o problemă care afectează clienţii care utilizează Aura pe Azure, atunci când încearcă să descarce instantaneele din baza de date.

2. 26 octombrie 2026 la 15:09 UTCidentified

   Am identificat problema și lucrăm în prezent la implementarea fixului.

3. 26 octombrie 2026 la 16:22 UTCidentified

   Fixarea este în prezent testată în medii inferioare, înainte de a fi implementată.

4. 26 octombrie 2026 la 17:43 UTCidentified

   Testarea fix este în curs de desfășurare și implementarea va continua odată ce testarea a fost finalizată.

5. 26 octombrie 2026 la 19:14 UTCresolved

   Inginerii noștri au implementat cu succes o fix, și problema este acum rezolvată. Clienții Aura de pe Azure pot descărca acum capturi de baze de date fără probleme.

Traducere automată din actualizarea oficială a incidentului.

1. 20 octombrie 2026 la 07:35 UTCinvestigating

   Investigăm în prezent o problemă care afectează regiunea Europa de Vest 2 din PCG, care afectează anumite operațiuni, inclusiv crearea de exemple de baze de date în regiune.

2. 20 octombrie 2026 la 08:36 UTCinvestigating

   Continuăm să investigăm problema în prezent, colaborând cu GCP pentru a găsi o rezoluție. În acest moment, unele operaţiuni, inclusiv crearea de instanţe de baze de date în regiune continuă să fie afectate.

3. 20 octombrie 2026 la 09:15 UTCidentified

   Am identificat sursa problemei care afectează în prezent clienții din Europa-Vest2 în ceea ce privește PCP. Mai multe detalii disponibile de la GCP statuspage la https://status.cloud.google.com/incidente/Xs2XTHzavC9YnafnPyzj. În acest moment, unele operaţiuni, inclusiv crearea de instanţe de baze de date în regiune continuă să fie afectate.

4. 20 octombrie 2026 la 10:42 UTCidentified

   Între timp, punem în aplicare măsuri de remediere pentru a atenua această problemă. A se vedea, de asemenea, Decizia nr.

5. 20 octombrie 2026 la 12:38 UTCmonitoring

   Funcţionalitatea ar trebui să fie restabilită acum în cadrul serviciilor Aura afectate. Vom monitoriza îndeaproape situația înainte de a lua în considerare acest lucru rezolvat.

6. 20 octombrie 2026 la 14:06 UTCmonitoring

   Continuăm să monitorizăm situația cu GCP în prezent și în acest moment nu am văzut noi probleme.

7. 20 octombrie 2026 la 14:50 UTCresolved

   Acest incident a fost rezolvat

Traducere automată din actualizarea oficială a incidentului.

1. 13 octombrie 2026 la 09:15 UTCinvestigating

   Investigăm o problemă care afectează indicatorii din Consola Aura şi prin intermediul obiectivului metric.

2. 13 octombrie 2026 la 10:13 UTCidentified

   Am identificat că o problemă legată de furnizorul de servicii de cloud computing afectează situația actuală. Am deschis un caz de suport cu Furnizorul de servicii Cloud și vom actualiza în continuare odată ce vom avea mai multe detalii.

3. 13 octombrie 2026 la 11:01 UTCmonitoring

   Credem că problema furnizorilor de servicii de cloud computing a fost rezolvată, deoarece nu mai vedem probleme din sistemele noastre interne. Vom continua să monitorizăm situația, în timp ce așteptăm confirmarea de la furnizorul de servicii Cloud.

4. 13 octombrie 2026 la 12:08 UTCresolved

   Am primit confirmarea de la Furnizorul de Cloud Service că problema a fost rezolvată pe deplin.

5. 16 octombrie 2026 la 17:06 UTCpostmortem

   **Errors when ending metrics from GCP europe-west1** Ce s-a întâmplat? Marți, 13 octombrie 2026 la 08:54 UTC, indicatorii pentru cazurile din GCP Europa-Vest1 au încetat să mai fie livrați și nu au putut fi citiți. Cauza a fost o problemă pe partea Google Cloud, în care o reducere a capacității în serviciul său de monitorizare a condus la respingerea incorectă a cererilor valabile. Metrics a revenit la normal la 10:49 UTC după ce Google Cloud a aplicat un fix, și am rezolvat incidentul la 12:08 UTC odată ce Google Cloud a confirmat rezoluția completă. Instituțiile au rămas disponibile pe parcursul acestui eveniment, fără niciun impact asupra performanței de interogare sau asupra integrității datelor. A fost afectată doar vizibilitatea indicatorilor. **Cum a fost afectat serviciul** Clienții au văzut câteva lacune scurte în indicatorii de exemplu: * **Metode de consolă:** Tribunalele din GCP Europa-Vest1 ar fi putut indica date metrice incomplete sau lipsă în timpul ferestrei incidentului. * **Monitorizarea Cloud Integrare \(CMI\):** Metricele transmise propriilor sisteme de monitorizare din această regiune ar fi putut avea, de asemenea, lacune. Nu toate cazurile din regiune au fost afectate, iar alți furnizori și regiuni de nori nu au fost afectate. Metricile generate în timpul incidentului nu au fost înregistrate, astfel încât decalajul va rămâne în diagrame istorice pentru cazurile afectate. **Ce facem acum** Fix a venit de la Google Cloud cu această ocazie, dar conducta noastră de indicatori s-a bazat pe o singură regiune, așa că luăm măsuri pentru a reduce această expunere: * ** Rezistenta regionala:** Evaluăm rutarea trans-regiunii astfel încât traficul metric să poată eşua într-o regiune sănătoasă. * **Trafic de rutare:** Explorăm opțiuni în stratul de rețea cloud pentru a redirecționa ambele citiri \ (Consolă și CMI\) și scrie \ (ingestiune\) departe de o regiune afectată.

Traducere automată din actualizarea oficială a incidentului.

1. 8 octombrie 2026 la 14:58 UTCinvestigating

   Investigăm o problemă cu indicatorii din Aura Console şi prin intermediul obiectivului metric.

2. 8 octombrie 2026 la 15:36 UTCidentified

   Continuăm să investigăm cauza principală. Problema este limitată la clienții de pe noi-central1 privind GCP Cazuri Aura sunt difuzate și nici o operație este afectată.

3. 8 octombrie 2026 la 16:30 UTCidentified

   Lucrăm cu furnizorul de servicii cloud pentru a investiga natura problemei. Controalele noastre confirmă faptul că doar un subset de clienți care rulează în regiunile noastre centrale1 sunt afectate.

4. 8 octombrie 2026 la 18:41 UTCidentified

   Continuăm să lucrăm cu furnizorul de servicii cloud pentru a obține o soluție.

5. 8 octombrie 2026 la 19:11 UTCresolved

   Acest incident a fost rezolvat acum, indicatorii ar trebui să funcționeze acum ca normal.

6. 16 octombrie 2026 la 17:04 UTCpostmortem

   **Errors when end metrics from GCP us-central1** Ce s-a întâmplat? Joi, 8 octombrie 2026 la 14:05 UTC, indicatorii din unele cazuri din GCP ne-central1 a încetat să mai fie livrate. Cauza a fost o problemă pe partea Google Cloud care a respins incorect cererile metrice valabile. Livrarea metrică reluată la ora 18:00 UTC după ce Google Cloud a aplicat un fix și am rezolvat incidentul la ora 18:48 UTC. Instituțiile au rămas disponibile pe parcursul acestui eveniment, fără niciun impact asupra performanței de interogare sau asupra integrității datelor. Numai vizibilitatea indicatorilor a fost afectată temporar. **Cum a fost afectat serviciul** Clienții au văzut lacune în indicatorii de exemplu: * **Metode de consolă:** Tribunalele din GCP ne-central1 ar fi putut indica date metrice incomplete sau lipsă în timpul ferestrei incidentului. * **Monitorizarea Cloud Integrare \(CMI\):** Metricele transmise propriilor sisteme de monitorizare din această regiune ar fi putut avea, de asemenea, lacune. Nu toate cazurile din regiune au fost afectate, iar alți furnizori de cloud și regiuni nu au fost afectate. **Ce facem acum** Fixarea a venit de la Google Cloud, dar luăm măsuri pentru a prinde și răspunde la evenimente similare mai devreme: * **Alertarea erorilor de livrare metrică:** Adăugăm alerta cu privire la ratele de eroare de transfer metric, astfel încât eșecurile furnizorului sunt detectate mai devreme și se disting de lacunele de rutină. * **Continuarea monitorizării:** Vom continua monitorizarea regiunii cu Google Cloud pentru orice recurență.

Traducere automată din actualizarea oficială a incidentului.

1. 6 octombrie 2026 la 09:22 UTCinvestigating

   Investigăm o problemă în care, în ciuda backup-urilor care se termină cu succes, descărcările instantanee returnează goluri. Restaurarea dintr-un instantaneu prin consola Aura sau API nu este considerată a fi afectată, și verificăm acest lucru acum. Vom împărtăși o actualizare de îndată ce vom avea mai multe informații.

2. 6 octombrie 2026 la 10:43 UTCinvestigating

   Continuăm să investigăm problema. Restaurarea operațiunilor nu sunt afectate ca parte a acestei probleme.

3. 6 octombrie 2026 la 13:41 UTCinvestigating

   Continuăm să investigăm această problemă.

4. 6 octombrie 2026 la 13:41 UTCinvestigating

   Continuăm să investigăm problema.

5. 6 octombrie 2026 la 15:19 UTCresolved

   A fost implementat un fix; descărcările instantanee conţin acum datele corespunzătoare.

6. 26 octombrie 2026 la 08:58 UTCpostmortem

   Ce s-a întâmplat Pe 18 septembrie 2026 14:33 UTC, am identificat că descărcările instantanee pentru cazurile Aura găzduite pe Azure returnau fişiere de aproximativ 24KB în loc de mărimea multi-gigabyte aşteptată. Backup-uri de bază stocate în Azure au fost dimensiunea corectă, dar calea de descărcare în consolă a fost de servire fişiere aproape goale. Cauza root a fost o problemă de acreditare Azure care a avut loc în timpul unei desfășurare și a împiedicat furnizarea de date de rezervă pentru descărcare. Un fix iniţial a fost implementat pe Mon, 21 sep 2026 10:31 UTC, restaurând dimensiunile corecte de descărcare. Cu toate acestea, aceeași problemă credibilă a reapărut pe Tue, 06 octombrie 2026 08:20 UTC, producând din nou descărcări instantanee pe toate nivelurile Azure. Echipa noastră de inginerie a identificat recurenţa, a legat-o de aceeaşi cauză de bază, a implementat un fix credibil pentru producţie şi a verificat dacă descărcările au revenit la mărimea lor aşteptată. Nu am postat pe pagina de stare pe 18 septembrie deoarece un număr mic de clienți au fost afectați, și am lucrat cu ei direct. Am postat pe 6 octombrie la 09:22 UTC, la aproximativ o oră după recidiva a început, odată ce a fost clar mai larg. Cum a fost afectat serviciul Descărcările prin sondaj au fost afectate pentru AuraDS Professional and Enterprise, AuraDB Professional, Business Critical and Virtual Dedicated Cloud instances running on Azure. * Descărcări Snapshot returnate fișiere inutilizabile. Atunci când clienţii au descărcat fotografii de pe consolă, au primit fişiere de aproximativ 24KB în loc de datele de rezervă reale, care ar putea fi mai multe gigabytes în mărime. Acest lucru a făcut ca fotografiile descărcate să nu poată fi utilizate pentru restaurarea sau migrarea offline. * Backup-urile nu au fost pierdute. Artefactele de rezervă stocate în Azure au rămas intacte și de dimensiuni corecte. Problema a fost strict în calea de descărcare, nu în procesul de captare sau stocare de rezervă. * Restaurarea prin intermediul consolei nu a fost afectată. In-platform restaura operațiunile \ [spre deosebire de descărcarea unui fișier de gunoi\) a continuat să funcționeze deoarece au accesat datele de rezervă direct, mai degrabă decât prin calea de descărcare afectată. Ce facem acum Am luat mai multe măsuri pentru rezolvarea problemei și am pus în aplicare garanții pentru prevenirea recurenței. * Remediul de acreditare este implementat. Am corectat problema de acreditare Azure în producție, care a restaurat imediat descărcări instantaneu pentru toate cazurile afectate. * Prevenirea rotaţiei neintenţionate. O schimbare de cod a fost prezentată pentru a reveni logica care a fost declanșarea rotației credibile Azure pe fiecare implementare. Acest lucru garantează că implementarea viitoare nu va invalida din greșeală acreditările existente, care a fost mecanismul care a cauzat atât incidentul inițial, cât și recurența acestuia. * Monitorizarea continuă. Monitorizăm descărcarea instantanee Azure pe toate nivelurile pentru a confirma că rămân stabile. Am cerut clienților afectați să verifice dacă descărcările lor returnează acum dimensiunile de fișiere preconizate. Aceste modificări abordează atât simptomul imediat, cât și comportamentul de implementare care a permis problema să reapară

Traducere automată din actualizarea oficială a incidentului.

1. 6 octombrie 2026 la 08:07 UTCidentified

   Am identificat o problemă când încercăm să refacem fotografiile de pe AuraDS. Avem un fix gata și va implementa acest lucru în curând. Între timp, poţi restaura de la o rezervă.

2. 6 octombrie 2026 la 09:07 UTCidentified

   Am identificat în mod clar cauza principală și continuăm să lucrăm la o soluție pentru această problemă.

3. 6 octombrie 2026 la 10:03 UTCidentified

   Continuăm să lucrăm la o soluţie pentru această problemă.

4. 6 octombrie 2026 la 12:14 UTCidentified

   Un fix este în curs de desfășurare și va rula la clienții afectați în scurt timp.

5. 6 octombrie 2026 la 13:35 UTCmonitoring

   Fix este de rulare și clienții afectați ar trebui să vadă funcționalitatea restabilită progresiv.

6. 6 octombrie 2026 la 14:04 UTCresolved

   Am trimis fix la toți clienții.

7. 26 octombrie 2026 la 08:51 UTCpostmortem

   Ce s-a întâmplat Un defect software într-o componentă centrală de management a Neo4j Aura instantaneu restaurează pentru a eșua pentru AuraDS Professional și AuraDS Enterprise cazuri găzduite pe AWS. În cazul în care s-a solicitat o restaurare, sistemul a analizat cazul folosind un tip de resursă incorect și a returnat o eroare. Incidentul a fost declarat luni, 05 octombrie 2026 21:52 UTC. Echipa noastră de inginerie a identificat cauza principală, a dezvoltat și validat un fix, și l-au desfășurat la producție marți, 06 octombrie 2026 13:37 UTC. Cum a fost afectat serviciul Impactul a fost pus în aplicare pentru a instantaneu restaurarea operațiunilor pentru AuraDS Professional and AuraDS Enterprise instances. Clienţii afectaţi nu au reuşit să refacă fotografiile prin Aura Console sau Aura API pe durata emisiunii. * Restaurarea încercărilor de erori returnate, perturbarea fluxurilor de lucru care depind de instantanee restaurează. *Instanțele au rămas disponibile pe parcursul acestui eveniment. Integritatea datelor nu a fost afectată. Restaurarea de la backup-uri complete și exportate a rămas disponibil ca un workaround. Ce facem acum * Am fixat defectul în stratul de management al Aurei care a afectat AuraDS Professional și AuraDS Enterprise instantaneu restaurează și a implementat fix la producție. * Optimizarea conductei de desfăşurare: În timpul acestui incident, conducta de desfăşurare a durat mai mult decât ideal datorită creării secvenţiale a instanţelor de testare. Am evaluat crearea în paralel a instanţei de testare pentru a reduce timpul de aşteptare în timpul desfăşurărilor critice. Această îmbunătăţire are ca scop scurtarea timpului necesar pentru validarea şi transportul unui fix în incidentele viitoare, reducând impactul asupra clienţilor

Traducere automată din actualizarea oficială a incidentului.

1. 17 septembrie 2026 la 16:46 UTCinvestigating

   Suntem în prezent conștienți de o problemă care afectează anumite operațiuni de baze de date, cum ar fi crearea, ștergerea, clona pentru clienții care utilizează Aura pe Azure.

2. 17 septembrie 2026 la 17:11 UTCidentified

   Am identificat problema și lucrăm la găsirea unei soluții. În acest moment, anumite operațiuni de baze de date, cum ar fi crearea, ștergerea și clona pentru clienții care utilizează Neo4j Aura numai pe Azure, continuă să fie afectate.

3. 17 septembrie 2026 la 19:06 UTCmonitoring

   Un fix a fost implementat în toate mediile afectate. Vom monitoriza situația pentru a ne asigura că fix rezolvă pe deplin problema.

4. 17 septembrie 2026 la 19:55 UTCresolved

   După ce am pus în aplicare fix, am monitorizat cazurile afectate, indicatorii operaționali și erorile. Acest incident este acum rezolvat. O post-mortem va fi disponibil imediat ce acesta a fost finalizat.

5. 16 octombrie 2026 la 16:23 UTCpostmortem

   Ce s-a întâmplat Joi, 17 septembrie 2026 la 13:52 UTC, un conflict de desfăşurare-timp între operaţiunile simultane a dus la eliminarea unei credibilităţi utilizate de o componentă principală Aura pentru autentificarea cu infrastructura găzduită de Azure. Deoarece jetoanele de autentificare existente au expirat, componenta a început să returneze erori pentru unele cazuri Aura găzduite pe Azure, afectând anumite operațiuni de baze de date. Am urmărit erorile până la acreditarea lipsă, am creat una nouă, am depozitat-o în siguranţă şi am realizat o desfăşurare la rulare a componentei afectate, care s-a încheiat la 18:39 UTC. Un număr mic de cereri de creare de baze de date care au fost în curs în timpul întreruperii au fost lăsate într-o stare incompletă și de remediere manuală necesară. Acest lucru a fost finalizat la 19:48 UTC, iar incidentul a fost marcat rezolvat la 19:55 UTC. Cum a fost afectat serviciul Impactul a fost limitat la cazurile Aura găzduite pe Azure. Alți furnizori de nori nu au fost afectați. * ** Operaţiuni de bază de date:** Clienţii nu au reuşit să efectueze anumite operaţiuni de baze de date, cum ar fi crearea, ştergerea şi clona, în unele cazuri Azure în timpul ferestrei incidentului. Un număr mic de creaţii aflate în desfăşurare au rămas blocate şi au fost recuperate manual. * ** Vizibilitate managerială:** Unele cazuri găzduite de Azure nu au fost temporar vizibile sau gestionabile în Aura Console. * **Porţiuni de date:** Criteriile de evaluare metrică pentru unele cazuri de Azure au revenit erori intermitente, lăsând lacune scurte în datele privind indicatorii pentru perioada afectată. Aceste date nu vor fi completate. Cazurile de azură care erau deja în desfăşurare au rămas disponibile şi au continuat să servească în mod normal la muncă. Ce facem acum Luăm următoarele măsuri pentru a preveni repetarea și a îmbunătăți răspunsul nostru: * **Detecţia şi comunicarea anterioare:** Vom îmbunătăţi monitorizarea şi alertarea şi vom evalua verificările credibile automate, astfel încât problemele sunt detectate şi clienţii sunt informaţi mai repede. * ** Recovery from incomplete database creation:** Vom repara un defect care poate lăsa o bază de date de creare blocată în cazul în care un apel de infrastructură nu reușește partway prin intermediul, astfel încât sistemul se recuperează pe cont propriu. * ** Autentificare revizuire:** Vom analiza modul în care această componentă autentifică furnizorii de cloud, pentru a elimina punctele unice de eșec și pentru a reduce riscul de acest tip de conflict recurent.

Traducere automată din actualizarea oficială a incidentului.

1. 16 septembrie 2026 la 08:50 UTCidentified

   Furnizorul nostru de servicii pentru portalul de sprijin se confruntă cu unele întreruperi - A se vedea https://status.salesforce.com/products/Salesforce Services Dacă aveți probleme de depunere a unui nou caz de suport, vă rugăm să trimiteți e-mail la [email protected]

2. 16 septembrie 2026 la 09:16 UTCidentified

   Furnizorul nostru de portaluri de sprijin încă lucrează la abordarea problemei. A se vedea aici detaliile https://status.salesforce.com/incidente/20004433

3. 16 septembrie 2026 la 10:11 UTCidentified

   Furnizorul nostru de portaluri de sprijin continuă să lucreze la abordarea problemei. A se vedea aici detaliile https://status.salesforce.com/incidente/20004433

4. 16 septembrie 2026 la 11:30 UTCmonitoring

   Un fix este în curs de desfășurare și portalul ar trebui să devină mai puțin afectat de erori în timp. A se vedea detaliile https://status.salesforce.com/incidente/20004433

5. 16 septembrie 2026 la 12:29 UTCmonitoring

   Furnizorul nostru de portaluri de sprijin continuă să-şi rezolve problemele.

6. 16 septembrie 2026 la 14:31 UTCresolved

   Un fix a fost implementat și toate funcționalitățile ar trebui să fie acum recuperate.

Traducere automată din actualizarea oficială a incidentului.

1. 9 septembrie 2026 la 12:31 UTCinvestigating

   Investigăm în prezent o problemă care afectează consola Aura.neo4j.io și API api.neo4j.io

2. 9 septembrie 2026 la 12:54 UTCidentified

   Am identificat sursa problemei și lucrăm în prezent la o soluție.

3. 9 septembrie 2026 la 13:10 UTCidentified

   Continuăm să lucrăm la abordarea problemei.

4. 9 septembrie 2026 la 13:26 UTCidentified

   Am făcut progrese bune și recuperăm componenta problematică.

5. 9 septembrie 2026 la 13:36 UTCmonitoring

   Am implementat o soluţie şi serviciile afectate se recuperează.

6. 9 septembrie 2026 la 13:39 UTCresolved

   Toate componentele afectate sunt acum complet recuperate.

Traducere automată din actualizarea oficială a incidentului.

1. 3 septembrie 2026 la 16:43 UTCinvestigating

   În prezent investigăm această problemă.

2. 4 septembrie 2026 la 10:23 UTCidentified

   Problema a fost identificată, există în continuare cazuri disponibile și măsuri de soluționare a cazurilor cu impact care au fost revizuite în prezent.

3. 4 septembrie 2026 la 15:36 UTCresolved

   Toate cazurile sunt disponibile, au fost întreprinse etape manuale pentru a debloca numărul mic de cazuri rămase.

Traducere automată din actualizarea oficială a incidentului.

1. 20 august 2026 la 15:49 UTCinvestigating

   Echipa noastră a identificat o problemă cu colectarea indicatorilor pentru cazurile Aura. Acest lucru va afecta vizibilitatea metrică și transmiterea. În prezent investigăm problema.

2. 20 august 2026 la 16:48 UTCinvestigating

   Continuăm să investigăm problema cu Aura.

3. 20 august 2026 la 19:10 UTCresolved

   De la ultima actualizare, ancheta a trecut mai departe. Problema a fost identificată şi am monitorizat serviciul pe măsură ce s-a recuperat din degradare. Confirmăm că problema este rezolvată acum.

4. 17 septembrie 2026 la 10:09 UTCpostmortem

   Ce s-a întâmplat Joi, 20 Aug 2026 14:58:00 UTC, conducta noastră de ingestie a indicatorilor a început să se confrunte cu eșecuri ridicate de export atunci când trimiteți date la Google Managemented Prometeu \(GMP\). Cauza de bază a fost un incident de servicii Google Cloud Platform în regiunea "us-west1," care a perturbat calea de export utilizată de infrastructura noastră de colectare a taxelor. Ca urmare, cozile metrice de export au început să se acumuleze pe un subset de medii de producție. Esecurile s-au manifestat în primul rând ca timeout-uri de rețea atunci când încearcă să livreze date metrice la GMP, prevenind ingestie normală pentru grupurile afectate. Echipa noastra de inginerie a identificat concentrarea geografica a sistemelor afectate Spanning AWS Odată ce incidentul regional al GCP a fost atenuat de Google, erorile de export s-au diminuat și cozile au început să se scurgă. Cum a fost afectat serviciul Impactul s-a limitat la vizibilitate **metrică** pentru un subset de medii Aura. Aproximativ 45 de medii de clienți au fost afectate, ceea ce înseamnă că datele metrice din bazele de date nu au fost ingerate în platforma noastră de monitorizare în timpul ferestrei incidentului. Regiunea cea mai afectată a fost AWS Clienții cu baze de date în aceste regiuni ar fi putut experimenta lacune în tabloul lor de bord al indicatorilor și date de monitorizare pe durata incidentului. Operaţiuni de bază de baze de date Odată ce Google a atenuat problema regională de bază, ingerarea metrică a fost reluată și a fost procesată backlog-ul datelor la coadă. Ce facem acum Am efectuat o analiză aprofundată a acestui incident și luăm următoarele măsuri pentru a îmbunătăți capacitatea noastră de reziliență și reacție: * ** Impoveded observabilitate borduri**: Ne îmbunătăţim tabloul de bord al exportatorului pentru a oferi vizibilitate mai clară, mai rapidă în sănătatea cozii şi ratele de eroare la export, permiţând detectarea şi diagnosticarea mai rapidă a unor probleme similare. * ** Imbunatatirea activitatii de alerta**: Implementăm gruparea automată de alertă, astfel încât un incident regional care afectează mai multe grupuri să fie mai bine expus ca un eveniment unic corelat și tratat cu severitate și atenție corespunzătoare. * ** Alertarea proactivă a ratelor de eroare de ingestie:** Adăugăm alerte dedicate că focul asupra ratelor ridicate de eroare de ingerare a GMP, oferind echipei noastre un semnal mai devreme înainte ca cozile exportatorului să ajungă la capacitate. Aceste îmbunătățiri sunt concepute pentru a reduce timpul de detectare, a simplifica triajul incidentului și a consolida conducta noastră de indicatori împotriva perturbărilor viitoare ale furnizorilor din amonte.

Traducere automată din actualizarea oficială a incidentului.

1. 5 august 2026 la 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 la 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 la 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 la 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 la 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 la 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 la 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 la 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 la 09:44 UTCidentified

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

10. 7 august 2026 la 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 la 15:34 UTCresolved

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

Traducere automată din actualizarea oficială a incidentului.

1. 23 iulie 2026 la 10:52 UTCinvestigating

   Investigăm o problemă în acest moment.

2. 23 iulie 2026 la 11:08 UTCinvestigating

   Lucrăm cu echipe de ingineri şi facem progrese cu investigaţiile în prezent.

3. 23 iulie 2026 la 11:24 UTCinvestigating

   Lucrăm cu echipe de ingineri şi continuăm să facem progrese cu investigaţiile în prezent.

4. 23 iulie 2026 la 11:38 UTCidentified

   Am identificat cauza problemei actuale și lucrăm activ la fix în prezent.

5. 23 iulie 2026 la 11:53 UTCidentified

   Implementăm prima parte a fixării și continuăm să lucrăm activ la găsirea soluției complete. Aşteptăm un ETA în ordine de 1 oră de acum.

6. 23 iulie 2026 la 12:11 UTCidentified

   Am identificat subgrupul de cazuri care au avut impact și continuă să se desfășoare fixarea în acest moment.

7. 23 iulie 2026 la 12:32 UTCidentified

   Am implementat o fixare a configuraţiei şi acum lucrăm la rezolvarea subsetului de cazuri afectate.

8. 23 iulie 2026 la 12:49 UTCidentified

   Odată cu configurarea fixată, continuăm să rezolvăm subgrupul de cazuri afectate.

9. 23 iulie 2026 la 14:07 UTCidentified

   Continuăm să rezolvăm subgrupul de cazuri afectate.

10. 23 iulie 2026 la 14:27 UTCidentified

    Continuăm să rezolvăm subgrupul de cazuri care sunt încă afectate.

11. 23 iulie 2026 la 14:44 UTCmonitoring

    Continuăm să rezolvăm subgrupul de cazuri care sunt încă afectate.

12. 23 iulie 2026 la 15:03 UTCmonitoring

    AuraDB Virtual Dedicate Cloud și AuraDB Business Critical ar trebui să fie acum toate fixe. Continuăm să rezolvăm subgrupul de cazuri care sunt încă afectate pentru AuraDB Professional și Free.

13. 23 iulie 2026 la 15:29 UTCmonitoring

    Continuăm să rezolvăm subgrupul de cazuri care sunt încă afectate pentru AuraDB Professional și Free.

14. 23 iulie 2026 la 15:57 UTCmonitoring

    Continuăm să rezolvăm subgrupul de cazuri care sunt încă afectate pentru AuraDB Professional și Free.

15. 23 iulie 2026 la 16:32 UTCmonitoring

    Continuăm să rezolvăm subgrupul de cazuri care sunt încă afectate pentru AuraDB Professional și Free

16. 23 iulie 2026 la 17:01 UTCmonitoring

    Continuăm să fixăm un subset de cazuri care sunt încă afectate pentru AuraDB Professional și Free

17. 23 iulie 2026 la 17:31 UTCmonitoring

    Continuăm să fixăm un subset mic de cazuri care sunt încă afectate de nivelurile profesionale și gratuite AuraDB.

18. 23 iulie 2026 la 18:07 UTCmonitoring

    Am abordat problema în toate cazurile profesionale AuraDB. Aura Free poate fi încă afectată. Vom continua să monitorizăm și să reparăm bazele de date rămase.

19. 23 iulie 2026 la 19:39 UTCmonitoring

    Continuăm să fixăm un subset mic de cazuri libere care sunt încă afectate.

20. 24 iulie 2026 la 06:00 UTCmonitoring

    Continuăm să monitorizăm îndeaproape situaţia pentru orice alte probleme.

21. 24 iulie 2026 la 08:30 UTCmonitoring

    Continuăm să monitorizăm orice alte probleme.

22. 24 iulie 2026 la 12:59 UTCmonitoring

    Toate cazurile identificate au fost rezolvate, continuând să monitorizeze. Contactaţi clienţii pentru orice alte probleme.

23. 24 iulie 2026 la 15:56 UTCresolved

    Toate remediile au fost implementate și problema este acum marcată ca rezolvată.

24. 29 iulie 2026 la 21:58 UTCpostmortem

    Ce s-a întâmplat? Joi, 23 iul, 2026 10:33 UTC a fost implementată o schimbare de configurație în Aura care a modificat involuntar modul în care alocările de memorie au fost calculate pentru cazurile de baze de date. Ca urmare, un subset de cazuri au primit memorie insuficientă, determinând unele cazuri de baze de date să devină indisponibile sau incapabile să completeze actualizările. Alocarea de memorie ajustată a dus la condiții out-of-memory, ceea ce a determinat cazuri de baze de date să repornească în mod repetat din cauza resurselor insuficiente de memorie sau să devină blocat actualizarea. Această problemă a afectat cazurile din rândul mai multor furnizori de cloud și al mai multor niveluri de produs. Odată ce problema a fost identificată, am revenit imediat schimbarea configurației, împiedicând orice situații suplimentare să primească configurația incorectă. O configuraţie corectată a fost trimisă la producţie până joi, 23 iul, 2026 11:56 UTC. Cu toate acestea, cazurile de baze de date care au primit deja configurația incorectă au necesitat acțiuni individuale de recuperare înainte ca acestea să poată reveni la funcționarea normală. Până joi, 23 iul, 2026 17:59 UTC, toate cazurile cunoscute de baze de date cu impact asupra clienților au fost recuperate. Monitorizarea a continuat până în ziua următoare, incidentul fiind complet rezolvat vineri, 24 iulie 2026 16:30 UTC. Cum a fost afectat serviciul Impactul principal al clientului a fost că mai multe cazuri din baza de date AuraDB au devenit indisponibile sau au intrat într-o stare degradată. Cazurile afectate nu au putut completa actualizările de rutină ale software-ului și, în unele cazuri, au fost reluate în mod repetat, deoarece memoria insuficientă fusese alocată. * ** Disponibilitatea serviciului:** Impactul clientului a variat în funcție de nivelul serviciilor. Cazuri profesionale AuraDB, care nu oferă disponibilitate ridicată, experimentat cel mai mare nivel de întrerupere a serviciului, cu un subset devenind indisponibil și incapabil să proceseze citiri sau scrie. Pentru cazurile afectate de AuraDB Business Critical and Virtual Dedicated Cloud \ (VDC\), impactul s-a limitat, în general, la o pierdere temporară a toleranței la defecțiuni în timp ce disponibilitatea serviciilor a fost menținută. Într-un număr mai mic de cazuri, cazurile critice de afaceri și cele VDC au devenit, de asemenea, indisponibile. * **Stuck actualizări**: Cazuri suplimentare au rămas disponibile, dar au fost blocate într-o stare de "actualizare," care a blocat operațiunile inițiate de client, cum ar fi redimensionări sau modificări de configurare. * **Cross-platform domeniu de aplicare**: Impactul a cuprins toți cei trei furnizori de cloud și mai multe regiuni sprijinite, afectând clienții la nivel mondial. Au fost ridicate cazuri de asistență a clienților și echipa noastră a triat și recuperat manual cazuri afectate în ordine prioritară. Majoritatea cazurilor de AuraDB au continuat să funcționeze normal. Impactul asupra clienților a fost atenuat pe deplin prin revenirea configurației și recuperarea manuală orientată a fiecărei situații afectate. Ce facem acum Am efectuat o analiză aprofundată a acestui incident și am identificat următoarele acțiuni: * **Prevenire** * ** Validarea implementării dovedită:** Ne consolidăm procesul de validare a eliberării pentru a identifica mai bine modificările de configurare. * **Decuplare Component**: Evaluăm îmbunătățirile aduse secvențierii implementării componentelor pentru a reduce riscul ca modificările nedorite să fie incluse în versiuni. * ** Strategia de lansare progresivă**: Revizuim procesul de lansare a componentelor afectate, pentru a le alinia la controalele de lansare utilizate pentru alte componente critice. * **Detecţie** * ** Mai bine alertarea**: Suntem îmbunătățirea monitorizării noastre pentru a detecta creșteri anormale ale ratelor de eșec \ (cum ar fi pierderea toleranței de defect sau disponibilitatea\) mai rapid și fiabil. * **Contenţionarea** * ** Desfășurarea configurației Safer:** Îmbunătățim modul în care sunt implementate schimbările de configurare a producției, astfel încât acestea să poată fi dezactivate sau laminate mai repede fără a necesita o versiune software mai largă. * **Recuperare manuală mai rapidă**: Ne îmbunătăţim instrumentele de recuperare pentru a reduce timpul necesar identificării şi recuperării manuale a cazurilor afectate. Recunoastem intreruperea acestui incident si ne cerem scuze pentru impactul asupra clientilor afectati. Am finalizat acțiunile corective imediate, iar îmbunătățirile pe termen lung descrise mai sus sunt deja în curs de desfășurare pentru a reduce probabilitatea și impactul unor incidente similare în viitor.

Traducere automată din actualizarea oficială a incidentului.

1. 10 iulie 2026 la 17:18 UTCinvestigating

   Investigăm în prezent o problemă care afectează Consola Aura, unde unii clienți ar putea fi în imposibilitatea de a vedea cazurile lor. Această problemă este cauzată de un eșec într-un serviciu terț de care depinde Aura. Cazurile afectate continuă să funcționeze normal, iar conectivitatea bazei de date nu este afectată. Echipa noastră investighează în mod activ problema.

2. 10 iulie 2026 la 17:23 UTCinvestigating

   Continuăm să investigăm această problemă.

3. 10 iulie 2026 la 17:51 UTCmonitoring

   Serviciul terţ de care depinde Aura a restabilit operaţiunile normale şi sistemele Neo4j Aura s-au recuperat. Echipa noastră monitorizează în mod activ problema pentru a confirma că Aura Console evoluează conform aşteptărilor.

4. 10 iulie 2026 la 19:23 UTCresolved

   Serviciile sunt confirmate a fi operaționale și nu se așteaptă alte întreruperi.

5. 27 iulie 2026 la 04:28 UTCpostmortem

   ## What happened Aura Console și alte componente Aura s-au confruntat cu întreruperi la 2026-07-10 la 16:14 UTC, ceea ce a dus la eșecuri și la prăbușiri. În consecință, un segment de clienți s-a confruntat cu probleme de vizibilitate în ceea ce privește cazurile lor. Acesta a fost cauzat de o pană de curent într-un serviciu extern al terților integrat cu Aura. În mod esențial, conectivitatea bazei de date a rămas necompromisă, iar cazurile afectate și-au continuat operațiunile normale. LansareÎntuneric serviciu a fost restaurat pentru a rezolva problema ## Cum serviciul a fost afectat Multiple componente Aura, inclusiv Aura Console, au suferit întreruperi. Utilizatorii au întâlnit erori HTTP 500 pe paginile și operațiunile legate de baze de date, deși organizațiile și proiectele ar putea fi încă accesate. Conexiunile directe la anumite cazuri de baze de date nu au fost afectate complet Avionul de control a devenit indisponibil, ceea ce a însemnat că utilizatorii nu au putut crea, șterge, redimensiona sau ajusta setările pentru situații prin intermediul API sau consola Aura. Cu toate acestea, cazurile existente au rămas operaționale. Problema a fost cauzată de o pană de curent la LaunchDarkly, iar serviciile noastre nu s-au ocupat cu graţie de această dependenţă în timpul startup-ului. Toate sistemele afectate au revenit la funcționarea normală până la 2026-07-10 la 17:07 UTC ## Ce facem acum Echipa de Inginerie Neo4j a diagnosticat rapid cauza rădăcină și a restaurat serviciul. În evaluarea acestui incident, am identificat domenii-cheie pentru accelerarea rezoluțiilor viitoare și atenuarea riscurilor de recurență: * Indicatori cheie analizați ai incidentelor, concentrându-se pe durata de alertă la răspuns pentru a identifica oportunitățile de accelerare a eficienței răspunsului * Desfășurat o retrospectivă cuprinzătoare evidențiind rezultate de succes, inclusiv analiza rapidă a cauzelor prin exploatarea transparentă, alinierea fără probleme prin intermediul instrumentului de gestionare a incidentelor, și degradarea rezilientă, grațioasă a mai multor componente care au păstrat intactă conectivitatea planului de date * Dezvoltarea în mod activ mai grațios Fallback implicits pentru steaguri caracteristică pentru a proteja operațiunile de bază în timpul descărcărilor vânzătorului * Consolidarea rezilienței arhitecturale prin integrarea practicilor avansate de planificare, inginerie haos, precum și testarea injecției de defecte la nivelul producției pentru a descoperi preventiv și a atenua potențialele căi de eșec * Limitările logice abordate în cacheul de pavilion caracteristică operatorului, subliniind necesitatea operatorilor de a stoca steaguri evaluate la nivel local pentru a menține continuitatea operațională în cazul în care dependențe externe nu.

Traducere automată din actualizarea oficială a incidentului.

1. 30 iunie 2026 la 14:45 UTCidentified

   Rularea VECTOR INDEX nu reușește cu eroare 51N31 eroare: configurarea sistemului sau excepția de funcționare - nu este susținută. Crearea unui indice vectorial cu setările furnizate nu este susținută în V2026 02. Versiunea necesară pentru operație este V2026 06. Vă rugăm să actualizați DBMS .. Aceasta afectează doar un nou indice, VECTOR INDEX existent nu este afectată. Orice indice vectorial creat înainte de 2026-06-30 la ora 09:00 continuă să funcționeze normal.

2. 30 iunie 2026 la 15:41 UTCidentified

   Începem acum să punem în aplicare un fix pentru a aborda această problemă și va oferi în curând o actualizare a progreselor înregistrate.

3. 30 iunie 2026 la 16:05 UTCmonitoring

   Un fix este de rulare și progresează bine. Vom face progrese.

4. 30 iunie 2026 la 17:45 UTCresolved

   Fixarea a fost pe deplin implementată în toate cazurile afectate. Acest incident este acum rezolvat.

5. 20 iulie 2026 la 08:40 UTCpostmortem

   ## What happened O problemă a fost identificată ca urmare a implementării versiunii 2026.06 la 2026-06-30 la ora 08:00 UTC, în cazul în care rulează VECTOR INDEX Acest eșec în generarea de indici a avut loc deoarece magazinul de bază și nucleul necesita actualizări suplimentare pentru a sprijini operațiunea Această problemă a afectat doar crearea de noi indici; indicii vectori existenţi nu sunt afectaţi. Orice indice vectoric creat înainte de ora 09:00 pe 2026-06-30 nu a fost afectat și a continuat să funcționeze normal. ## Cum serviciul a fost afectat Ca urmare a introducerii versiunii 2026.06, executarea declaraţiei CREATE VECTOR INDEX a eşuat, influenţând aplicaţiile care depind de adăugarea de noi indici vectori. Clienții afectați au primit eroarea: Crearea unui indice vectorial cu setările furnizate nu este suportată în V2026\ 02. Versiunea necesară pentru operare este V2026\ 06. Te rog upgrade DBMS . Indicele existent \ (creat înainte de acest incident\) și alte întrebări au rămas complet neafectate și complet funcționale. ## Ce facem acum Echipele Neo4j au identificat cauza rădăcină ca fiind o eroare în Planificatorul Cypher și au rezolvat problema cu o fixare de cod. Acest fix a fost implementat în toate cazurile Aura afectate, rezolvarea completă a erorii Pentru a preveni apariţiile viitoare, ne îmbunătăţim sistemele de monitorizare şi alertă pentru a detecta probleme similare mai devreme, în special în mediile de pregătire, înainte de apariţia rollout-urilor. Simultan, ne perfecționăm procesele de implementare pentru a minimiza impactul clienților și timpul de recuperare În plus, investigăm opțiuni de implementare a testelor automatizate de validare post-actualizare specifice operațiunilor critice, cum ar fi crearea de indici vectori

Traducere automată din actualizarea oficială a incidentului.

1. 23 iunie 2026 la 11:25 UTCidentified

   Aura consola se confruntă cu unele erori intermitente: "Sistemul nostru se confruntă cu probleme chiar acum. încearcă din nou mai târziu sau contactează suportul dacă problema persistă." Acest lucru vă poate cere să reîncărcați sau să așteptați mai mult pentru navigarea în consolă Operațiunile și Aura API rămân neafectate Lucrăm activ la o rezolvare

2. 23 iunie 2026 la 13:03 UTCidentified

   Continuăm să investigăm o rezolvare a problemei

3. 23 iunie 2026 la 13:39 UTCidentified

   Continuăm să lucrăm la o soluție pentru această problemă.

4. 23 iunie 2026 la 15:43 UTCmonitoring

   Derulăm o schimbare. Vom monitoriza și actualiza.

5. 23 iunie 2026 la 19:27 UTCmonitoring

   Continuarea monitorizării modificărilor implementate. Următoarea actualizare aşteptată la 6/24/2026 10am UTC.

6. 24 iunie 2026 la 09:14 UTCmonitoring

   Am verificat și confirmăm faptul că problema este acum pe deplin abordată.

7. 24 iunie 2026 la 09:14 UTCresolved

   Acest incident a fost rezolvat.

8. 10 iulie 2026 la 14:50 UTCpostmortem

   ## What happened La aproximativ 12:00 UTC pe 22 ianuarie 2026, utilizatorii au întâlnit bannere intermitente de eroare în consola Aura care afișează: "Avem o problemă. Încercați din nou.," care a apărut alături de 500 de erori de la criteriile finale ale consolei API. Aceste întreruperi au fost tranzitorii și cauzate de sincronizare internă API în timpul procesului de strângere de mână TLS, de obicei rezolva în aproximativ 10 secunde sau după o reîmprospătare pagină ## Cum serviciul a fost afectat Aura Console și Aura API au experimentat performanțe degradate, care s-au manifestat ca bannere intermitente de eroare în consola Aura UI. O anchetă a identificat cauza rădăcină ca fiind utilizarea ridicată a procesorului și trepidarea în consola API. Această problemă a fost determinată în primul rând de liste repetate de entități mari și cereri costisitoare de reconciliere Pentru a aborda această problemă, au fost implementate cu succes soluții specifice atât pentru consola Aura, cât și pentru Aura API. Acest lucru a fost urmat de ajustări ale configurației resurselor pentru a crește sediul operațional și a asigura stabilitatea ## Ce facem acum Au fost puse în aplicare următoarele măsuri reactive și proactive pentru a reduce probabilitatea unor incidente similare: * Dezvoltat un tablou de bord de monitorizare pentru a observa picăturile de cerere bazate pe datele interne API jurnal pentru a implementa monitorizarea automată și alertarea la probleme de captură înainte ca acestea să apară * Implementat o întârziere stagnată între cererile de reconciliere paginate pentru a atenua consumul ridicat de resurse și pentru a îmbunătăți stabilitatea API * Calcule de resurse pentru îmbunătăţirea performanţei * A introdus un nou filtru pentru întrebări bazate pe niveluri de service pentru a optimiza cheltuielile CPU pentru fiecare apeluri efectuate de conciliator * Deactivat cerere redundantă de procesare Middleware pentru a optimiza apeluri API

Traducere automată din actualizarea oficială a incidentului.

1. 26 mai 2026 la 18:23 UTCinvestigating

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

2. 26 mai 2026 la 19:19 UTCmonitoring

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

3. 26 mai 2026 la 23:06 UTCresolved

   This incident has been resolved.

4. 9 iunie 2026 la 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 martie 2026 la 10:18 UTCidentified

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

2. 6 martie 2026 la 10:24 UTCmonitoring

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

3. 6 martie 2026 la 10:25 UTCresolved

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

4. 30 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 04:52 UTCidentified

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

4. 4 martie 2026 la 14:07 UTCmonitoring

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

5. 4 martie 2026 la 15:19 UTCresolved

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

6. 8 aprilie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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)