Problema che colpisce determinate operazioni di database per i clienti Aura su Azure
Inizio 26 ottobre 2026 alle ore 14:50 UTC · 4h 23m
IssuesIncidente minore
Componenti interessati
AuraDB Business Critical (*.databases.neo4j.io) on AzureAuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDS on Azure (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on Azure (*.databases.neo4j.io)AuraDB Professional on Azure (*.databases.neo4j.io)Aura API (api.neo4j.io)
investigating
Siamo attualmente a conoscenza di un problema che sta influenzando i clienti utilizzando Aura su Azure, quando si tenta di scaricare le istantanee delle istanze di database.
identified
Abbiamo identificato il problema e stiamo attualmente lavorando sull'implementazione della correzione.
identified
La correzione è attualmente in fase di test in ambienti inferiori, prima di essere utilizzata.
identified
La prova della correzione è in corso e la distribuzione procederà una volta che il test è stato completato.
resolved
I nostri ingegneri hanno implementato con successo una soluzione, e il problema è risolto. I clienti di Aura su Azure possono ora scaricare le snapshot del database senza problemi.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
GCP - Europe West 2 - Partial Outage
Inizio 20 ottobre 2026 alle ore 07:35 UTC · 7h 14m
OutageIncidente maggiore
Componenti interessati
AuraDB Virtual Dedicated Cloud on GCP (*.databases.neo4j.io)AuraDS on GCP (*.databases.neo4j.io)AuraDB Professional on GCP (*.databases.neo4j.io)AuraDS Enterprise on GCP (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on GCP
investigating
Stiamo attualmente indagando su un problema che riguarda la regione Europa occidentale 2 in GCP che sta influenzando alcune operazioni, tra cui la creazione di istanze di database nella regione.
investigating
Stiamo continuando a indagare sul problema attualmente, lavorando con il GCP per trovare una risoluzione. In questo momento alcune operazioni, tra cui la creazione di istanze di database nella regione continuano a rimanere colpite.
identified
Abbiamo identificato la fonte del problema che interessa attualmente i clienti su europe-west2 su GCP.
Ulteriori dettagli disponibili da GCP statuspage a https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.
In questo momento alcune operazioni, tra cui la creazione di istanze di database nella regione continuano a rimanere colpite.
identified
Attualmente stiamo implementando azioni correttive per mitigare il problema nel frattempo.
Seguire le ultime novità da GCP nella pagina di stato https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.
monitoring
La funzionalità dovrebbe ora essere ripristinata attraverso i servizi Aura interessati. Noi monitoreremo la situazione da vicino prima di considerare questo risolto.
monitoring
Stiamo continuando a monitorare la situazione con GCP al momento attuale e a questo punto non abbiamo visto nuovi problemi.
resolved
Questo incidente è stato risolto
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Problema per alcuni clienti con metriche di istanza (endpoint e in Console)
Inizio 13 ottobre 2026 alle ore 09:15 UTC · 2h 53m
Stiamo indagando su un problema che colpisce metriche nella Console Aura e attraverso il punto finale metrico.
identified
Abbiamo identificato che un problema relativo a Cloud Service Provider sta influenzando la situazione attuale. Abbiamo aperto un caso di supporto con il Cloud Service Provider e si aggiornerà ulteriormente una volta che avremo maggiori dettagli.
monitoring
Crediamo che il problema del Cloud Service Provider sia stato risolto, poiché non vediamo più problemi dai nostri sistemi interni. Continueremo a monitorare la situazione, mentre aspettiamo la conferma da parte del provider Cloud Service.
resolved
Abbiamo avuto conferma dal Cloud Service Provider che il problema è stato risolto completamente.
postmortem
***Errori durante l'invio di metriche da GCP europe-west1**
Che e' successo?
Martedì 13 ottobre 2026 alle 08:54 UTC, metriche per le istanze in GCP europe-ovest1 smesso di essere consegnato e non poteva essere letto. La causa è stata un problema sul lato di Google Cloud, dove una riduzione della capacità nel suo servizio di monitoraggio ha portato a richieste valide non correttamente respinte. Metrics è tornato alla normalità a 10:49 UTC dopo Google Cloud applicato una correzione, e abbiamo risolto l'incidente a 12:08 UTC una volta Google Cloud ha confermato la risoluzione completa.
Instances rimase disponibile in tutto questo evento, senza alcun impatto per interrogare le prestazioni o l'integrità dei dati. Solo la visibilità metrica è stata influenzata.
"Come il servizio è stato interessato"
I clienti hanno visto alcuni brevi lacune nelle metriche di istanza:
Traduzione: Le istanze in GCP europe-west1 possono aver mostrato dati metrici incompleti o mancanti durante la finestra incidente.
*******Cloud Monitoring Integration \(CMI\):**** Le metriche inoltrate ai vostri sistemi di monitoraggio da questa regione possono anche avere avuto lacune.
Non tutte le istanze nella regione sono state influenzate, e altri fornitori di cloud e regioni non sono stati colpiti. I metrici generati durante l'incidente non sono stati registrati, quindi il divario rimarrà nei grafici storici per le istanze interessate.
Quello che stiamo facendo ora...
La correzione è venuta da Google Cloud in questa occasione, ma la nostra pipeline metrica ha fatto affidamento su un percorso di singola regione, quindi stiamo prendendo misure per ridurre tale esposizione:
***Resistenza regionale * Stiamo valutando il routing di regione trasversale in modo che il traffico metrico può fallire in una regione sana.
Traduzione: Stiamo esplorando le opzioni nel nostro livello di rete cloud per reindirizzare entrambe le letture \(Console e CMI\) e scrive \(ingestion\) lontano da una regione colpita.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Problema per alcuni clienti con metriche di istanza (endpoint e in Console).
Stiamo indagando su un problema con metriche nella Console Aura e attraverso il punto finale metrico.
identified
Continuiamo a indagare sulla causa principale.
Il problema è limitato ai clienti su noi-central1 su GCP
Le istanze di Aura sono in esecuzione e nessuna operazione è influenzata.
identified
Stiamo lavorando con il provider di servizi cloud per indagare la natura del problema.
I nostri controlli confermano che solo un sottoinsieme di clienti che operano nelle regioni centro-noi sono colpiti.
identified
Continuiamo a lavorare con il provider di servizi cloud per ottenere una soluzione.
resolved
Questo incidente è stato risolto, le metriche dovrebbero ora funzionare come normale.
postmortem
***Errori durante l'invio di metriche da GCP us-central1**
Che e' successo?
Il giovedì 8 ottobre 2026 alle 14:05 UTC, metriche da alcune istanze in GCP us-central1 ha smesso di essere consegnato. La causa è stata un problema sul lato di Google Cloud che ha erroneamente respinto richieste metriche valide. Consegna metrica ripresa alle 18:00 UTC dopo Google Cloud applicato una correzione, e abbiamo risolto l'incidente alle 18:48 UTC.
Instances rimase disponibile in tutto questo evento, senza alcun impatto per interrogare le prestazioni o l'integrità dei dati. Solo la visibilità metrica è stata temporaneamente influenzata.
"Come il servizio è stato interessato"
I clienti hanno visto lacune nelle metriche di istanza:
Traduzione: Le istanze in GCP us-central1 possono aver mostrato dati metrici incompleti o mancanti durante la finestra incidente.
*******Cloud Monitoring Integration \(CMI\):**** Le metriche inoltrate ai vostri sistemi di monitoraggio da questa regione possono anche avere avuto lacune.
Non tutte le istanze nella regione sono state colpite, e altri fornitori di cloud e regioni non sono stati colpiti.
Quello che stiamo facendo ora...
La correzione è venuta da Google Cloud, ma stiamo facendo passi per catturare e rispondere a eventi simili prima:
***Allering on metric delivery errors:** Stiamo aggiungendo avvisi sui tassi di errore di inoltro metrico, quindi i guasti lato provider vengono rilevati in precedenza e si distinguono dai vuoti di routine.
Revisione: Continueremo a monitorare la regione con Google Cloud per qualsiasi ricorrenza.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Istantanee Downloads Restituzione dei vuoti
Inizio 6 ottobre 2026 alle ore 09:22 UTC · 5h 57m
IssuesIncidente minore
Componenti interessati
AuraDB Business Critical (*.databases.neo4j.io) on AzureAuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDS on Azure (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on Azure (*.databases.neo4j.io)AuraDB Professional on Azure (*.databases.neo4j.io)
investigating
Stiamo indagando su un problema in cui, nonostante i backup che completano con successo, i download istantanei stanno ritornando dump vuoti. Ripristinare da un'istantanea attraverso la console Aura o API non è creduto essere interessato, e stiamo verificando questo ora. Condivideremo un aggiornamento non appena avremo maggiori informazioni.
investigating
Stiamo continuando a indagare sul problema. Le operazioni di ripristino non sono interessate come parte di questo problema.
investigating
Stiamo continuando a indagare su questo problema.
investigating
Stiamo continuando a indagare sul problema.
resolved
Una correzione è stata implementata; i download istantanei ora contengono i dati appropriati.
postmortem
# Che e' successo #
Su Fri, 18 Sep 2026 14:33 UTC, abbiamo identificato che i download istantanei per le istanze di Aura ospitate su Azure stavano restituendo file di circa 24KB invece della dimensione multi-gigabyte prevista. I backup sottostanti memorizzati in Azure erano la dimensione corretta, ma il percorso di download nella console stava servendo i file quasi vuoto.
La causa principale era un problema di credenziali Azure che si è verificato durante una distribuzione e ha impedito ai dati di backup di essere serviti per il download.
Una correzione iniziale è stata distribuita su Mon, 21 set 2026 10:31 UTC, ripristinando le misure di download corrette. Tuttavia, lo stesso problema di credenziali ricorrenti su Tue, 06 Oct 2026 08:20 UTC, di nuovo producendo download istantanei vuoti su tutti i livelli Azure. Il nostro team di ingegneria ha identificato la ricorrenza, l'ha collegata alla stessa causa principale, ha implementato una credenziale mirata fissa alla produzione, e ha verificato che i download sono tornati alla loro dimensione prevista.
Non abbiamo postato alla pagina di stato il 18 settembre perché un piccolo numero di clienti sono stati colpiti, e abbiamo lavorato con loro direttamente. Abbiamo postato il 6 ottobre alle 09:22 UTC, circa un'ora dopo l'inizio della ricorrenza, una volta che era chiaramente più ampio.
# Come il servizio à ̈ stato interessato
I download di snapshot sono stati influenzati dalle istanze AuraDS Professional e Enterprise, AuraDB Professional, Business Critical e Virtual Dedicated Cloud in esecuzione su Azure.
* I download di snapshot restituiti file inutilizzabili. Quando i clienti hanno scaricato le snapshot dalla console, hanno ricevuto file di circa 24KB invece dei dati di backup effettivi, che potrebbero essere diversi gigabyte di dimensioni. Ciò ha reso le snapshot scaricate inutilizzabili per i fini di ripristino o migrazione offline.
* I backup stessi non sono stati persi. I manufatti di backup sottostanti memorizzati in Azure rimasero intatti e dimensionati correttamente. Il problema era strettamente nel percorso di download, non nel processo di cattura o archiviazione di backup.
* Il ripristino tramite la console non è stato influenzato. Le operazioni di ripristino in-piattaforma \(al contrario di scaricare un file di dump\) hanno continuato a funzionare perché hanno accesso ai dati di backup direttamente piuttosto che attraverso il percorso di download interessato.
# Che stiamo facendo ora #
Abbiamo fatto più passi per risolvere il problema e abbiamo implementato salvaguardie per prevenire il ripetersi.
* Credenziali risolti schierati. Abbiamo corretto il problema delle credenziali Azure in produzione, che ha immediatamente ripristinato i download di snapshot per tutte le istanze interessate.
* Prevenire la rotazione delle credenziali indesiderate. Un cambio di codice è stato inviato per ripristinare la logica che stava innescando la rotazione delle credenziali Azure su ogni distribuzione. Ciò garantisce che le future distribuzioni non invalideranno inavvertitamente le credenziali esistenti, che è stato il meccanismo che ha causato sia l'incidente iniziale che la sua ricorrenza.
* Monitoraggio in corso. Stiamo monitorando i download di snapshot Azure su tutti i livelli per confermare che rimangono stabili. Abbiamo chiesto ai clienti interessati di verificare che i loro download ora restituiscano le dimensioni dei file attesi.
Questi cambiamenti affrontano sia il sintomo immediato che il comportamento di distribuzione sottostante che ha permesso al problema di ricorsi
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
AuraDS colpiti da problemi durante il tentativo di ripristinare da snapshot
Inizio 6 ottobre 2026 alle ore 08:07 UTC · 5h 57m
IssuesIncidente minore
Componenti interessati
AuraDS Enterprise on AWS (*.databases.neo4j.io)AuraDS on AWS (*.databases.neo4j.io)AuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDS on Azure (*.databases.neo4j.io)AuraDS on GCP (*.databases.neo4j.io)AuraDS Enterprise on GCP (*.databases.neo4j.io)
identified
Abbiamo identificato un problema nel tentativo di ripristinare da snapshot su AuraDS.
Abbiamo una soluzione pronta e lo distribuiremo presto.
Nel frattempo è possibile ripristinare da un backup invece.
identified
Abbiamo chiaramente identificato la causa principale e continuare a lavorare su una correzione per questo problema.
identified
Continuiamo a lavorare su una soluzione per questo problema.
identified
Una soluzione è in fase di distribuzione e si arrotolirà ai clienti interessati a breve.
monitoring
La correzione è fuori e i clienti interessati dovrebbero vedere la funzionalità ripristinata progressivamente.
resolved
Abbiamo implementato la correzione a tutti i clienti.
postmortem
# Che e' successo #
Un difetto software in una componente di gestione centrale di snapshot Neo4j Aura ripristina il fallimento per le istanze AuraDS Professional e AuraDS Enterprise ospitate su AWS. Quando è stato richiesto un ripristino, il sistema ha cercato l'istanza utilizzando un tipo di risorsa errato e ha restituito un errore.
L'incidente è stato dichiarato lunedì 05 ott 2026 21:52 UTC. Il nostro team di ingegneria ha identificato la causa principale, sviluppato e convalidato una correzione, e distribuito alla produzione il Martedì, 06 Oct 2026 13:37 UTC.
# Come il servizio à ̈ stato interessato
L'impatto è stato finalizzato alle operazioni di ripristino istantanee per le istanze AuraDS Professional e AuraDS Enterprise. I clienti interessati non sono stati in grado di ripristinare le snapshot tramite Aura Console o Aura API per la durata del problema.
* Ripristinare i tentativi di errori restituiti, interrompere i flussi di lavoro che dipendono dai ripristino di snapshot.
* Le istanze sono rimaste disponibili durante l'evento. L'integrità dei dati non è stata influenzata. Restaurare da backup completi ed esportati è rimasto disponibile come soluzione di lavoro.
# Che stiamo facendo ora #
* Abbiamo fissato il difetto nello strato di gestione di Aura che ha colpito AuraDS Professional e AuraDS Enterprise snapshot ripristina e implementato la correzione alla produzione.
* Ottimizzazione delle tubazioni di distribuzione: Durante questo incidente, la pipeline di distribuzione ha richiesto più tempo dell'ideale a causa della creazione di istanze di test sequenziali. Abbiamo valutato parallelizzare la creazione di istanze di prova per ridurre i tempi di attesa durante i rollout critici.
Questo miglioramento mira a accorciare il tempo necessario per convalidare e spedire una correzione in incidenti futuri, riducendo l'impatto rivolto al cliente
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Problema che colpisce determinate operazioni di database per i clienti Aura su Azure
Inizio 17 settembre 2026 alle ore 16:46 UTC · 3h 9m
OutageIncidente maggiore
Componenti interessati
AuraDB Business Critical (*.databases.neo4j.io) on AzureAuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDS on Azure (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on Azure (*.databases.neo4j.io)AuraDB Professional on Azure (*.databases.neo4j.io)Aura Graph Analytics on Azure
investigating
Siamo attualmente a conoscenza di un problema che sta influenzando alcune operazioni di database, come creare, eliminare, clone per i clienti che utilizzano Aura su Azure.
identified
Abbiamo identificato il problema e stiamo lavorando per una soluzione. In questo momento, alcune operazioni di database, come creare, eliminare e clone per i clienti che utilizzano Neo4j Aura solo su Azure, continuano ad essere influenzate.
monitoring
Una correzione è stata implementata in tutti gli ambienti interessati. Monitoreremo la situazione per garantire che la correzione risolva completamente il problema.
resolved
Dopo aver implementato la correzione, abbiamo monitorato le istanze, le metriche operative e gli errori. Questo incidente è ora risolto. Un post-mortem sarà disponibile non appena è stato completato.
postmortem
# Che e' successo #
Giovedì 17 settembre 2026 alle 13:52 UTC, un conflitto a tempo di distribuzione tra operazioni concorrenti ha causato una credenziale utilizzata da un core componente Aura per autenticare con l'infrastruttura ospitata da Azure da rimuovere.
Poiché i token di autenticazione esistenti sono scaduti, il componente ha iniziato a restituire errori per alcune istanze di Aura ospitate su Azure, che interessano determinate operazioni di database. Abbiamo tracciato gli errori alle credenziali mancanti, ne abbiamo creato una nuova, l'abbiamo memorizzata in modo sicuro, e abbiamo eseguito un rolling deployment del componente interessato, che ha completato a 18:39 UTC.
Un piccolo numero di richieste di creazione di database che erano in corso durante l'outage sono state lasciate in uno stato incompleto e hanno bisogno di risanamento manuale. Questo è stato completato alle 19:48 UTC, e l'incidente è stato risolto alle 19:55 UTC.
# Come il servizio à ̈ stato interessato
L'impatto è stato limitato alle istanze di Aura ospitate su Azure. Altri fornitori di cloud non sono stati colpiti.
# Operazioni Database # I clienti non sono stati in grado di eseguire determinate operazioni di database, come creare, eliminare e clone, su alcune istanze Azure durante la finestra incidente. Un piccolo numero di crea che erano in corso è rimasto bloccato e sono stati recuperati manualmente.
* ** Visibilità di gestione:** Alcune istanze ospitate da Azure non erano temporaneamente visibili o gestibili in Aura Console.
Traduzione: Gli endpoint Metrics per alcune istanze Azure hanno restituito errori intermittenti, lasciando brevi lacune nei dati delle metriche per il periodo interessato. Questi dati non saranno riempiti.
Le istanze Azure che erano già in esecuzione sono rimaste disponibili e hanno continuato a servire carichi di lavoro normalmente.
# Che stiamo facendo ora #
Stiamo facendo i seguenti passi per prevenire una ricorrenza e migliorare la nostra risposta:
* ** Rilevamento e comunicazione del campione:** Noi miglioreremo il monitoraggio e l'avviso, e valuteremo i controlli automatizzati delle credenziali, così i problemi vengono rilevati e i clienti vengono informati prima.
***Recupero dalla creazione di database incompleta Risolveremo un difetto che può lasciare una creazione di database bloccato se una chiamata infrastruttura fallisce a parte attraverso, in modo che il sistema recupera da solo.
Traduzione: Rivedremo come questo componente autentica con i fornitori di cloud, per rimuovere singoli punti di guasto e ridurre il rischio di questo tipo di conflitto ricorrente.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Problemi del portale di supporto clienti
Inizio 16 settembre 2026 alle ore 08:50 UTC · 5h 40m
OutageIncidente maggiore
Componenti interessati
Customer Support Portal (support.neo4j.com)
identified
Il nostro fornitore di servizi per il portale di supporto sta sperimentando qualche outage - Vedi https://status.salesforce.com/products/Salesforce Services
Se si verificano problemi di presentazione di un nuovo caso di supporto, si prega di inviare e-mail a [email protected]
identified
Il nostro gestore del portale di supporto sta ancora lavorando per affrontare il problema. Vedi i dettagli qui https://status.salesforce.com/incidents/20004433
identified
Il nostro fornitore del portale di supporto continua a lavorare per affrontare il problema. Vedi i dettagli qui https://status.salesforce.com/incidents/20004433
monitoring
Una correzione è in fase di roll out e il portale dovrebbe diventare meno influenzato da errori nel tempo. Vedi i dettagli https://status.salesforce.com/incidents/20004433
monitoring
Il nostro fornitore del portale di supporto continua a fare una correzione.
resolved
Una correzione è stata implementata e tutte le funzionalità dovrebbero essere recuperate.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Console e Outage API
Inizio 9 settembre 2026 alle ore 12:31 UTC · 1h 8m
OutageIncidente critico
Componenti interessati
Aura AgentAura Graph Analytics on GCPAura Console (console.neo4j.io)Aura Graph Analytics on AWSAura Graph Analytics on AzureAura API (api.neo4j.io)Aura MCP Service
investigating
Stiamo attualmente indagando su un problema che riguarda la console Aura.neo4j.io e l'API api.neo4j.io
identified
Abbiamo identificato la fonte del problema e stiamo attualmente lavorando su una soluzione.
identified
Continuiamo a lavorare per affrontare il problema.
identified
Abbiamo fatto buoni progressi e stiamo recuperando la componente problematica.
monitoring
Abbiamo implementato una correzione e i servizi interessati stanno recuperando.
resolved
Tutti i componenti interessati sono ora completamente recuperati.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Un piccolo numero di istanze Free Tier stanno vivendo problemi di aggiornamento
Inizio 3 settembre 2026 alle ore 16:43 UTC · 22h 53m
Pending
Componenti interessati
AuraDB Free (*.databases.neo4j.io)
investigating
Stiamo attualmente indagando su questo problema.
identified
La questione è stata identificata, le istanze rimangono disponibili e le misure da risolvere per le istanze che hanno subito una revisione.
resolved
Tutte le istanze sono disponibili, sono state intraprese delle misure manuali per sbloccare il restante piccolo numero di istanze.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Il nostro team ha identificato un problema con la raccolta delle metriche per le istanze di Aura. Ciò influenzerà la visibilità metrica e l'avanzamento.
Stiamo indagando sul problema.
investigating
Continuiamo a indagare sul problema delle metriche di Aura.
resolved
Dall'ultimo aggiornamento, l'indagine è andata avanti. Il problema è stato identificato, e abbiamo monitorato il servizio come recuperato dal degrado. Confermiamo che il problema è risolto.
postmortem
# Che e' successo #
Giovedì 20 Aug 2026 14:58:00 UTC, la nostra pipeline di ingestione metrica ha iniziato a sperimentare elevati errori di esportazione quando si inviano dati a Google Managed Prometheus \(GMP\). La causa di fondo è stata un incidente di servizio di Google Cloud Platform nella regione `us-west1`, che ha interrotto il percorso di esportazione utilizzato dalla nostra infrastruttura di raccolta metriche.
Di conseguenza, le code di esportazione metriche hanno cominciato a costruire attraverso un sottoinsieme di ambienti di produzione. I guasti si manifestano principalmente come timeout di rete quando si tenta di fornire dati metrici a GMP, impedendo la normale ingestione per cluster colpiti. Il nostro team di ingegneria ha identificato la concentrazione geografica dei sistemi interessati — che spaziano da AWS `us-west-2`, Google Cloud `us-west1`, e Azure `westus2` — tutti che percorso attraverso l'infrastruttura nell'area dell'Oregon.
Una volta che l'incidente regionale del GCP è stato mitigato da Google, gli errori di esportazione sono sottosostituiti e le code hanno cominciato a drenare.
# Come il servizio à ̈ stato interessato
L'impatto è stato limitato alla visibilità **metrics**** per un sottoinsieme di ambienti Aura. Circa 45 ambienti dei clienti sono stati colpiti, il che significa che i dati metrici dai database non sono stati ingeriti nella nostra piattaforma di monitoraggio durante la finestra incidente.
La regione più colpita è stata AWS `us-west-2`, con impatto aggiuntivo in Google Cloud `us-west1` e Azure `westus2`. I clienti con banche dati in queste regioni possono avere lacune sperimentate nelle loro dashboard metriche e dati di monitoraggio per la durata dell'incidente. Le operazioni di base di dati, comprese le letture, le scritture e la disponibilità, non sono state influenzate **; solo la raccolta e la visibilità delle metriche di prestazione sono state interrotte.
Una volta che Google ha mitigato il problema regionale sottostante, l'ingestione metrica ha ripreso e il backlog dei dati in coda è stato elaborato.
# Che stiamo facendo ora #
Abbiamo condotto una revisione approfondita di questo incidente e stiamo facendo i seguenti passi per migliorare le nostre capacità di resilienza e risposta:
Traduzione: Stiamo migliorando le nostre dashboard per l'esportatore di metriche per fornire una visibilità più chiara e più rapida nella salute della coda e nei tassi di errore di esportazione, consentendo un rilevamento più rapido e una diagnosi di problemi simili.
# Improva allerta aggregazione # Stiamo implementando un gruppo di allarme automatico in modo che un incidente regionale che interessa più cluster sia meglio riemerso come un singolo evento correlato e trattato con una corretta gravità e attenzione.
*** Avviso proattivo sui tassi di errore di ingestione:** Stiamo aggiungendo avvisi dedicati che il fuoco sui tassi di errore di ingestione GMP elevati, dando al nostro team un segnale precedente prima che le code di esportazione raggiungano la capacità.
Questi miglioramenti sono progettati per ridurre il tempo di rilevamento, semplificare il triage degli incidenti e rafforzare la nostra pipeline metrica contro future interruzioni del fornitore a monte.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Potenziali errori di query inaspettati.
Inizio 5 agosto 2026 alle ore 17:31 UTC · 1d 22h
IssuesIncidente minore
Componenti interessati
AuraDS Enterprise on AWS (*.databases.neo4j.io)AuraDS on AWS (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on GCP (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AzureAuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDB Professional on AWS (*.databases.neo4j.io)AuraDS on Azure (*.databases.neo4j.io)AuraDS on GCP (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on AWS (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on Azure (*.databases.neo4j.io)AuraDB Professional on GCP (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AWSAuraDS Enterprise on GCP (*.databases.neo4j.io)AuraDB Professional on Azure (*.databases.neo4j.io)AuraDB Free (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on GCP
investigating
Abbiamo identificato un problema attualmente che potrebbe portare a inattesi errori di query quando si utilizza il trim() Funzione Cypher. Le indagini sulla causa sono in corso.
identified
Abbiamo trovato il problema e stiamo lavorando a una soluzione. Un piccolo per centoatge di query utilizzando trim può ancora err.
I clienti VDC con database impostati al massimo non hanno alcun impatto a meno che non si fermino e inizino le loro istanze.
identified
Stiamo testando la correzione per il trim() Problema della funzione cieca. Ci aggiorneremo prima di iniziare la nostra distribuzione nell'ambiente Aura.
identified
We are actively validating the fix for the trim() Cypher function. Further updates will be provided before we begin deploying to Aura instances
identified
We continue to validate the fix for the trim() Cypher function.
Further updates will be provided before we begin deploying it to Aura instances.
identified
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.
identified
Development has completed on the hot-fix for this issue, and we are finalizing the rollout plan for Aura.
identified
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.
identified
The fix to the trim() Cypher function has passed testing and validation and is now being deployed.
monitoring
The fix to resolve the issue has now completed deployment to the Aura service and we are monitoring the situation.
resolved
We have monitored the fix and found the service to be stable. This incident is now considered resolved.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Problema che influisce sulle operazioni di istanza Aura
Inizio 23 luglio 2026 alle ore 10:52 UTC · 1d 5h
OutageIncidente maggiore
Componenti interessati
AuraDS Enterprise on AWS (*.databases.neo4j.io)AuraDS on AWS (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on GCP (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AzureAuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDB Professional on AWS (*.databases.neo4j.io)AuraDS on Azure (*.databases.neo4j.io)AuraDS on GCP (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on AWS (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on Azure (*.databases.neo4j.io)AuraDB Professional on GCP (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AWSAuraDS Enterprise on GCP (*.databases.neo4j.io)AuraDB Professional on Azure (*.databases.neo4j.io)AuraDB Free (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on GCPAura API (api.neo4j.io)
investigating
Stiamo attualmente indagando su un problema in questo momento.
investigating
Stiamo lavorando con i team di ingegneria e stiamo facendo progressi con le indagini al momento attuale.
investigating
Lavoriamo con i team di ingegneria e continuiamo a fare progressi con le indagini in questo momento.
identified
Abbiamo identificato la causa del problema attuale e stiamo lavorando attivamente sulla correzione attualmente.
identified
Stiamo implementando la prima parte della soluzione e continuiamo a lavorare attivamente per lanciare la soluzione completa. Ci aspettiamo un ETA nell'ordine di 1 ora.
identified
Abbiamo identificato il sottoinsieme delle istanze colpite e continuiamo a distribuire la correzione in questo momento.
identified
Abbiamo implementato una correzione di configurazione e ora stiamo lavorando per risolvere il sottoinsieme delle istanze colpite.
identified
Con la configurazione risolta implementata, continuiamo a risolvere il sottoinsieme delle istanze ancora colpite.
identified
Stiamo continuando a risolvere il sottoinsieme delle istanze ancora colpite.
identified
Continuiamo a risolvere il sottoinsieme di istanze che sono ancora influenzate.
monitoring
Continuiamo a risolvere il sottoinsieme di istanze che sono ancora influenzate.
monitoring
AuraDB Virtual Dedicated Cloud e AuraDB Business Critical dovrebbero essere tutti fissati. Continuiamo a risolvere il sottoinsieme di istanze che sono ancora influenzate per AuraDB Professional e Free.
monitoring
Continuiamo a risolvere il sottoinsieme di istanze che sono ancora influenzate per AuraDB Professional e Free.
monitoring
Continuiamo a risolvere il sottoinsieme di istanze che sono ancora influenzate per AuraDB Professional e Free.
monitoring
Continuiamo a risolvere il sottoinsieme di istanze che sono ancora influenzate per AuraDB Professional e Free
monitoring
Continuiamo a correggere un sottoinsieme di istanze che sono ancora influenzate per AuraDB Professional e Free
monitoring
Continuiamo a fissare un piccolo sottoinsieme di istanze che sono ancora influenzate sotto i livelli AuraDB Professional e Free.
monitoring
Abbiamo affrontato il problema in tutte le istanze AuraDB Professional. Aura Free può ancora essere influenzato. Continueremo a monitorare e correggere i database rimanenti.
monitoring
Continuiamo a correggere un piccolo sottoinsieme di istanze Free che sono ancora influenzate.
monitoring
Stiamo continuando a monitorare attentamente la situazione per ulteriori problemi.
monitoring
Stiamo continuando a monitorare eventuali ulteriori problemi.
monitoring
Tutte le istanze identificate sono state corrette, continuando a monitorare. Contatta l'assistenza clienti per ulteriori problemi.
resolved
Tutte le correzioni sono state implementate e il problema è ora segnato come risolto.
postmortem
# Che e' successo #
Giovedì 23 luglio 2026 10:33 UTC è stato distribuito un cambiamento di configurazione ad Aura che ha alterato involontariamente come le allocazioni della memoria sono state calcolate per le istanze del database. Di conseguenza, un sottoinsieme di istanze ha ricevuto memoria insufficiente, causando alcune istanze di database a diventare non disponibile o in grado di completare gli aggiornamenti.
L'allocazione di memoria regolata ha portato a condizioni fuori memoria, causando istanze di database di riavviare ripetutamente a causa di risorse di memoria insufficienti o di diventare l'aggiornamento bloccato. Questo problema ha interessato le istanze tra più fornitori di cloud e più livelli di prodotto.
Una volta che il problema è stato identificato, abbiamo immediatamente reindirizzato la modifica di configurazione, impedendo a eventuali istanze aggiuntive di ricevere la configurazione errata. Una configurazione corretta è stata distribuita alla produzione entro giovedì 23 luglio 2026 11:56 UTC. Tuttavia, le istanze del database che avevano già ricevuto la configurazione errata richiedevano singole azioni di recupero prima che potessero tornare al normale funzionamento.
Da giovedì 23 luglio 2026 17:59 UTC, tutte le istanze di database di impatto dei clienti noti erano stati recuperati. Il monitoraggio è continuato attraverso il giorno seguente, con l'incidente completamente risolto il venerdì, lug 24, 2026 16:30 UTC.
##### **Come il servizio è stato interessato **
L'impatto principale del cliente era che diverse istanze di database AuraDB non erano disponibili o entravano in uno stato degradato. Le istanze colpite non erano in grado di completare gli aggiornamenti del software di routine e, in alcuni casi, ripetutamente riavviato perché la memoria insufficiente era stata assegnata.
* ** Disponibilità del servizio:** L'impatto del cliente varia da livello di servizio. Le istanze professionali AuraDB, che non forniscono Alta Disponibilità, hanno sperimentato il più grande livello di disagi di servizio, con un sottoinsieme che diventa indisponibile e incapace di elaborare letture o scritture. Per le istanze AuraDB Business Critical e Virtual Dedicated Cloud \(VDC\), l'impatto è stato generalmente limitato a una perdita temporanea di tolleranza ai guasti, mentre la disponibilità dei servizi è stata mantenuta. In un numero minore di casi, anche le istanze Business Critical e VDC non sono disponibili.
Traduzione: Ulteriori istanze sono rimaste disponibili ma sono state bloccate in uno stato "Apdating", che ha bloccato le operazioni avviate dal cliente come ridimensioni o modifiche di configurazione.
* * * Campo di applicazione della piattaforma * * * L'impatto ha abbracciato tutti e tre i fornitori di cloud supportati e più regioni, che interessano i clienti a livello globale.
I casi di Customer Support sono stati sollevati e il nostro team ha triaged e recuperato manualmente le istanze in ordine prioritario. La maggior parte delle istanze di AuraDB ha continuato a funzionare normalmente. L'impatto del cliente è stato completamente mitigato attraverso la conversione della configurazione e il recupero manuale mirato di ogni istanza interessata.
# Che stiamo facendo ora #
Abbiamo effettuato un'analisi approfondita di questo incidente e abbiamo identificato le seguenti azioni:
# Prevenzione #
*** Convalida di distribuzione migliorata:** Stiamo rafforzando il nostro processo di convalida del rilascio per identificare meglio le modifiche di configurazione.
Traduzione: Stiamo valutando i miglioramenti al sequenziamento delle distribuzioni dei componenti per ridurre il rischio di modifiche involontarie incluse nelle versioni.
Traduzione: Stiamo esaminando il processo di rollout per i componenti interessati, per portarli in linea con i controlli di rollout utilizzati per altri componenti critici.
♪Detection ♪
# Meglio allertare # Stiamo migliorando il nostro monitoraggio per rilevare aumenti anormali dei tassi di guasto \(come la perdita di tolleranza di guasto o la disponibilità\) più rapidamente e in modo affidabile.
♪Mitigation ♪
*** Risparmiare la configurazione di distribuzione:** Stiamo migliorando il modo in cui le modifiche di configurazione di produzione vengono implementate in modo da poter essere disabilitate o rimosse più rapidamente senza richiedere un rilascio di software più ampio.
* * Più veloce strumento di recupero manuale**: Stiamo migliorando il nostro strumento di recupero per ridurre il tempo necessario per identificare e recuperare manualmente le istanze colpite.
Riconosciamo la rottura che questo incidente ha causato e scusa per l'impatto ai clienti colpiti. Abbiamo completato le azioni correttive immediate, e i miglioramenti a lungo termine sopra descritti sono già in corso per ridurre la probabilità e l'impatto di incidenti simili in futuro.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Aura Console Impatto - Visione del caso
Inizio 10 luglio 2026 alle ore 17:18 UTC · 2h 5m
IssuesIncidente minore
Componenti interessati
Aura Console (console.neo4j.io)
investigating
Stiamo attualmente indagando su un problema che riguarda l'Aura Console dove alcuni clienti potrebbero non essere in grado di vedere le loro istanze.
Questo problema è causato da un fallimento in un servizio di terze parti che Aura dipende. Le istanze interessate continuano a funzionare normalmente, e la connettività del database non è influenzata.
Il nostro team sta indagando attivamente sul problema.
investigating
Stiamo continuando a indagare su questo problema.
monitoring
Il servizio di terze parti su cui Aura dipende ha ripristinato le normali operazioni e i sistemi Neo4j Aura sono stati recuperati.
Il nostro team sta monitorando attivamente il problema per confermare che Aura Console si sta eseguendo come previsto.
resolved
I servizi sono confermati operativi e non sono previste ulteriori interruzioni.
postmortem
# What Happened #
Aura Console e altri componenti Aura hanno sperimentato interruzioni su 2026-07-10 a 16:14 UTC, con conseguente guasti e crashloop. Di conseguenza, un segmento di clienti ha affrontato problemi di visibilità per quanto riguarda le loro istanze. E 'stato causato da un outage in un servizio esterno di terze parti integrato con Aura. Crucialmente, la connettività di database è rimasta non compromessa, e le istanze colpite hanno continuato le loro normali operazioni. Il servizio LaunchDarkly è stato ripristinato per risolvere il problema
## Come il servizio à ̈ stato interessato
Componenti Aura multipli, tra cui Aura Console, perturbazioni sperimentate. Gli utenti hanno riscontrato errori HTTP 500 su pagine e operazioni relative al database, anche se organizzazioni e progetti potrebbero ancora essere accessibili. Le connessioni dirette a specifiche istanze di database non sono state completamente influenzate
Il piano di controllo è diventato non disponibile, il che significa che gli utenti non possono creare, eliminare, ridimensionare o regolare le impostazioni per le istanze tramite l'API o la console Aura. Tuttavia, le istanze esistenti sono rimaste operative. Il problema è stato causato da un outage su LaunchDarkly e i nostri servizi non hanno gestito quel fallimento di dipendenza con grazia durante l'avvio. Tutti i sistemi interessati sono tornati al funzionamento normale entro 2026-07-10 alle 17:07 UTC
# Che stiamo facendo ora #
Il team Neo4j Engineering ha rapidamente diagnosticato la causa principale e il servizio ripristinato. Nel valutare questo incidente, abbiamo individuato aree chiave per accelerare le risoluzioni future e mitigare i rischi di ricorrenza:
* metriche di incidente chiave analizzate, concentrandosi sulla durata dell'avviso-risposta per identificare le opportunità per accelerare l'efficienza della risposta
* Condotto una retrospettiva completa che evidenzia i risultati di successo, tra cui l'analisi rapida di root-cause tramite logging trasparente, l'allineamento senza soluzione di continuità tramite lo strumento di gestione degli incidenti, e il degrado resiliente e aggraziato di più componenti che ha mantenuto la connettività del piano di dati intatta
* Sviluppare attivamente più graziosi default fallback per le bandiere di funzionalità per salvaguardare le operazioni di base durante i tempi di fermo del fornitore
* Rafforzare la resilienza architettonica integrando la pianificazione avanzata, le pratiche di ingegneria del caos e i test di iniezione di guasti di livello di produzione per scoprire e mitigare i potenziali percorsi di fallimento
* Limitazioni logiche affrontate nell'operatore caratterizzano il caching della bandiera, sottolineando la necessità per gli operatori di memorizzare bandiere valutate localmente per preservare la continuità operativa se le dipendenze esterne falliscono.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
AuraDB problema: errori durante l'esecuzione CREATE VECTOR INDICE
Inizio 30 giugno 2026 alle ore 14:45 UTC · 2h 59m
IssuesIncidente minore
Componenti interessati
AuraDS Enterprise on AWS (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AzureAuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDB Professional on AWS (*.databases.neo4j.io)AuraDB Professional on GCP (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AWSAuraDS Enterprise on GCP (*.databases.neo4j.io)AuraDB Professional on Azure (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on GCP
identified
In esecuzione CREATE VECTOR INDICE fallisce con errore 51N31
errore: configurazione del sistema o eccezione di funzionamento - non supportato. La creazione di un indice vettoriale con le impostazioni fornite non è supportata in V2026 02. La versione richiesta per il funzionamento è V2026 06. Si prega di aggiornare DBMS..
Questo riguarda solo il nuovo indice, l'attuale INDICE VECTOR non è influenzato.
Qualsiasi indice vettoriale creato prima del 2026-06-30 alle 09:00 continuano a funzionare normalmente.
identified
Stiamo iniziando ora a distribuire una correzione per affrontare questo problema e fornirà un aggiornamento presto sui progressi.
monitoring
Una soluzione si sta esaurendo e progredisce bene. Ci aggiorneremo con i progressi.
resolved
La correzione è stata completamente implementata a tutte le istanze colpite. Questo incidente è ora risolto.
postmortem
# What Happened #
Un problema è stato identificato dopo l'implementazione della versione 2026.06 il 2026-06-30 alle 08:00 UTC, dove l'esecuzione di `CREATE VECTOR INDICE ` su istanze Aura aggiornate ha innescato un'eccezione di sistema. Questo fallimento nella generazione dell'indice si è verificato perché il negozio sottostante e il kernel hanno richiesto aggiornamenti aggiuntivi per supportare l'operazione
Questo problema ha colpito solo la creazione di nuovi indici; gli indici vettoriali esistenti non sono interessati. Qualsiasi indice vettoriale creato prima delle 09:00 il 2026-06-30 non è stato influenzato e ha continuato a lavorare normalmente.
## Come il servizio à ̈ stato interessato
A seguito del rollout della versione 2026.06, l'esecuzione della dichiarazione CREATE VECTOR INDICE fallì, impattando le applicazioni che dipendevano dall'aggiunta di nuovi indici vettoriali. I client interessati hanno ricevuto l'errore: Creare un indice vettoriale con le impostazioni fornite non è supportato in V2026\ 02. La versione richiesta per il funzionamento è V2026\ 06. Si prega di aggiornare DBMS . Gli indici esistenti \(creati prima di questo incidente\) e altre domande sono rimaste del tutto inalterate e completamente funzionali.
# Che stiamo facendo ora #
I team Neo4j hanno identificato la causa principale come un bug nel pianificatore Cypher e hanno risolto il problema con una correzione di codice. Questa correzione è stata implementata a tutte le istanze Aura interessate, risolvendo completamente l'errore
Per evitare eventi futuri, stiamo migliorando i nostri sistemi di monitoraggio e avviso per rilevare problemi simili in precedenza, in particolare all'interno di ambienti di staging, prima che si verifichino rollout. Contemporaneamente, stiamo rifinanziando i nostri processi di distribuzione per ridurre al minimo i tempi di impatto e recupero del cliente
Inoltre, stiamo indagando sulle opzioni per implementare test di convalida automatizzati post-upgrade specificamente per operazioni critiche come la creazione di indice vettoriale
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Console Aura che sperimenta alcuni errori intermittenti
Inizio 23 giugno 2026 alle ore 11:25 UTC · 21h 49m
IssuesIncidente minore
Componenti interessati
Aura Console (console.neo4j.io)Aura API (api.neo4j.io)
identified
Aura console sta vivendo alcuni errori intermittenti: "Il nostro sistema sta vivendo problemi in questo momento. riprovare più tardi o contattare il supporto se il problema persiste."
Ciò può richiedere di ricaricare o aspettare più a lungo per la navigazione nella console
Le operazioni e l'API Aura rimangono inalterate
Stiamo lavorando attivamente a una soluzione
identified
Stiamo continuando a indagare su una soluzione per il problema
identified
Stiamo continuando a lavorare per risolvere questo problema.
monitoring
Stiamo implementando un cambiamento. Monitoreremo e aggiorneremo.
monitoring
Proseguendo per monitorare le modifiche implementate. Prossimo aggiornamento previsto 6/24/2026 10am UTC.
monitoring
Abbiamo controllato e confermato che il problema è ora completamente affrontato.
resolved
Questo incidente è stato risolto.
postmortem
# What Happened #
A circa 12:00 UTC il 22 gennaio 2026, gli utenti hanno incontrato banner di errore intermittenti all'interno della console Aura visualizzando, "Stiamo avendo un problema. Riprova.," che si è verificato accanto a 500 errori da endpoint API console. Queste interruzioni sono state transitorie e causate dal temporizzazione delle API interne durante il processo di handshake TLS, in genere risolvendo entro circa 10 secondi o seguendo un aggiornamento della pagina
## Come il servizio à ̈ stato interessato
L'Aura Console e Aura API hanno sperimentato le prestazioni degradate, che si sono manifestate come banner di errore intermittenti all'interno della console Aura UI. Un'indagine ha identificato la causa principale come alto utilizzo della CPU e ottimizzazione all'interno della console API. Questo problema è stato principalmente guidato da ripetuti elenchi di grandi entità e costose richieste di conciliare
Per affrontare il problema, le correzioni mirate sono state implementate con successo sia sulla console Aura che su Aura API. Questo è stato seguito da modifiche alla configurazione delle risorse per aumentare la headroom operativa e garantire la stabilità
# Che stiamo facendo ora #
Sono state attuate le seguenti misure reattive e proattive per ridurre la probabilità di incidenti simili:
* Sviluppato un dashboard di monitoraggio per osservare le gocce di richiesta in base ai dati di registro API interni per implementare il monitoraggio automatizzato e l'avviso per catturare i problemi prima che si verifichino
* Implementato un ritardo netto tra le richieste di riconciliatore impaginato per mitigare l'alto consumo di risorse e migliorare la stabilità API
* Calcoli informativi delle risorse infrastrutturali migliorati per migliorare le prestazioni
* Introdotto un nuovo filtro per query basato su livelli di servizio per ottimizzare la CPU overhead per ogni chiamata eseguita dal riconciliatore
* Riattivato richiesta di elaborazione middleware per ottimizzare le chiamate API
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Aura Console Auth error
Inizio 26 maggio 2026 alle ore 18:23 UTC · 4h 43m
OutageIncidente maggiore
Componenti interessati
Aura Console (console.neo4j.io)
investigating
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.
monitoring
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.
resolved
This incident has been resolved.
postmortem
**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.
Console is not available
Inizio 6 marzo 2026 alle ore 10:18 UTC · 6m
OutageIncidente critico
Componenti interessati
Aura Console (console.neo4j.io)
identified
We identified an issue with the availability of console.neo4j.io - we are investigating
monitoring
We have made a code change and we believe the console is available again.
resolved
We have checked and confirm that the issue is now fully addressed.
postmortem
## 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
Subset of MERGE queries lead to setting unexpected property values
Inizio 3 marzo 2026 alle ore 21:35 UTC · 17h 44m
Pending
Componenti interessati
AuraDS Enterprise on AWS (*.databases.neo4j.io)AuraDS on AWS (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on GCP (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AzureAuraDS Enterprise on Azure (*.databases.neo4j.io)AuraDB Professional on AWS (*.databases.neo4j.io)AuraDS on Azure (*.databases.neo4j.io)AuraDS on GCP (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on AWS (*.databases.neo4j.io)AuraDB Virtual Dedicated Cloud on Azure (*.databases.neo4j.io)AuraDB Professional on GCP (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on AWSAuraDS Enterprise on GCP (*.databases.neo4j.io)AuraDB Professional on Azure (*.databases.neo4j.io)AuraDB Free (*.databases.neo4j.io)AuraDB Business Critical (*.databases.neo4j.io) on GCP
identified
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.
identified
The fix is being deployed and the status page will be updated upon completion of the full deployment of the fix.
identified
The fix is being deployed and the status page will be updated upon completion of the full deployment
monitoring
The fix has now been deployed to those instances impacted and we are monitoring the situation.
resolved
The fix has been fully deployed to all impacted instances. This incident is now resolved.
postmortem
## 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
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.
identified
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.
identified
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.
resolved
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
postmortem
## 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)
