Historial de interrupciones de Neo4j Aura

1. 26 de octubre de 2026 a las 14:50 UTCinvestigating

   Actualmente somos conscientes de un problema que está afectando a los clientes usando Aura en Azure, al intentar descargar instantáneas de instancia de base de datos.

2. 26 de octubre de 2026 a las 15:09 UTCidentified

   Hemos identificado la cuestión y estamos trabajando actualmente en el despliegue de la solución.

3. 26 de octubre de 2026 a las 16:22 UTCidentified

   La solución se está probando en entornos más bajos, antes de ser implementada.

4. 26 de octubre de 2026 a las 17:43 UTCidentified

   El examen de la solución está en curso y el despliegue se realizará una vez que se haya completado la prueba.

5. 26 de octubre de 2026 a las 19:14 UTCresolved

   Nuestros ingenieros han implementado con éxito una solución, y el problema ya está resuelto. Los clientes de Aura en Azure ahora pueden descargar instantáneas de la base de datos sin problemas.

Traducido automáticamente desde la actualización oficial del incidente.

1. 20 de octubre de 2026 a las 7:35 UTCinvestigating

   Actualmente estamos investigando una cuestión que afecta a la región de Europa occidental 2 en el GCP, que está afectando algunas operaciones, incluida la creación de instancias de base de datos en la región.

2. 20 de octubre de 2026 a las 8:36 UTCinvestigating

   Seguimos investigando la cuestión actualmente, trabajando con el GCP para encontrar una resolución. En este momento, algunas operaciones, incluida la creación de bases de datos en la región, siguen teniendo repercusiones.

3. 20 de octubre de 2026 a las 9:15 UTCidentified

   Hemos identificado la fuente de la cuestión que afecta actualmente a los clientes en europe-west2 en GCP. Más detalles disponibles en la página GCP en https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj. En este momento, algunas operaciones, incluida la creación de bases de datos en la región, siguen teniendo repercusiones.

4. 20 de octubre de 2026 a las 10:42 UTCidentified

   Actualmente estamos aplicando medidas correctivas para mitigar la cuestión mientras tanto. Siga las últimas de GCP en la página de estado en https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.

5. 20 de octubre de 2026 a las 12:38 UTCmonitoring

   La funcionalidad debe ser restaurada en todos los servicios afectados de Aura. Seguiremos de cerca la situación antes de considerarlo resuelto.

6. 20 de octubre de 2026 a las 14:06 UTCmonitoring

   Seguimos monitoreando la situación con el GCP en la actualidad y en este momento no hemos visto nuevas cuestiones.

7. 20 de octubre de 2026 a las 14:50 UTCresolved

   Este incidente se ha resuelto

Traducido automáticamente desde la actualización oficial del incidente.

1. 13 de octubre de 2026 a las 9:15 UTCinvestigating

   Estamos investigando un problema que impacta las métricas en la consola Aura y a través del punto final métrico.

2. 13 de octubre de 2026 a las 10:13 UTCidentified

   Hemos identificado que un problema relacionado con Cloud Service Provider está afectando la situación actual. Hemos abierto un caso de soporte con el proveedor de servicios de Cloud y actualizaremos más una vez tengamos más detalles.

3. 13 de octubre de 2026 a las 11:01 UTCmonitoring

   Creemos que el problema del proveedor de servicios en la nube se ha resuelto, ya que ya no estamos viendo problemas de nuestros sistemas internos. Seguiremos monitoreando la situación, mientras esperamos la confirmación del proveedor de servicios de Cloud.

4. 13 de octubre de 2026 a las 12:08 UTCresolved

   Hemos recibido la confirmación del proveedor de servicios de Cloud de que el problema se ha resuelto totalmente.

5. 16 de octubre de 2026 a las 17:06 UTCpostmortem

   **Errores al enviar métricas de GCP europe-west1** ¿Qué pasó? El martes 13 de octubre de 2026 a las 08:54 UTC, las métricas para casos en GCP europe-west1 dejaron de ser entregadas y no pudieron leerse. La causa fue un problema en el lado de Google Cloud, donde una reducción de la capacidad en su servicio de monitoreo llevó a solicitudes válidas siendo rechazadas incorrectamente. Las métricas volvieron a la normalidad a las 10:49 UTC después de que Google Cloud aplicara una solución, y resolvimos el incidente a las 12:08 UTC una vez que Google Cloud confirmó la resolución completa. Las noticias permanecieron disponibles durante todo este evento, sin ningún impacto en el desempeño de las consultas o la integridad de los datos. Sólo la visibilidad de las métricas fue afectada. Cómo el servicio fue afectado** Los clientes vieron algunas lagunas cortas en las métricas de ejemplo: * **Metrices de consola:** Las incidencias en GCP europe-west1 pueden haber mostrado datos métricos incompletos o faltantes durante la ventana del incidente. * **Cloud Monitoring Integration \(CMI\):** Las métricas transmitidas a sus propios sistemas de monitoreo de esta región también pueden haber tenido lagunas. No todos los casos en la región fueron impactados, y otros proveedores de nubes y regiones no fueron afectados. No se registraron las métricas generadas durante el incidente, por lo que la brecha permanecerá en los gráficos históricos para los casos afectados. Lo que estamos haciendo ahora La solución vino de Google Cloud en esta ocasión, pero nuestro oleoducto de métricas se basó en un camino de una sola inscripción, por lo que estamos tomando medidas para reducir esa exposición: * **Resistencia regional** Estamos evaluando el enrutamiento cruzado para que el tráfico de métricas pueda fracasar en una región sana. **** Traffic routing:** Estamos explorando opciones en nuestra capa de redes en la nube para redirigir ambas lecturas \(Console y CMI\) y escribe \(ingestión\) lejos de una región impactada.

Traducido automáticamente desde la actualización oficial del incidente.

1. 8 de octubre de 2026 a las 14:58 UTCinvestigating

   Estamos investigando un problema con métricas en la consola Aura y a través del punto final métrico.

2. 8 de octubre de 2026 a las 15:36 UTCidentified

   Seguimos investigando la causa raíz. El tema se limita a los clientes en nosotros-central1 en GCP Los casos de Aura se están ejecutando y ninguna operación se ve afectada.

3. 8 de octubre de 2026 a las 16:30 UTCidentified

   Trabajamos con el proveedor de servicios en la nube para investigar la naturaleza del problema. Nuestros cheques confirman que sólo un subconjunto de clientes que se ejecutan en las regiones nosotros-central1.

4. 8 de octubre de 2026 a las 18:41 UTCidentified

   Seguimos trabajando con el proveedor de servicios en la nube para obtener una solución.

5. 8 de octubre de 2026 a las 19:11 UTCresolved

   Este incidente se ha resuelto ahora, las métricas deberían funcionar como normales.

6. 16 de octubre de 2026 a las 17:04 UTCpostmortem

   **Errores al enviar métricas de GCP us-central1** ¿Qué pasó? El jueves 8 de octubre de 2026 a las 14:05 UTC, las métricas de algunos casos en GCP nos-central1 dejaron de ser entregadas. La causa fue un problema en el lado de Google Cloud que rechazó incorrectamente solicitudes métricas válidas. Entrega métrica reanudado a las 18:00 UTC después de que Google Cloud aplicara una solución, y resolvimos el incidente a las 18:48 UTC. Las noticias permanecieron disponibles durante todo este evento, sin ningún impacto en el desempeño de las consultas o la integridad de los datos. Sólo la visibilidad métrica fue afectada temporalmente. Cómo el servicio fue afectado** Los clientes vieron lagunas en métricas de ejemplo: * **Metrices de consola:** Las incidencias en el GCP us-central1 pueden haber mostrado datos métricos incompletos o faltantes durante la ventana del incidente. * **Cloud Monitoring Integration \(CMI\):** Las métricas transmitidas a sus propios sistemas de monitoreo de esta región también pueden haber tenido lagunas. No todos los casos en la región fueron afectados, y otros proveedores de nubes y regiones no fueron afectados. Lo que estamos haciendo ahora La solución vino de Google Cloud, pero estamos tomando medidas para atrapar y responder a eventos similares antes: * **Alerting on metric delivery errors:** Estamos añadiendo alerta sobre las tasas de error de reenvío métrico, por lo que las fallas del lado proveedor se detectan antes y se distinguen de las brechas de rutina. * ** Vigilancia continua:** Seguiremos monitoreando la región con Google Cloud para cualquier recurrencia.

Traducido automáticamente desde la actualización oficial del incidente.

1. 6 de octubre de 2026 a las 9:22 UTCinvestigating

   Estamos investigando un problema donde, a pesar de las copias de seguridad completadas con éxito, las descargas instantáneas están devolviendo los vertederos en blanco. Restaurar de una instantánea a través de la consola Aura o API no se cree que se vea afectada, y estamos verificando esto ahora. Compartiremos una actualización tan pronto como tengamos más información.

2. 6 de octubre de 2026 a las 10:43 UTCinvestigating

   Seguimos investigando la cuestión. Las operaciones de restauración no se ven afectadas como parte de esta cuestión.

3. 6 de octubre de 2026 a las 13:41 UTCinvestigating

   Seguimos investigando esta cuestión.

4. 6 de octubre de 2026 a las 13:41 UTCinvestigating

   Seguimos investigando el problema.

5. 6 de octubre de 2026 a las 15:19 UTCresolved

   Se ha implementado una solución; descargas instantáneas ahora contienen los datos apropiados.

6. 26 de octubre de 2026 a las 8:58 UTCpostmortem

   Lo que pasó On Fri, 18 Sep 2026 14:33 UTC, identificamos que las descargas instantáneas de los casos de Aura hospedadas en Azure estaban devolviendo archivos de aproximadamente 24KB en lugar del tamaño esperado de varios gigabytes. Las copias de seguridad subyacentes almacenadas en Azure fueron el tamaño correcto, pero la ruta de descarga en la consola estaba sirviendo archivos casi vacíos. La causa raíz fue un problema credencial de Azure que ocurrió durante un despliegue e impidió que los datos de copia de seguridad fueran servidos para su descarga. Una fijación inicial fue implementada en Mon, 21 Sep 2026 10:31 UTC, restaurando tamaños de descarga correctos. Sin embargo, el mismo problema credencial recurrió en Tue, 06 Oct 2026 08:20 UTC, otra vez produciendo descargas instantáneas en blanco en todos los niveles de Azure. Nuestro equipo de ingeniería identificó la recurrencia, la enlazó con la misma causa raíz, desplegó una fijación credencial dirigida a la producción, y verificó que las descargas regresaron a su tamaño esperado. No publicamos la página de estado el 18 de septiembre porque un pequeño número de clientes fueron afectados, y trabajamos con ellos directamente. Publicamos el 6 de octubre a las 09:22 UTC, aproximadamente una hora después de que comenzara la recurrencia, una vez que era claramente más amplio. # How the service was affected Las descargas instantáneas fueron impactadas para AuraDS Professional y Enterprise, AuraDB Professional, Business Critical y Virtual Dedicated Cloud instancias que se ejecutan en Azure. * Las descargas instantáneas devolvieron archivos inutilizables. Cuando los clientes descargaron instantáneas de la consola, recibieron archivos de aproximadamente 24KB en lugar de los datos de copia de seguridad reales, que podrían ser varios gigabytes en tamaño. Esto hizo que las instantáneas descargadas fueran inutilizables para fines de restauración o migración fuera de línea. * Los respaldos mismos no se perdieron. Los artefactos de copia de seguridad subyacentes almacenados en Azure permanecieron intactos y tallados correctamente. El problema estaba estrictamente en la ruta de descarga, no en el proceso de captura o almacenamiento de copia de seguridad. * Restaurar a través de la consola no fue afectada. Las operaciones de restauración en formato \(en lugar de descargar un archivo de dump\) continuaron funcionando porque accedieron a los datos de copia de seguridad directamente en lugar de a través de la ruta de descarga afectada. # Lo que estamos haciendo ahora Hemos adoptado múltiples medidas para resolver la cuestión y hemos aplicado salvaguardias para prevenir la recurrencia. * Fijación de credenciales desplegada. Corrigemos el problema de la credencial de Azure en la producción, que de inmediato restauró descargas instantáneas para todas las instancias afectadas. * Prevención de la rotación credencial no deseada. Se ha presentado un cambio de código para revertir la lógica que activaba la rotación credencial de Azure en cada despliegue. Esto asegura que los despliegues futuros no invaliden inadvertidamente las credenciales existentes, que fue el mecanismo que causó tanto el incidente inicial como su recurrencia. * Monitoreo continuo. Estamos monitoreando las descargas instantáneas de Azure en todos los niveles para confirmar que permanecen estables. Hemos pedido a los clientes afectados que verifiquen que sus descargas ahora devuelven los tamaños de archivos esperados. Estos cambios abordan tanto el síntoma inmediato como el comportamiento de implementación subyacente que permitió que el problema volviera a ocurrir

Traducido automáticamente desde la actualización oficial del incidente.

1. 6 de octubre de 2026 a las 8:07 UTCidentified

   Hemos identificado un problema al intentar restaurar de instantáneas en AuraDS. Tenemos una solución lista y desplegaremos esto pronto. Mientras tanto, puede restaurar de una copia de seguridad en su lugar.

2. 6 de octubre de 2026 a las 9:07 UTCidentified

   Hemos identificado claramente la causa raíz y seguimos trabajando en una solución para esta cuestión.

3. 6 de octubre de 2026 a las 10:03 UTCidentified

   Seguimos trabajando en una solución para esta cuestión.

4. 6 de octubre de 2026 a las 12:14 UTCidentified

   Se está implementando una solución y se pondrá en marcha en breve a los clientes afectados.

5. 6 de octubre de 2026 a las 13:35 UTCmonitoring

   La solución está funcionando y los clientes afectados deben ver la funcionalidad restaurada progresivamente.

6. 6 de octubre de 2026 a las 14:04 UTCresolved

   Hemos implementado la solución a todos los clientes.

7. 26 de octubre de 2026 a las 8:51 UTCpostmortem

   Lo que pasó Un defecto de software en un componente de gestión central de Neo4j Aura snapshot restaura para fallar en las instancias AuraDS Professional y AuraDS Enterprise alojadas en AWS. Cuando se solicitó una restauración, el sistema buscó la instancia utilizando un tipo de recurso incorrecto y devolvió un error. El incidente fue declarado el lunes, 05 oct 2026 21:52 UTC. Nuestro equipo de ingeniería identificó la causa raíz, desarrolló y validó una solución, y la desplegó en producción el martes 06 Oct 2026 13:37 UTC. # How the service was affected The impact was scoped to snapshot restore operations for AuraDS Professional and AuraDS Enterprise instances. Los clientes afectados no pudieron restaurar instantáneas a través de la consola Aura o la API de Aura durante la duración del problema. * Restaurar los intentos devueltos errores, alterar los flujos de trabajo que dependen de las restauraciones instantáneas. * Los casos siguen disponibles durante todo este evento. La integridad de los datos no se vio afectada. El almacenamiento de copias de seguridad completas y exportadas seguía estando disponible como solución de trabajo. # Lo que estamos haciendo ahora * Hemos fijado el defecto en la capa de gestión de AuraDS que afectó a AuraDS Professional y AuraDS Enterprise instantánea restaura y desplegó la solución a la producción. * Optimización de los oleoductos de despliegue: Durante este incidente, el oleoducto de despliegue tomó más tiempo que ideal debido a la creación de instancia de prueba secuencial. Hemos evaluado la creación paralela de instancias de prueba para reducir los tiempos de espera durante los despliegues críticos. Esta mejora tiene como objetivo acortar el tiempo necesario para validar y enviar una solución en futuros incidentes, reduciendo el impacto del cliente

Traducido automáticamente desde la actualización oficial del incidente.

1. 17 de septiembre de 2026 a las 16:46 UTCinvestigating

   Actualmente somos conscientes de un problema que está afectando ciertas operaciones de base de datos, como crear, eliminar, clonar para los clientes utilizando Aura en Azure.

2. 17 de septiembre de 2026 a las 17:11 UTCidentified

   Hemos identificado la cuestión y estamos trabajando para una solución. En este momento, ciertas operaciones de base de datos, como crear, eliminar y clonar para los clientes utilizando Neo4j Aura en Azure solamente, siguen siendo impactadas.

3. 17 de septiembre de 2026 a las 19:06 UTCmonitoring

   Se ha desplegado una solución a todos los entornos afectados. Seguiremos de cerca la situación para asegurar que la solución resuelva plenamente la cuestión.

4. 17 de septiembre de 2026 a las 19:55 UTCresolved

   Después de implementar la solución, monitoreamos los casos impactados, métricas operativas y errores. Este incidente ya está resuelto. Una post-mortem estará disponible tan pronto como se haya completado.

5. 16 de octubre de 2026 a las 16:23 UTCpostmortem

   Lo que pasó El jueves 17 de septiembre de 2026 a las 13:52 UTC, un conflicto de tiempo de despliegue entre operaciones concurrentes causó una credencial utilizada por un componente básico de Aura para autenticar con la infraestructura anfitriona de Azure para ser eliminada. A medida que caducaban las fichas de autenticación existentes, el componente comenzó a devolver errores para algunos casos de Aura alojados en Azure, afectando algunas operaciones de bases de datos. Trazamos los errores a la credencial desaparecida, creamos una nueva, la almacenamos de forma segura, y realizamos un despliegue de la componente afectada, que completó a las 18:39 UTC. Un pequeño número de solicitudes de creación de bases de datos que estaban en curso durante el desvío se quedaron en un estado incompleto y se necesitaba una remediación manual. Esto se completó a las 19:48 UTC, y el incidente fue marcado resuelto a las 19:55 UTC. # How the service was affected The impact was limited to Aura instances hosted on Azure. Otros proveedores de nube no fueron afectados. * ** Operaciones de base de datos:** Los clientes no pudieron realizar ciertas operaciones de base de datos, como crear, eliminar y clonar, en algunas instancias de Azure durante la ventana del incidente. Un pequeño número de creaciones que estaban en progreso se atascó y se recuperaron manualmente. * ** Visibilidad de gestión:** Algunas instancias anfitrionas de Azure no fueron visibles o manejables temporalmente en la consola Aura. * ** brechas de medición:** Los puntos finales métricos de algunos casos de Azure devolvieron errores intermitentes, dejando lagunas cortas en datos métricos para el período afectado. Estos datos no se rellenarán. Los casos de azufre que ya se estaban ejecutando seguían disponibles y seguían sirviendo normalmente a la carga de trabajo. # Lo que estamos haciendo ahora Estamos tomando las siguientes medidas para ayudar a prevenir una recurrencia y mejorar nuestra respuesta: * **Detección y comunicación a distancia:** Mejoraremos el monitoreo y alerta, y evaluaremos las comprobaciones automatizadas de credenciales, por lo que se detectan problemas y se informa a los clientes antes. * **Recovery from incomplete database creation:** Arreglaremos un defecto que puede dejar una creación de bases de datos pegada si una llamada de infraestructura falla en parte, por lo que el sistema se recupera por sí mismo. * **Revisión de la autenticación** Revisaremos cómo este componente autentica con proveedores de nube, para eliminar puntos únicos de fracaso y reducir el riesgo de este tipo de conflicto recurrente.

Traducido automáticamente desde la actualización oficial del incidente.

1. 16 de septiembre de 2026 a las 8:50 UTCidentified

   Nuestro proveedor de servicios para el portal de soporte está experimentando algún outage - Véase https://status.salesforce.com/products/Salesforce Services Si experimenta problemas presentando un nuevo caso de soporte, envíe un correo electrónico a [email protected]

2. 16 de septiembre de 2026 a las 9:16 UTCidentified

   Nuestro proveedor de portales de apoyo sigue trabajando para abordar el problema. See details here https://status.salesforce.com/incidents/20004433

3. 16 de septiembre de 2026 a las 10:11 UTCidentified

   Nuestro proveedor de portales de apoyo sigue trabajando para abordar la cuestión. See details here https://status.salesforce.com/incidents/20004433

4. 16 de septiembre de 2026 a las 11:30 UTCmonitoring

   Se está implementando una solución y el portal debe ser menos impactado por errores con el tiempo. See details https://status.salesforce.com/incidents/20004433

5. 16 de septiembre de 2026 a las 12:29 UTCmonitoring

   Nuestro proveedor del portal de soporte continúa haciendo una solución.

6. 16 de septiembre de 2026 a las 14:31 UTCresolved

   Se ha desplegado una solución y se debe recuperar toda la funcionalidad.

Traducido automáticamente desde la actualización oficial del incidente.

1. 9 de septiembre de 2026 a las 12:31 UTCinvestigating

   Actualmente estamos investigando un problema que afecta a la consola Aura.neo4j.io y la API api.neo4j.io

2. 9 de septiembre de 2026 a las 12:54 UTCidentified

   Hemos identificado la fuente de la cuestión y actualmente estamos trabajando en una solución.

3. 9 de septiembre de 2026 a las 13:10 UTCidentified

   Seguimos trabajando para abordar la cuestión.

4. 9 de septiembre de 2026 a las 13:26 UTCidentified

   Hemos progresado y estamos recuperando el componente problemático.

5. 9 de septiembre de 2026 a las 13:36 UTCmonitoring

   Hemos implementado una solución y los servicios afectados se están recuperando.

6. 9 de septiembre de 2026 a las 13:39 UTCresolved

   Todos los componentes afectados se recuperan totalmente.

Traducido automáticamente desde la actualización oficial del incidente.

1. 3 de septiembre de 2026 a las 16:43 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 4 de septiembre de 2026 a las 10:23 UTCidentified

   Se ha determinado la cuestión, siguen existiendo casos y se siguen adoptando medidas para resolver los casos que se están examinando actualmente.

3. 4 de septiembre de 2026 a las 15:36 UTCresolved

   Todos los casos están disponibles, se adoptaron medidas manuales para desbloquear el pequeño número restante de casos para resolverlo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 20 de agosto de 2026 a las 15:49 UTCinvestigating

   Nuestro equipo ha identificado un problema con la recogida de las métricas para las instancias de Aura. Esto afectará la visibilidad métrica y el reenvío. Actualmente estamos investigando la cuestión.

2. 20 de agosto de 2026 a las 16:48 UTCinvestigating

   Seguimos investigando el problema de la métrica Aura.

3. 20 de agosto de 2026 a las 19:10 UTCresolved

   Desde la última actualización, la investigación ha seguido adelante. La cuestión fue identificada, y monitoreamos el servicio mientras se recuperaba de la degradación. Confirmamos que el problema ya está resuelto.

4. 17 de septiembre de 2026 a las 10:09 UTCpostmortem

   Lo que pasó El jueves 20 ago 2026 14:58:00 UTC, nuestro gasoducto de ingestión métrica comenzó a experimentar altas fallas de exportación al enviar datos a Google Managed Prometheus \(GMP\). La causa subyacente fue un incidente de servicio de Google Cloud Platform en la región `us-west1`, que interrumpió el camino de exportación utilizado por nuestra infraestructura de recogida de métricas. Como resultado, las colas de exportación métricas comenzaron a construirse en un subconjunto de entornos de producción. Los fallos se manifestaron principalmente como timeouts de red al intentar entregar datos métricos a GMP, evitando la ingestión normal para los grupos afectados. Nuestro equipo de ingeniería identificó la concentración geográfica de los sistemas afectados, abarcando AWS `us-west-2`, Google Cloud `us-west1`, y Azure `westus2`, todos los cuales recorren la infraestructura en la zona de Oregon. Una vez que el incidente regional del GCP fue mitigado por Google, los errores de exportación disminuyeron y las colas comenzaron a drenar. # How the service was affected El impacto se limitó a la visibilidad **métrica** para un subconjunto de entornos Aura. Aproximadamente 45 ambientes de clientes se vieron afectados, lo que significa que los datos métricos de bases de datos no estaban siendo ingeridos en nuestra plataforma de vigilancia durante la ventana del incidente. La región más afectada fue AWS `us-west-2`, con impacto adicional en Google Cloud `us-west1` y Azure `westus2`. Los clientes con bases de datos en estas regiones pueden haber experimentado lagunas en sus tableros de control de métricas y datos de vigilancia durante el incidente. Las operaciones básicas de base de datos —incluyendo lecturas, escritos y disponibilidad— fueron ** no afectadas**; sólo se interrumpió la recopilación y visibilidad de las métricas de rendimiento. Una vez que Google mitigó la cuestión regional subyacente, se reanudó la ingestión métrica y se tramitó el atraso de los datos solicitados. # Lo que estamos haciendo ahora Hemos realizado un examen exhaustivo de este incidente y estamos adoptando las siguientes medidas para mejorar nuestra capacidad de resiliencia y respuesta: * **Dashboards de observabilidad mejoradas**: Estamos mejorando nuestros paneles para exportadores de métricas para ofrecer una visibilidad más clara y rápida en las tasas de error de exportación y salud de cola, lo que permite una detección y un diagnóstico más rápidos de problemas similares. * **Mejora la agregación de alerta**: Estamos implementando la agrupación de alerta automática para que un incidente regional que afecta a múltiples grupos se vea mejor surgido como un solo evento correlativo y tratado con la severidad y la atención adecuadas. * ** Alerta activa sobre las tasas de error de ingestión:** Estamos agregando alertas dedicadas que disparan sobre tasas de error de ingestión GMP elevadas, dando a nuestro equipo una señal anterior antes de que las colas exportadoras alcancen la capacidad. Estas mejoras están diseñadas para reducir el tiempo de detección, simplificar el triaje de incidentes y fortalecer nuestro oleoducto de métricas contra futuras interrupciones del proveedor de corriente avanzada.

Traducido automáticamente desde la actualización oficial del incidente.

1. 5 de agosto de 2026 a las 17:31 UTCinvestigating

   Hemos identificado un problema que podría resultar en fracasos inesperados de la consulta al usar el trm() Función Cypher. Se están investigando la causa.

2. 5 de agosto de 2026 a las 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 de agosto de 2026 a las 0: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 de agosto de 2026 a las 7: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 de agosto de 2026 a las 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 de agosto de 2026 a las 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 de agosto de 2026 a las 1:15 UTCidentified

   Development has completed on the hot-fix for this issue, and we are finalizing the rollout plan for Aura.

8. 7 de agosto de 2026 a las 1: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 de agosto de 2026 a las 9:44 UTCidentified

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

10. 7 de agosto de 2026 a las 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 de agosto de 2026 a las 15:34 UTCresolved

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

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de julio de 2026 a las 10:52 UTCinvestigating

   Actualmente estamos investigando un problema en este momento.

2. 23 de julio de 2026 a las 11:08 UTCinvestigating

   Trabajamos con equipos de ingeniería y progresamos con las investigaciones en la actualidad.

3. 23 de julio de 2026 a las 11:24 UTCinvestigating

   Trabajamos con equipos de ingeniería y continuamos progresando con las investigaciones en la actualidad.

4. 23 de julio de 2026 a las 11:38 UTCidentified

   Hemos identificado la causa de la cuestión actual y estamos trabajando activamente en la solución actual.

5. 23 de julio de 2026 a las 11:53 UTCidentified

   Estamos implementando la primera parte de la solución y continuamos trabajando activamente en la salida de la solución completa. Esperamos un ETA en el orden de 1 hora a partir de ahora.

6. 23 de julio de 2026 a las 12:11 UTCidentified

   Hemos identificado el subconjunto de casos impactados y continuamos implementando la solución en este momento.

7. 23 de julio de 2026 a las 12:32 UTCidentified

   Hemos implementado una solución de configuración y ahora estamos trabajando para resolver el subconjunto de instancias impactadas.

8. 23 de julio de 2026 a las 12:49 UTCidentified

   Con la solución de configuración desplegada, continuamos resolviendo el subconjunto de casos todavía afectados.

9. 23 de julio de 2026 a las 14:07 UTCidentified

   Seguimos resolviendo el subconjunto de casos todavía afectados.

10. 23 de julio de 2026 a las 14:27 UTCidentified

    Seguimos resolviendo el subconjunto de casos que todavía están afectados.

11. 23 de julio de 2026 a las 14:44 UTCmonitoring

    Seguimos resolviendo el subconjunto de casos que todavía están afectados.

12. 23 de julio de 2026 a las 15:03 UTCmonitoring

    AuraDB Virtual Dedicated Cloud and AuraDB Business Critical should all now be fixed. Seguimos resolviendo el subconjunto de casos que todavía están impactados para AuraDB Professional y Free.

13. 23 de julio de 2026 a las 15:29 UTCmonitoring

    Seguimos resolviendo el subconjunto de casos que todavía están impactados para AuraDB Professional y Free.

14. 23 de julio de 2026 a las 15:57 UTCmonitoring

    Seguimos resolviendo el subconjunto de casos que todavía están impactados para AuraDB Professional y Free.

15. 23 de julio de 2026 a las 16:32 UTCmonitoring

    Seguimos resolviendo el subconjunto de casos que todavía están impactados para AuraDB Professional y Free

16. 23 de julio de 2026 a las 17:01 UTCmonitoring

    Seguimos fijando un subconjunto de casos que todavía están impactados para AuraDB Professional y Free

17. 23 de julio de 2026 a las 17:31 UTCmonitoring

    Seguimos fijando un pequeño subconjunto de instancias que todavía están impactadas bajo los niveles AuraDB Professional y Free.

18. 23 de julio de 2026 a las 18:07 UTCmonitoring

    Abordamos la cuestión en todas las instancias del AuraDB Professional. Aura Free todavía puede ser afectada. Seguiremos vigilando y arreglando las bases de datos restantes.

19. 23 de julio de 2026 a las 19:39 UTCmonitoring

    Seguimos fijando un pequeño subconjunto de instancias gratuitas que todavía están impactadas.

20. 24 de julio de 2026 a las 6:00 UTCmonitoring

    Seguimos vigilando de cerca la situación para otras cuestiones.

21. 24 de julio de 2026 a las 8:30 UTCmonitoring

    Continuamos monitoreando cualquier otro problema.

22. 24 de julio de 2026 a las 12:59 UTCmonitoring

    Se han resuelto todos los casos identificados, que siguen vigilando. Contacte con el cliente para cualquier otro problema.

23. 24 de julio de 2026 a las 15:56 UTCresolved

    Todas las correcciones se han desplegado y la cuestión está marcada como resuelta.

24. 29 de julio de 2026 a las 21:58 UTCpostmortem

    Lo que pasó El jueves 23 de julio de 2026 10:33 UTC se desplegó un cambio de configuración a Aura que alteró involuntariamente cómo se calcularon las asignaciones de memoria para los casos de bases de datos. As a result, a subset of instances received insufficient memory, causing some database instances to become unavailable or unable to complete updates. La asignación de memoria ajustada dio lugar a condiciones fuera de la memoria, lo que hizo que las instancias de la base de datos se reiniciaran repetidamente debido a la insuficiencia de recursos de memoria o quedaran estancadas de actualización. Este problema afectó las instancias a través de múltiples proveedores de nube y múltiples niveles de productos. Una vez identificado el problema, revertimos inmediatamente el cambio de configuración, impidiendo que cualquier instancia adicional reciba la configuración incorrecta. Para el jueves 23 de julio de 2026 11:56 UTC se implementó una configuración corregida. Sin embargo, los casos de bases de datos que ya habían recibido la configuración incorrecta requerían acciones individuales de recuperación antes de que pudieran regresar a una operación normal. Para el jueves 23 de julio de 2026 17:59 UTC, se habían recuperado todas las instancias conocidas de la base de datos de impacto del cliente. La vigilancia continuó durante el día siguiente, con el incidente totalmente resuelto el viernes, 24 de julio, 2026 16:30 UTC. #### ** How the service was affected** El impacto principal del cliente fue que varias instancias de la base de datos AuraDB no estaban disponibles o entraron en un estado degradado. Los casos afectados no pudieron completar las actualizaciones de software de rutina y, en algunos casos, se reiniciaron repetidamente porque no se había asignado suficiente memoria. * ** Disponibilidad de servicios:** Impacto del cliente variado por nivel de servicio. AuraDB Professional instances, which do not provide High Availability, experienced the greatest level of service disruption, with a subset becoming unavailable and unable to process reads or writes. Para los casos afectados de AuraDB Business Critical y Virtual Dedicated Cloud \(VDC\), el impacto se limitó generalmente a una pérdida temporal de tolerancia a la falla mientras se mantenía la disponibilidad de servicio. En un número menor de casos, las instancias de Business Critical y VDC también se hicieron indisponibles. * **Stuck updates**: Otras instancias permanecieron disponibles pero se quedaron atascadas en un estado "Updating", que bloqueó operaciones iniciadas por el cliente, como los tamaños o cambios de configuración. * ** Alcance de la plataforma Cross**: El impacto abarcó a los tres proveedores de nube compatibles y múltiples regiones, afectando a los clientes a nivel mundial. Se plantearon casos de asistencia al cliente y nuestro equipo recortaba y recuperaba manualmente los casos afectados en orden prioritario. La mayoría de los casos de AuraDB siguieron funcionando normalmente. El impacto del cliente se mitigó completamente a través de la reversión de la configuración y la recuperación manual específica de cada instancia afectada. Lo que estamos haciendo ahora Hemos realizado un análisis exhaustivo de este incidente y hemos identificado las siguientes acciones: *Prevención* * ** validación mejorada del despliegue:** Estamos fortaleciendo nuestro proceso de validación de la liberación para identificar mejor los cambios de configuración. * **Decoupling Component**: Estamos evaluando mejoras en la secuencia de despliegues de componentes para reducir el riesgo de que se incluyan cambios no deseados en las liberaciones. * **Progressive rollout strategy**: Estamos revisando el proceso de puesta en marcha de los componentes afectados, para ajustarlos a los controles de despliegue utilizados para otros componentes críticos. * **Detección* * **Mejor alerta* Estamos mejorando nuestro monitoreo para detectar aumentos anormales en las tasas de falla \ (como la pérdida de tolerancia de falla o disponibilidad\) más rápido y fiable. * Mitigation* * ** Despliegue de configuración de la tarjeta:** Estamos mejorando cómo se despliegan los cambios de configuración de producción para que puedan ser desactivados o volcados más rápidamente sin requerir una versión más amplia del software. * **Faster manual recovery tooling**: Estamos mejorando nuestra herramienta de recuperación para reducir el tiempo necesario para identificar y recuperar manualmente los casos afectados. Reconocemos la perturbación que este incidente causó y nos disculpamos por el impacto a los clientes afectados. Hemos completado las acciones correctivas inmediatas, y las mejoras a largo plazo descritas anteriormente ya están en marcha para reducir la probabilidad y el impacto de incidentes similares en el futuro.

Traducido automáticamente desde la actualización oficial del incidente.

1. 10 de julio de 2026 a las 17:18 UTCinvestigating

   Actualmente estamos investigando un problema que afecta a la Consola Aura donde algunos clientes pueden ser incapaces de ver sus casos. Este problema es causado por un fracaso en un servicio de terceros que Aura depende. Los casos afectados siguen funcionando normalmente, y la conectividad de bases de datos no se ve afectada. Nuestro equipo está investigando activamente el tema.

2. 10 de julio de 2026 a las 17:23 UTCinvestigating

   Seguimos investigando esta cuestión.

3. 10 de julio de 2026 a las 17:51 UTCmonitoring

   El servicio de terceros que Aura depende ha restaurado operaciones normales y los sistemas Neo4j Aura se han recuperado. Nuestro equipo está monitoreando activamente la cuestión para confirmar que Aura Console está funcionando como se espera.

4. 10 de julio de 2026 a las 19:23 UTCresolved

   Se confirma que los servicios funcionan y que no se prevén nuevas interrupciones.

5. 27 de julio de 2026 a las 4:28 UTCpostmortem

   ## What Happened Aura Console y otros componentes de Aura experimentaron interrupciones en 2026-07-10 a 16:14 UTC, lo que dio lugar a fallos y fallos. En consecuencia, un segmento de clientes se enfrentaba a problemas de visibilidad en sus casos. Fue causada por un outage en un servicio externo de terceros integrado con Aura. Es fundamental que la conectividad de las bases de datos no se produjera y que los casos afectados continuaran sus operaciones normales. El servicio de lanzamientoDarkly fue restaurado para resolver el problema ## How the service was affected Múltiples componentes de Aura, incluyendo la consola Aura, experimentaron trastornos. Los usuarios encontraron errores de HTTP 500 en páginas y operaciones relacionadas con la base de datos, aunque todavía se podían acceder a organizaciones y proyectos. Las conexiones directas a casos específicos de bases de datos no se vieron afectadas por completo El plano de control no estaba disponible, lo que significaba que los usuarios no podían crear, eliminar, redimensionar o ajustar los ajustes para los casos a través de la API o la consola Aura. Sin embargo, los casos existentes seguían funcionando. El problema fue causado por un outage en LaunchDarkly y nuestros servicios no manejaron ese fracaso de dependencia con gracia durante la puesta en marcha. Todos los sistemas afectados regresaron a la operación normal en 2026-07-10 a las 17:07 UTC ## What are we doing now El equipo de ingeniería Neo4j rápidamente diagnosticó la causa raíz y el servicio restaurado. Al evaluar este incidente, hemos identificado áreas clave para acelerar futuras resoluciones y mitigar los riesgos de recurrencia: * Analizar métricas clave de incidentes, centrándose en la duración de alerta a respuesta para identificar oportunidades para acelerar la eficiencia de la respuesta * Realizó una retrospectiva completa destacando los resultados exitosos, incluyendo el rápido análisis de las raíces a través de logging transparente, alineación sin costuras a través de la herramienta de gestión de incidentes, y la degradación resiliente y graciosa de múltiples componentes que mantenía intacta la conectividad de los planos de datos * Desarrollar activamente predeterminados de retroceso más elegantes para las banderas de características para salvaguardar las operaciones centrales durante las horas de inactividad de proveedores * Fortalecimiento de la resiliencia arquitectónica mediante la integración de la planificación avanzada, las prácticas de ingeniería del caos y las pruebas de inyección de fallas a nivel de producción para descubrir y mitigar de forma preventiva posibles trayectorias de fracaso * Limitaciones lógicas abordadas en el caché de la bandera del operador, destacando la necesidad de que los operadores almacenen banderas evaluadas localmente para preservar la continuidad operacional si fallan las dependencias externas.

Traducido automáticamente desde la actualización oficial del incidente.

1. 30 de junio de 2026 a las 14:45 UTCidentified

   Running CREATE VECTOR INDEX falla con error 51N31 error: configuración del sistema o excepción de operación - no compatible. Crear un índice vectorial con la configuración proporcionada no es compatible con V2026 02. Versión requerida para la operación es V2026 06. Por favor, actualice DBMS. Esto sólo afecta al nuevo índice, ya existente VECTOR INDEX no se ve afectado. Cualquier índice vectorial creado antes de 2026-06-30 a las 09:00 sigue funcionando normalmente.

2. 30 de junio de 2026 a las 15:41 UTCidentified

   Estamos empezando a implementar una solución para abordar esta cuestión y proporcionaremos una actualización pronto sobre el progreso.

3. 30 de junio de 2026 a las 16:05 UTCmonitoring

   Una solución está saliendo y progresando bien. Actualizaremos con el progreso.

4. 30 de junio de 2026 a las 17:45 UTCresolved

   La solución se ha desplegado plenamente en todos los casos afectados. Este incidente ya está resuelto.

5. 20 de julio de 2026 a las 8:40 UTCpostmortem

   ## What Happened Se identificó un problema tras el despliegue de la versión 2026.06 el 2026-06-30 a las 08:00 UTC, donde se ejecutó el `CREATE VECTOR INDEX` en los casos actualizados de Aura provocó una excepción del sistema. Este fracaso en la generación de índices ocurrió porque la tienda subyacente y el núcleo requerían actualizaciones adicionales para apoyar la operación Este problema sólo impactó la creación de nuevos índices; los índices vectoriales existentes no se ven afectados. Cualquier índice vectorial creado antes de las 09:00 el 2026-06-30 no fue afectado y continuó trabajando normalmente. ## How the service was affected Tras la puesta en marcha de la versión 2026.06, la ejecución de la declaración CREATE VECTOR INDEX falló, impactando aplicaciones que dependían de añadir nuevos índices vectoriales. Los clientes afectados recibieron el error: Crear un índice vectorial con la configuración proporcionada no es compatible con V2026\ 02. La versión requerida para la operación es V2026\ 06. Por favor, actualice DBMS . Los índices existentes \(creados antes de este incidente\) y otras consultas permanecieron enteramente no afectados y totalmente funcionales. ## What are we doing now Los equipos Neo4j identificaron la causa raíz como un error en el planificador Cypher y resolvieron el problema con una solución de código. Esta solución se ha implementado en todos los casos afectados de Aura, resolviendo completamente el error Para evitar futuros acontecimientos, estamos mejorando nuestros sistemas de vigilancia y alerta para detectar cuestiones similares antes, en particular dentro de entornos de estancamiento, antes de que ocurran despliegues. Simultaneamente, estamos refinando nuestros procesos de implementación para minimizar el impacto del cliente y los tiempos de recuperación Además, estamos investigando opciones para implementar pruebas automatizadas de validación post-upgrade específicamente para operaciones críticas como la creación de índice de vectores

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de junio de 2026 a las 11:25 UTCidentified

   La consola Aura está experimentando algunos errores intermitentes: "Nuestro sistema está experimentando problemas ahora mismo. intente más tarde o contacte con soporte si el problema persiste". Esto puede requerir que vuelva a cargar o espere más tiempo para navegar en la consola Las operaciones y la API de Aura siguen sin afectar Estamos trabajando activamente en una solución

2. 23 de junio de 2026 a las 13:03 UTCidentified

   Continuamos investigando una solución para la cuestión

3. 23 de junio de 2026 a las 13:39 UTCidentified

   Seguimos trabajando en una solución para esta cuestión.

4. 23 de junio de 2026 a las 15:43 UTCmonitoring

   Estamos implementando un cambio. Monitorearemos y actualizaremos.

5. 23 de junio de 2026 a las 19:27 UTCmonitoring

   Seguir vigilando los cambios desplegados. Siguiente actualización esperada 6/24/2026 10am UTC.

6. 24 de junio de 2026 a las 9:14 UTCmonitoring

   Hemos comprobado y confirmado que la cuestión se ha abordado plenamente.

7. 24 de junio de 2026 a las 9:14 UTCresolved

   Este incidente ha sido resuelto.

8. 10 de julio de 2026 a las 14:50 UTCpostmortem

   ## What Happened Aproximadamente a las 12:00 UTC el 22 de enero de 2026, los usuarios encontraron banners de error intermitentes dentro de la consola Aura mostrando, "Estamos teniendo un problema. Prueba de nuevo.", que ocurrió junto con 500 errores de consola API endpoints. Estas interrupciones fueron transitorias y causadas por el tiempo interno de API durante el proceso de apretón de manos TLS, normalmente resolviendo dentro de unos 10 segundos o después de una actualización de página ## How the service was affected La consola Aura y Aura API experimentaron un rendimiento degradado, que se manifestó como banners de error intermitente dentro de la consola Aura UI. Una investigación identificó la causa raíz como alto uso de CPU y la oscilación dentro de la consola API. This issue was primarily driven by repeated large entity listings and expensive reconcilir requests Para abordar el problema, se desplegaron con éxito correcciones específicas tanto en la consola Aura como en la API de Aura. A ello siguieron los ajustes en la configuración de recursos para aumentar la capacidad operacional y garantizar la estabilidad ## What are we doing now Se han aplicado las siguientes medidas reactivas y proactivas para reducir la probabilidad de incidentes similares: * Desarrolló un panel de control para observar gotas de solicitud basadas en datos de registro interno de API para implementar monitoreo y alerta automatizada para capturar problemas antes de que ocurran * Efectuó un retraso escalofriante entre las solicitudes de reconciliador de paginas para mitigar el alto consumo de recursos y mejorar la estabilidad de la API * Mejora de la infraestructura con conocimiento de los cálculos de recursos para mejorar el rendimiento * Introdujo un nuevo filtro para consultas basadas en niveles de servicio para optimizar la sobrecarga de CPU para cada llamada realizada por el conciliador * Procesamiento de middleware de solicitud redundante desactivado para optimizar las llamadas API

Traducido automáticamente desde la actualización oficial del incidente.

1. 26 de mayo de 2026 a las 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 de mayo de 2026 a las 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 de mayo de 2026 a las 23:06 UTCresolved

   This incident has been resolved.

4. 9 de junio de 2026 a las 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 de marzo de 2026 a las 10:18 UTCidentified

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

2. 6 de marzo de 2026 a las 10:24 UTCmonitoring

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

3. 6 de marzo de 2026 a las 10:25 UTCresolved

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

4. 30 de marzo de 2026 a las 7: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 de marzo de 2026 a las 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 de marzo de 2026 a las 1: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 de marzo de 2026 a las 4:52 UTCidentified

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

4. 4 de marzo de 2026 a las 14:07 UTCmonitoring

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

5. 4 de marzo de 2026 a las 15:19 UTCresolved

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

6. 8 de abril de 2026 a las 6: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 de marzo de 2026 a las 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 de marzo de 2026 a las 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 de marzo de 2026 a las 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 de marzo de 2026 a las 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 de marzo de 2026 a las 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)