Historial de interrupciones de Neo4j Aura

1. September 3, 2026 at 4:43 PM UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. September 4, 2026 at 10:23 AM 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. September 4, 2026 at 3:36 PM 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. August 20, 2026 at 3:49 PM 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. August 20, 2026 at 4:48 PM UTCinvestigating

   Seguimos investigando el problema de la métrica Aura.

3. August 20, 2026 at 7:10 PM 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.

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

1. August 5, 2026 at 5:31 PM UTCinvestigating

   We have identified an issue currently that could result in unexpected query failures when using the trim() Cypher function. Investigations into the cause are in progress.

2. August 5, 2026 at 7:27 PM 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. August 6, 2026 at 12:58 AM 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. August 6, 2026 at 7:13 AM 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. August 6, 2026 at 11:17 AM 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. August 6, 2026 at 2:54 PM 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. August 7, 2026 at 1:15 AM UTCidentified

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

8. August 7, 2026 at 1:16 AM 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. August 7, 2026 at 9:44 AM UTCidentified

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

10. August 7, 2026 at 1:49 PM UTCmonitoring

    The fix to resolve the issue has now completed deployment to the Aura service and we are monitoring the situation.

11. August 7, 2026 at 3:34 PM UTCresolved

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

1. July 23, 2026 at 10:52 AM UTCinvestigating

   Actualmente estamos investigando un problema en este momento.

2. July 23, 2026 at 11:08 AM UTCinvestigating

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

3. July 23, 2026 at 11:24 AM UTCinvestigating

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

4. July 23, 2026 at 11:38 AM UTCidentified

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

5. July 23, 2026 at 11:53 AM 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. July 23, 2026 at 12:11 PM UTCidentified

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

7. July 23, 2026 at 12:32 PM UTCidentified

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

8. July 23, 2026 at 12:49 PM UTCidentified

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

9. July 23, 2026 at 2:07 PM UTCidentified

   Seguimos resolviendo el subconjunto de casos todavía afectados.

10. July 23, 2026 at 2:27 PM UTCidentified

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

11. July 23, 2026 at 2:44 PM UTCmonitoring

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

12. July 23, 2026 at 3:03 PM 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. July 23, 2026 at 3:29 PM UTCmonitoring

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

14. July 23, 2026 at 3:57 PM UTCmonitoring

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

15. July 23, 2026 at 4:32 PM UTCmonitoring

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

16. July 23, 2026 at 5:01 PM UTCmonitoring

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

17. July 23, 2026 at 5:31 PM UTCmonitoring

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

18. July 23, 2026 at 6:07 PM 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. July 23, 2026 at 7:39 PM UTCmonitoring

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

20. July 24, 2026 at 6:00 AM UTCmonitoring

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

21. July 24, 2026 at 8:30 AM UTCmonitoring

    Continuamos monitoreando cualquier otro problema.

22. July 24, 2026 at 12:59 PM UTCmonitoring

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

23. July 24, 2026 at 3:56 PM UTCresolved

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

24. July 29, 2026 at 9:58 PM 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. July 10, 2026 at 5:18 PM 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. July 10, 2026 at 5:23 PM UTCinvestigating

   Seguimos investigando esta cuestión.

3. July 10, 2026 at 5:51 PM 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. July 10, 2026 at 7:23 PM UTCresolved

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

5. July 27, 2026 at 4:28 AM 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. June 30, 2026 at 2:45 PM 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. June 30, 2026 at 3:41 PM UTCidentified

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

3. June 30, 2026 at 4:05 PM UTCmonitoring

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

4. June 30, 2026 at 5:45 PM UTCresolved

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

5. July 20, 2026 at 8:40 AM 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. June 23, 2026 at 11:25 AM 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. June 23, 2026 at 1:03 PM UTCidentified

   Continuamos investigando una solución para la cuestión

3. June 23, 2026 at 1:39 PM UTCidentified

   Seguimos trabajando para solucionar este problema.

4. June 23, 2026 at 3:43 PM UTCmonitoring

   Estamos implementando un cambio. Monitorearemos y actualizaremos.

5. June 23, 2026 at 7:27 PM UTCmonitoring

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

6. June 24, 2026 at 9:14 AM UTCmonitoring

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

7. June 24, 2026 at 9:14 AM UTCresolved

   Este incidente ha sido resuelto.

8. July 10, 2026 at 2:50 PM 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. May 26, 2026 at 6:23 PM 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. May 26, 2026 at 7:19 PM 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. May 26, 2026 at 11:06 PM UTCresolved

   This incident has been resolved.

4. June 9, 2026 at 4:50 PM 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. March 6, 2026 at 10:18 AM UTCidentified

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

2. March 6, 2026 at 10:24 AM UTCmonitoring

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

3. March 6, 2026 at 10:25 AM UTCresolved

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

4. March 30, 2026 at 7:25 AM 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. March 3, 2026 at 9:35 PM 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. March 4, 2026 at 1:39 AM UTCidentified

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

3. March 4, 2026 at 4:52 AM UTCidentified

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

4. March 4, 2026 at 2:07 PM UTCmonitoring

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

5. March 4, 2026 at 3:19 PM UTCresolved

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

6. April 8, 2026 at 6:39 AM 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. March 2, 2026 at 7:55 PM 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. March 3, 2026 at 3:26 PM 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. March 6, 2026 at 2:29 PM 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. March 6, 2026 at 4:06 PM 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. March 29, 2026 at 3:16 PM UTCpostmortem

   ## What Happened On March 1, at 12:51 PM UTC, AWS services in the ME-CENTRAL-1 & ME-SOUTH-1 Region were impacted. Connectivity and power issues affected APIs and AWS core services essential to run Neo4j Aura prompting AWS to initiate an investigation ## How the service was affected Operations \(clone, backup, resuming/pausing, resizing\) that require additional resources like EC2 Instances, EBS Volumes, and other resources were impaired in the ME-CENTRAL-1 and ME-SOUTH-1 Region. Other AWS Services also experienced error rates and latencies for some workflows. Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure. A detailed summary of the AWS regional incident can be found here:[ https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status) ## What are we doing now We are actively working to limit the impact on the Neo4j Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels Please visit AWS Status page for more info:[https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status)

1. January 26, 2026 at 7:26 PM UTCidentified

   Hemos identificado un problema que puede afectar un conjunto limitado de consultas Cypher 25 para AuraDB Free, Professional y AuraDS. Esto puede afectar: - Las consultas con la consulta condicional WHEN en combinación con una agregación no agrupada sobre los valores nulos dan como resultado un número incorrecto de filas devueltas. - Las consultas con NEXT pueden producir un error variable inesperado no definido en algunos casos. Estamos trabajando activamente en una solución y actualizaremos esta página a medida que se disponga de más información.

2. January 27, 2026 at 1:37 AM UTCidentified

   Hemos identificado una solución para este problema y se pondrá en marcha en Aura. Una vez implementada la actualización, actualizaremos esta página de tatus.

3. January 27, 2026 at 9:50 AM UTCidentified

   Estamos poniendo en marcha la solución y le actualizaremos cuando esto esté terminado.

4. January 27, 2026 at 11:10 AM UTCmonitoring

   La solución se ha extendido a los componentes afectados, ahora estamos monitoreando la situación en este momento.

5. January 27, 2026 at 2:51 PM UTCmonitoring

   Seguimos vigilando la situación en este momento.

6. January 27, 2026 at 3:58 PM UTCresolved

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

7. July 2, 2026 at 4:22 AM UTCpostmortem

   ## ** What Happened** Neo4j inició el despliegue de la versión 2026.01.1 a las instancias libres de Aura a las 07:49 AM UTC el 26 de enero de 2026. Tras la detección de fallos de consulta durante las pruebas internas, la puesta en marcha se detuvo antes de llegar a los niveles superiores de Aura. Las fallas ocurrieron en consultas condicionales \(por ejemplo, WHEN ...THEN ...\) después de la fase del planificador para comportarse de manera diferente en el caso de agregación sobre valores nulos. Identificamos la causa raíz y desarrollamos una resolución que se integró en la versión 2026.01.2. El 27 de enero de 2026 empezamos a desplegar 2026.01.2 en todos los casos de Aura, mejorando con éxito todos los entornos afectados a la versión corregida ## How the service was affected Las consultas con WHEN en 2026.01.1 en combinación con la agregación de los valores nulos reciben un número incorrecto de filas devueltas. Las consultas que usan NEXT pueden en algunos casos producir un error inesperado y no definido. Esto causó que la consulta reescrita se comportase de manera diferente en el caso de agregación sobre valores nulos. La consulta condicional necesitaría recibir filas entrantes que contengan valores nulos y se agregan sobre los valores sin utilizar una agrupación. Los clientes recibieron un resultado incorrecto si estaban utilizando el constructo condicional de consultas en Cypher 25 \(véase [https://neo4j.com/docs/aura/managing-instances/cypher-version/](https://neo4j.com/docs/aura/managing-instances/cypher-version/)\), un impacto que se limitó a un número limitado de instancias Aura. ## What are we doing now Hemos mejorado nuestros procedimientos de prueba para asegurar una cobertura integral en todas las áreas de productos. Esto incluye el desarrollo de nuevos casos de prueba diseñados para abordar cuestiones identificadas y posibles escenarios futuros. Además, hemos integrado las pruebas de consulta Cypher dentro de Aura como componente estándar de nuestra suite de pruebas de regresión. Estos cheques son ahora etapas obligatorias dentro de nuestro oleoducto de integración continua y entornos de puesta en escena antes de cualquier despliegue de producción.

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

1. January 16, 2026 at 2:25 PM UTCidentified

   Impact is that currently it is not possible to load data into GDS via native projection. Customers using Aura Graph Analytics are not impacted. We have identified a packaging issue with the latest release of Aura. Our engineering team is working on a fix.

2. January 16, 2026 at 3:13 PM UTCidentified

   Our teams have a fix and initiated the work to get it ready to roll-out. No current ETA available. We will keep you updated soon.

3. January 16, 2026 at 5:07 PM UTCmonitoring

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

4. January 16, 2026 at 7:36 PM UTCresolved

   All instances should have the fix applied and if not it should be in the next 60 minutes

5. April 23, 2026 at 1:27 PM UTCpostmortem

   ### **What happened** On January 15, 2026 at 22:12 UTC we began rolling out an update that included an incompatible version of a key component, affecting customers using the GDS plugin. This issue was reported on January 16 at 12:59 UTC, and a fix was deployed within hours, restoring functionality for the majority of affected users by 20:03 UTC.  The issue occurred because Neo4’s packaging automation process selected the wrong version of the GDS component. GDS 2.25 should have been selected but instead GDS 2.24 was included in the bundle, which caused a compatibility issue. Although a corrected package was created and labeled separately, the release pipeline selected the incorrect package for deployment.  This issue highlighted a gap in the release validation process, where incompatible component versions were not detected before rollout. ### **How customers were affected** Customers using the GDS plugin were unable to use any of the functionality the plugin provides during the incident window.  The system configuration has been updated to ensure compatibility with the intended component versions, restoring full functionality. ### **What we are doing now** The following mitigations have been implemented:  * Enhanced testing procedures to automatically verify compatibility between Neo4j and all bundled components before release. * Improved release processes to ensure that only explicitly validated and correctly labeled packages can be selected for deployment.

1. November 26, 2025 at 3:47 PM UTCidentified

   Neo4j opened a ticket with Azure and is awaiting updates on their resolution of the Azure Infrastructure issues. Impact on Neo4j Aura Services: Create, Resize (CPU and Storage), Pause, Resume.

2. November 26, 2025 at 8:33 PM UTCidentified

   Neo4j continues working with Microsoft via an Azure cloud ticket and is awaiting updates on their resolution of the Azure Infrastructure issues. Some resources have been made available, and impacted Neo4j Services have resumed operation. Customers have been notified. The Neo4j Aura Service is impacted when performing the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j operations, the operation will fail, and the Neo4j instance will become unavailable until Azure is able to provision additional resources.

3. November 27, 2025 at 2:33 PM UTCidentified

   The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance will become unavailable until Azure is able to provision additional resources.

4. November 27, 2025 at 5:07 PM UTCidentified

   The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Clone, Resume. As Azure resources become available when performing some Aura operations, the impacted instances may progressively recover and operations successfully complete. We continue to monitor progress, work with Microsoft Azure Infrastructure issues and will update.

5. November 28, 2025 at 12:09 AM UTCidentified

   We continue to work with our cloud infrastructure provider . Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

6. November 28, 2025 at 10:55 AM UTCidentified

   We continue to work with our cloud infrastructure provider. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.

7. November 28, 2025 at 4:23 PM UTCidentified

   We continue to work with Microsoft Azure. No expected improvements in addressing the issues around cloud resources in the affected regions before next week. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume. We will resume updates after this weekend or earlier if we have more information.

8. December 1, 2025 at 9:54 AM UTCidentified

   The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance may become unavailable or degraded until Azure is able to provision additional resources.

9. December 5, 2025 at 10:20 AM UTCidentified

   The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, affecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance may become unavailable or degraded until Azure is able to provision additional resources.

10. December 5, 2025 at 4:59 PM UTCidentified

    The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region. We are working with our cloud partner and will resume updates once we have an ETA to share.

11. December 11, 2025 at 10:24 AM UTCmonitoring

    Cloud resources have become available in USEAST2 and we will monitor for a few hours to ensure there is no further customer impact.

12. December 11, 2025 at 3:39 PM UTCresolved

    Cloud resources have become available in USEAST2 and no further customer impact has been detected. This incident is resolved.

13. February 4, 2026 at 3:18 PM UTCpostmortem

    ### **What Happened** Starting at 13:26 UTC on November 24th Microsoft Azure region eastus experienced a stock out situation, which impacted operations for all tiers of Neo4j Aura in that specific region. Additional capacity was requested straight away, but not until 17:06 UTC on December 10th did enough additional resources become available to resume all normal operations. **How the service was affected** All tiers within the Neo4j Aura Service were impacted when performing the following operations during this incident: Create, Resize \(CPU and Storage\), Clone, Pause and Resume. If Microsoft Azure resources were unavailable when requesting these types of Neo4j operations, the operation would fail, and the Neo4j instance would become unavailable until Azure was able to provision additional resources.  ### **What are we doing now** To mitigate the scope of impact of future regional stock out issues, Neo4j is implementing the following measures: * Closely monitoring resource capacity to improve stockout predictions. * Regular calls with with our Cloud Service Provider to: * Learn about where regional resource capacity restrictions are forecast. * Plan for more resources in restricted regions. * Investigating other deployment models to allow us to keep Aura running in situations where 3 Availability Zones are not available.

1. November 18, 2025 at 3:56 PM UTCidentified

   We have identified an issue resulting in Pause, Resume and Delete operations to fail in both Console and Aura API across all tiers of Aura. We are actively working to resolve the issue and will report progress.

2. November 18, 2025 at 4:16 PM UTCmonitoring

   We have released a fix to this issue and are monitoring to ensure all operations are back to normal.

3. November 18, 2025 at 4:39 PM UTCresolved

   After monitoring the fix for some time, we can confirm that the issue is resolved and normal operations have resumed.

4. January 14, 2026 at 2:05 PM UTCpostmortem

   ### What happened On November 18, 2025, some customers experienced issues with the delete, pause, and resume operations in the Console. These actions failed due to a temporary system issue introduced during a sequence of updates. While the updates were intended to improve functionality, they unintentionally reintroduced a previously resolved defect. The issue was identified quickly, and our teams acted immediately to restore normal operation. The root cause was a misconfiguration in the data processing module. An outdated schema caused the data parsing logic to misinterpret certain input parameters, leading to incorrect behavior and data display within the Console. We have since corrected the schema and added stricter validation to ensure compatibility moving forward. ### How customers were affected During the incident, some users experienced service disruptions when accessing the Console. Impacts included: * Intermittent connectivity issues * Inability to log in * Temporary unavailability of specific Console features No customer data was lost. To prevent a recurrence, we have improved our release process to ensure updates are deployed in the correct order, eliminating overlapping or out-of-sequence changes. ### What we are doing now Neo4j takes service reliability seriously and is strengthening safeguards to prevent similar incidents. New mitigations being deployed include: * Enhanced monitoring to detect related issues earlier * Additional automated checks to block faulty configurations before deployment * Improvements to overall service resilience to better tolerate similar failures We apologize for the disruption and appreciate our customers’ patience as we continue to harden our systems.

1. October 20, 2025 at 4:43 PM UTCidentified

   Many core operations for instances in AWS region us-east-1 are degraded as a result of AWS incident in that region: https://health.aws.amazon.com/health/status Core operations include create, pause, resume, clone, backup, among others. We continue to monitor the AWS incident and will provide updates accordingly.

2. October 20, 2025 at 7:14 PM UTCidentified

   We are continuing to monitor the AWS incident, and can report some slow improvement of impacted Aura instances in the AWS us-east1 region, though the service remains degraded in this region at this time. We are continuing to monitor progress in the AWS incident: https://health.aws.amazon.com/health/status

3. October 20, 2025 at 9:28 PM UTCresolved

   Instance operations in AWS us-east-1 region are back to normal following the resolution of the AWS incident. We will continue to monitor but all data indicates that the issue is fully resolved at this time.

4. January 15, 2026 at 5:48 PM UTCpostmortem

   ### **What Happened** Between 08:41 UTC on October 20th and 09:00 UTC on October 21st, Neo4j Aura experienced service disruptions affecting the us-east-1 \(N. Virginia\) region in AWS. The incident was triggered by a broad AWS regional outage impacting Identity and Access Management \(IAM\) and the EC2 control plane. This resulted in delayed backups, temporary loss of database fault tolerance for a subset of users, and internal delays in administrative actions due to toolchain failures. A detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/) ### **How the service was affected** The primary cause was several AWS regional service disruptions in us-east-1. We will cover how each of these affected Neo4j Aura and its users. Neo4j Aura is designed to isolate regional failures. This is achieved through deploying customer instances in Orchestras that have instances in three availability zones and no cross region dependencies. AWS IAM and Identity Center became unresponsive, preventing Neo4j Aura’s automated systems from authenticating with AWS resources in us-east-1. This affected Neo4j Aura backups to be written to AWS S3 buckets. Customers were also not able to resume paused instances during this period as the resume process was not able to authenticate with AWS S3 buckets to retrieve the paused data set. Neo4j Aura’s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. AWS Network Load Balancer health check system failures and AWS EC2 “request limit exceeded” or “insufficient capacity” errors in us-east-1 were false negatives with the NLB heath checks which resulted in some Neo4j Aura DB clusters in us-east-1 losing fault tolerance \(1 out of 3 cluster members unavailable\). When this happened instances were removed by kubernetes and we were not able to provision new ones due to the EC2 failures noted earlier, leaving the clusters without fault tolerance for a prolonged period of time. All of these clusters still had full availability of the other two cluster members. ### **What are we doing now** Largely Neo4j Aura responded as designed to these events, isolating failures to us-east-1, with no to minimal cross system failure propagation. The cross cloud impact of creating DNS records for new instances was the main outlier.  To mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures: * Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies.  * Remove identified cross-region dependencies.

1. October 20, 2025 at 9:15 AM UTCidentified

   An active issue on AWS us-east-1 is affecting Neo4j Aura operations in the regions where we have some dependency on an impacted AWS service. See more details https://health.aws.amazon.com/health/status Other regions not currently impacted.

2. October 20, 2025 at 9:39 AM UTCidentified

   Operations such as Create, Pause, Resume, Clone are affected globally due to a dependency. Backups in the affected region of AWS us-est-1 will be impacted The affected AWS service is now starting to recover and we are monitoring the situation

3. October 20, 2025 at 9:58 AM UTCmonitoring

   We see clear signs of recovery and our impacted service are progressively getting back to normal. We will monitor and update when we can confirm full recovery and normal operations.

4. October 20, 2025 at 10:32 AM UTCmonitoring

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

5. October 20, 2025 at 11:13 AM UTCresolved

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

6. January 15, 2026 at 5:34 PM UTCpostmortem

   ### **What Happened** Between 08:41 UTC on October 20th and 09:00 UTC on October 21st, Neo4j Aura experienced service disruptions affecting the us-east-1 \(N. Virginia\) region in AWS. The incident was triggered by a broad AWS regional outage impacting Identity and Access Management \(IAM\) and the EC2 control plane. This resulted in delayed backups, temporary loss of database fault tolerance for a subset of users, and internal delays in administrative actions due to toolchain failures. A detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/) ### **How the service was affected** The primary cause was several AWS regional service disruptions in us-east-1. We will cover how each of these affected Neo4j Aura and its users. Neo4j Aura is designed to isolate regional failures. This is achieved through deploying customer instances in Orchestras that have instances in three availability zones and no cross region dependencies. AWS IAM and Identity Center became unresponsive, preventing Neo4j Aura’s automated systems from authenticating with AWS resources in us-east-1. This affected Neo4j Aura backups to be written to AWS S3 buckets. Customers were also not able to resume paused instances during this period as the resume process was not able to authenticate with AWS S3 buckets to retrieve the paused data set. Neo4j Aura’s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. AWS Network Load Balancer health check system failures and AWS EC2 “request limit exceeded” or “insufficient capacity” errors in us-east-1 were false negatives with the NLB heath checks which resulted in some Neo4j Aura DB clusters in us-east-1 losing fault tolerance \(1 out of 3 cluster members unavailable\). When this happened instances were removed by kubernetes and we were not able to provision new ones due to the EC2 failures noted earlier, leaving the clusters without fault tolerance for a prolonged period of time. All of these clusters still had full availability of the other two cluster members. ### **What are we doing now** Largely Neo4j Aura responded as designed to these events, isolating failures to us-east-1, with no to minimal cross system failure propagation. The cross cloud impact of creating DNS records for new instances was the main outlier.  To mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures: * Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies.  * Remove identified cross-region dependencies.

1. August 25, 2025 at 1:34 PM UTCinvestigating

   We are currently investigating this issue.

2. August 25, 2025 at 1:36 PM UTCinvestigating

   We are aware of an issue that could result in a degradation in write performance for all Aura instance. We have identified the cause and are preparing a fix.

3. August 25, 2025 at 1:47 PM UTCinvestigating

   We are continuing to investigate this issue.

4. August 25, 2025 at 3:34 PM UTCmonitoring

   The issue impact has been refined and currently could impact AuraDB Virtual Dedicated Cloud and Business Critical instances only. We have identified the cause and the faulty component has been reverted for the majority of instances. We will continue to monitor the situation, while the full fix is prepared.

5. August 25, 2025 at 9:44 PM UTCmonitoring

   We continue to work towards the issue resolution.

6. August 26, 2025 at 4:06 AM UTCmonitoring

   We are continuing to investigate this issue.

7. August 26, 2025 at 10:53 AM UTCmonitoring

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

8. August 26, 2025 at 2:48 PM UTCmonitoring

   We are continuing to monitor the situation. The full fix for the solution is currently undergoing final testing and will start deployment once testing is completed.

9. August 26, 2025 at 11:12 PM UTCmonitoring

   The full fix for the solution is starting to be deployed across the estate and are continuing to monitor the situation.

10. August 27, 2025 at 6:36 AM UTCmonitoring

    We are continuing to monitor for any further issues.

11. August 27, 2025 at 11:16 AM UTCmonitoring

    The full fix for the solution is continuing to be deployed across the estate and are continuing to monitor the situation.

12. August 27, 2025 at 4:46 PM UTCresolved

    The full fix for the solution has now been deployed across the estate and this issue is now resolved.

13. October 6, 2025 at 1:32 PM UTCpostmortem

    ### **What happened** Between August 22 and August 28, 2025, a performance issue affected some of our database services following a recent update. Our team quickly responded and discovered that the problem was due to a bug in the latest update, which caused certain memory settings to be incorrectly configured. We promptly applied the previous version of those settings to stabilize the affected databases. By August 28, all databases were successfully transferred to a new, stable version, and the incident was fully resolved. The issue was caused by a misconfiguration in the system's data processing module. Specifically, an incorrect parameter setting in the data pipeline led to a bottleneck, which slowed down the processing speed. This misconfiguration affected the way data was being queued and processed, resulting in delays. Our technical team has identified the root cause and implemented a fix to ensure that the data pipeline operates efficiently, preventing future occurrences of this issue. ### **How the service was affected** Some customers reported a performance change on their instance.  ### **What we are doing now** Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. New mitigations being deployed: * Enhancing our monitoring systems to detect similar issues faster * Implementing additional automated checks to prevent service disruptions * Improving our service resilience to handle similar scenarios * Introducing dynamic configuration management to ensure seamless updates * Enabling multiple configuration defaults to better manage database priorities * Improving notification systems for faster response to potential issues * Enhancing our tools to streamline database management and transfers

1. August 22, 2025 at 11:02 AM UTCinvestigating

   Engineers are investigating an issue whereby instance actions are not working. You may be unable to import data, pause, resume, create, delete or run manual backups for your instances. Regular Neo4j scheduled backups are continuing to run as normal. You may be unable to see your instances in the Aura Console. CMI is also experiencing an outage, you may be unable to ingest metrics from your Aura instances.

2. August 22, 2025 at 11:42 AM UTCmonitoring

   A fix has been identified and implemented. Instances should be showing on the console and instance operations should now be available. You should now also be able to ingest metrics using CMI. We are continuing to monitor the status of these services.

3. August 22, 2025 at 1:31 PM UTCresolved

   This incident has been resolved.

4. September 12, 2025 at 3:45 PM UTCpostmortem

   ### What happened On August 22, 2025, from 10:10 to 11:27 UTC, users experienced an issue with the Aura Console where instance operations were unavailable. This was due to a timing issue with refreshing security keys that affected the visibility and operations of instances in the Aura Console and also caused an outage in the Customer Metrics Integration \(CMI\) and Aura API. The issue was identified within 5 minutes and efforts to resolve it began promptly. The problem was traced back to a recent update and issues with authentication were resolved by refreshing the system cache, with the service fully restored by 11:27 UTC.  The issue arose because of a timing mismatch between the creation of new security keys and their recognition by our system. When new keys were generated, they were quickly used by the Console API. However, another part of our system, the database manager, was still using an older set of keys to verify requests. This mismatch caused requests to fail because the database manager could not recognize the new keys. No unauthorized operations were allowed and this did not affect the security of the service in any way. After approximately an hour, the system automatically updated its keys, and everything started working correctly again. ### How customers were affected Aura Console features were impacted, including the visibility of instances and therefore ability to connect to instances through the console. Driver connections to instances were not impacted. The issue also impacted the use of parts of the service including Customer Metrics Integration \(CMI\) and the Aura API. ### What we are doing now Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. We are taking steps to prevent similar issues in the future by improving our processes and monitoring systems. Changes we are making: * Enhancing our caching mechanisms to ensure seamless updates and prevent similar issues in the future. * Designing a robust process for updating service accounts and keys to guarantee uninterrupted service reliability.

1. August 19, 2025 at 9:19 AM UTCinvestigating

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

2. August 19, 2025 at 10:05 AM UTCinvestigating

   We are continuing to investigate the issue with backups. New backups after 0:00 last night are failing to complete. Existing backups are unaffected and remain available.

3. August 19, 2025 at 10:34 AM UTCinvestigating

   We are continuing to investigate this issue.

4. August 19, 2025 at 10:51 AM UTCinvestigating

   We continue to investigate and have identified the issue more clearly. Beyond backups, other operations are also affected: pause and clone. Operations may fail or take a long time to complete.

5. August 19, 2025 at 11:30 AM UTCmonitoring

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

6. August 19, 2025 at 12:04 PM UTCresolved

   This incident has been resolved.

7. September 12, 2025 at 7:41 PM UTCpostmortem

   ### What happened On August 18, 2025, at 19:18 UTC, the release of a faulty component in Neo4j Aura impacted the ability to perform backups of customer instances. The problem was identified when a critical component was updated without aligning with another dependent component, leading to failed backup attempts. This resulted in Neo4j not being able to take backups of customer instances for a period of approximately 17 hours. Our team quickly identified the root cause and began mitigation efforts early on August 19, 2025. By 11:54 UTC, the issue was fully resolved, and normal backup operations resumed. We apologize for any inconvenience this may have caused and are taking steps to prevent similar issues in the future. The issue arose because the deployment of the neo4j-backup system was not properly synchronized with the deployment of the neo4j-operator. This misalignment led to critical changes being introduced that impacted the ability to create new backups effectively. Essentially, the two components were not updated in harmony, which caused disruptions in the backup process. ### How customers were affected Customers were unable to  get successful backups of their instances for 17 hours. We promptly addressed the issue by reverting the recent backup changes that caused disruptions and ensured the stability of our service by cleaning up old, failing backups. ### What we are doing now Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. New mitigations being deployed: * Enhancing our monitoring systems to detect similar issues faster * Implementing additional automated checks to prevent service disruptions * Improving our service resilience to handle similar scenarios