Historique des pannes de Neo4j Aura

1. 9 septembre 2026 à 12:31 UTCinvestigating

   We are currently investigating an issue affecting the Aura console console.neo4j.io and the API api.neo4j.io

2. 9 septembre 2026 à 12:54 UTCidentified

   We have identified the source of the issue and are currently working on a solution.

3. 9 septembre 2026 à 13:10 UTCidentified

   We continue to work on addressing the issue.

4. 9 septembre 2026 à 13:26 UTCidentified

   We have made good progress and are recovering the problematic component.

5. 9 septembre 2026 à 13:36 UTCmonitoring

   We have deployed a fix and the affected services are recovering.

6. 9 septembre 2026 à 13:39 UTCresolved

   All affected components are now fully recovered.

1. 3 septembre 2026 à 16:43 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 4 septembre 2026 à 10:23 UTCidentified

   La question a été cernée, les cas demeurent disponibles et les mesures à prendre pour résoudre les cas touchés sont actuellement examinés.

3. 4 septembre 2026 à 15:36 UTCresolved

   Toutes les instances sont disponibles, des étapes manuelles pour débloquer le petit nombre restant d'instances ont été entreprises pour résoudre.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 août 2026 à 15:49 UTCinvestigating

   Notre équipe a identifié un problème avec la collecte des paramètres pour les instances Aura. Cela aura une incidence sur la visibilité métrique et la transmission. Nous enquêtons actuellement sur la question.

2. 20 août 2026 à 16:48 UTCinvestigating

   Nous continuons d'étudier la question des paramètres d'Aura.

3. 20 août 2026 à 19:10 UTCresolved

   Depuis la dernière mise à jour, l'enquête a progressé. Le problème a été identifié, et nous avons surveillé le service au fur et à mesure qu'il s'est remis de la dégradation. Nous confirmons que la question est maintenant réglée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 5 août 2026 à 17:31 UTCinvestigating

   Nous avons identifié un problème qui pourrait entraîner des défaillances inattendues lors de l'utilisation du trim() Fonction cryptographique. Des enquêtes sur la cause sont en cours.

2. 5 août 2026 à 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 août 2026 à 00:58 UTCidentified

   We are testing the fix for the trim() Cypher function issue. We will update before we begin our deployment into the Aura environment.

4. 6 août 2026 à 07:13 UTCidentified

   We are actively validating the fix for the trim() Cypher function. Further updates will be provided before we begin deploying to Aura instances

5. 6 août 2026 à 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 août 2026 à 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 août 2026 à 01:15 UTCidentified

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

8. 7 août 2026 à 01:16 UTCidentified

   We are actively working on addressing the issue. The fix for the trim() Cypher function is undergoing testing and validation currently before deployment. Further updates will be provided before we begin deploying it to Aura instances.

9. 7 août 2026 à 09:44 UTCidentified

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

10. 7 août 2026 à 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 août 2026 à 15:34 UTCresolved

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

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 juillet 2026 à 10:52 UTCinvestigating

   Nous enquêtons actuellement sur un problème.

2. 23 juillet 2026 à 11:08 UTCinvestigating

   Nous travaillons avec les équipes d'ingénierie et progressons actuellement dans les enquêtes.

3. 23 juillet 2026 à 11:24 UTCinvestigating

   Nous travaillons avec des équipes d'ingénieurs et continuons à faire des progrès dans les enquêtes à l'heure actuelle.

4. 23 juillet 2026 à 11:38 UTCidentified

   Nous avons identifié la cause du problème actuel et nous travaillons activement à la solution actuelle.

5. 23 juillet 2026 à 11:53 UTCidentified

   Nous déployons la première partie de la solution et continuons à travailler activement au déploiement de la solution complète. Nous attendons une ETA dans l'ordre de 1 heure.

6. 23 juillet 2026 à 12:11 UTCidentified

   Nous avons identifié le sous-ensemble des instances touchées et nous continuons de déployer la correction à ce moment-là.

7. 23 juillet 2026 à 12:32 UTCidentified

   Nous avons déployé une correction de configuration et nous travaillons maintenant pour résoudre le sous-ensemble d'instances touchées.

8. 23 juillet 2026 à 12:49 UTCidentified

   Avec la correction de configuration déployée, nous continuons à résoudre le sous-ensemble des instances encore touchées.

9. 23 juillet 2026 à 14:07 UTCidentified

   Nous continuons de résoudre le sous-ensemble des cas encore touchés.

10. 23 juillet 2026 à 14:27 UTCidentified

    Nous continuons de résoudre le sous-ensemble des cas qui sont encore touchés.

11. 23 juillet 2026 à 14:44 UTCmonitoring

    Nous continuons de résoudre le sous-ensemble des cas qui sont encore touchés.

12. 23 juillet 2026 à 15:03 UTCmonitoring

    AuraDB Virtual Dediced Cloud et AuraDB Business Critical devraient tous maintenant être corrigés. Nous continuons à résoudre le sous-ensemble d'instances qui sont encore impactées pour AuraDB Professional et Free.

13. 23 juillet 2026 à 15:29 UTCmonitoring

    Nous continuons à résoudre le sous-ensemble d'instances qui sont encore impactées pour AuraDB Professional et Free.

14. 23 juillet 2026 à 15:57 UTCmonitoring

    Nous continuons à résoudre le sous-ensemble d'instances qui sont encore touchées pour AuraDB Professional et Free.

15. 23 juillet 2026 à 16:32 UTCmonitoring

    Nous continuons à résoudre le sous-ensemble d'instances qui sont encore impactées pour AuraDB Professional et Free

16. 23 juillet 2026 à 17:01 UTCmonitoring

    Nous continuons à corriger un sous-ensemble d'instances qui sont encore impactées pour AuraDB Professional et Free

17. 23 juillet 2026 à 17:31 UTCmonitoring

    Nous continuons à corriger un petit sous-ensemble d'instances qui sont encore touchées par les niveaux AuraDB Professional et Free.

18. 23 juillet 2026 à 18:07 UTCmonitoring

    Nous avons abordé la question dans toutes les instances professionnelles AuraDB. Aura Free peut encore être affectée. Nous continuerons de surveiller et de réparer les bases de données restantes.

19. 23 juillet 2026 à 19:39 UTCmonitoring

    Nous continuons à corriger un petit sous-ensemble d'instances libres qui sont toujours touchées.

20. 24 juillet 2026 à 06:00 UTCmonitoring

    Nous continuons de suivre de près la situation pour toute autre question.

21. 24 juillet 2026 à 08:30 UTCmonitoring

    Nous restons à l'affût de tout autre problème.

22. 24 juillet 2026 à 12:59 UTCmonitoring

    Tous les cas identifiés ont été corrigés et continuent de surveiller. Contactez le support client pour tout autre problème.

23. 24 juillet 2026 à 15:56 UTCresolved

    Toutes les corrections ont été déployées et la question est maintenant traitée comme résolue.

24. 29 juillet 2026 à 21:58 UTCpostmortem

    Que s'est-il passé ? Le jeudi 23 juillet, 2026 10:33 UTC un changement de configuration a été déployé à Aura qui a modifié involontairement comment les allocations de mémoire ont été calculées pour les instances de base de données. Par conséquent, un sous-ensemble d'instances a reçu une mémoire insuffisante, ce qui a rendu certaines instances de base de données indisponibles ou incapables de compléter les mises à jour. L'allocation de mémoire ajustée a conduit à des conditions hors de mémoire, ce qui a provoqué le redémarrage répété des instances de base de données en raison de ressources de mémoire insuffisantes ou de la mise à jour bloquée. Ce problème a affecté les instances de plusieurs fournisseurs de cloud et de plusieurs niveaux de produits. Une fois le problème identifié, nous avons immédiatement retourné la modification de configuration, empêchant toute autre instance de recevoir la configuration incorrecte. Une configuration corrigée a été déployée à la production le jeudi 23 juillet 2026 11:56 UTC. Cependant, les cas de base de données qui avaient déjà reçu la configuration incorrecte nécessitaient des actions de récupération individuelles avant qu'ils puissent revenir à une opération normale. Jeudi 23 juil. 2026 17:59 UTC, toutes les instances connues de la base de données impact clients ont été récupérées. La surveillance s'est poursuivie le lendemain, l'incident ayant été entièrement résolu le vendredi 24 juillet 2026, 16 h 30 UTC. ** Comment le service a été affecté** Le principal impact client a été que plusieurs instances de base de données AuraDB sont devenues indisponibles ou sont entrées dans un état dégradé. Les cas touchés n'étaient pas en mesure de compléter les mises à jour courantes des logiciels et, dans certains cas, ont été redémarrés à plusieurs reprises parce que la mémoire était insuffisante. * ** Disponibilité du service :** L'impact du client varie selon le niveau de service. AuraDB Les instances professionnelles, qui ne fournissent pas de haute disponibilité, ont connu le plus grand niveau de perturbation du service, un sous-ensemble devenant indisponible et incapable de traiter des lectures ou des écrits. En ce qui concerne les cas d'AuraDB Business Critical et Virtual Dedicated Cloud \(VDC\) affectés, l'impact était généralement limité à une perte temporaire de tolérance à la défaillance pendant que la disponibilité du service était maintenue. Dans un petit nombre de cas, les instances Business Critical et VDC sont également devenues indisponibles. * ** Mises à jour sur place** : D'autres instances sont restées disponibles mais ont été coincées dans un état de "mise à jour", qui a bloqué les opérations initiées par le client comme les redimensionnements ou les modifications de configuration. * ** Portée de la plate-forme de choc**: L'impact a touché les trois fournisseurs de cloud et plusieurs régions, affectant les clients dans le monde entier. Des cas de soutien à la clientèle ont été soulevés et notre équipe a trié et récupéré manuellement les instances touchées en ordre de priorité. La majorité des cas d'AuraDB ont continué à fonctionner normalement. L'impact client a été pleinement atténué par le retour de configuration et la récupération manuelle ciblée de chaque instance touchée. Ce que nous faisons maintenant Nous avons procédé à une analyse approfondie de cet incident et nous avons identifié les mesures suivantes : * **Prévention** * ** Validation améliorée du déploiement :** Nous renforçons notre processus de validation pour mieux identifier les changements de configuration. * **Découplage du composant**: Nous évaluons les améliorations apportées au séquençage des déploiements de composantes afin de réduire le risque que des changements imprévus soient inclus dans les rejets. * **Stratégie de déploiement progressive**: Nous examinons le processus de déploiement des composants touchés pour les aligner sur les contrôles de déploiement utilisés pour les autres composants critiques. * **Détection** * **Mieux alerter**: Nous améliorons notre surveillance afin de détecter des augmentations anormales des taux de défaillance \(comme la perte de la tolérance aux défauts ou la disponibilité\) plus rapidement et de manière plus fiable. * **Mitigation** * **Déploiement de la configuration du coffre :** Nous améliorons la façon dont les changements de configuration de production sont déployés afin qu'ils puissent être désactivés ou revalorisés plus rapidement sans nécessiter une version plus large du logiciel. * ** Outillage manuel de récupération de grille** : Nous améliorons notre outil de récupération afin de réduire le temps nécessaire pour identifier et récupérer manuellement les instances touchées. Nous reconnaissons la perturbation que cet incident a causée et nous nous excusons de l'impact sur les clients touchés. Nous avons terminé les mesures correctives immédiates, et les améliorations à long terme décrites ci-dessus sont déjà en cours pour réduire la probabilité et l'impact d'incidents semblables à l'avenir.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 juillet 2026 à 17:18 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant la Console Aura où certains clients pourraient ne pas être en mesure de voir leurs instances. Cette question est causée par un échec dans un service tiers dont dépend Aura. Les instances touchées continuent de fonctionner normalement, et la connectivité à la base de données n'est pas affectée. Notre équipe enquête activement sur le problème.

2. 10 juillet 2026 à 17:23 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 10 juillet 2026 à 17:51 UTCmonitoring

   Le service tiers dont dépend Aura a rétabli des opérations normales et les systèmes Neo4j Aura ont récupéré. Notre équipe surveille activement la question pour confirmer que Aura Console fonctionne comme prévu.

4. 10 juillet 2026 à 19:23 UTCresolved

   Les services sont confirmés opérationnels et aucune interruption supplémentaire n'est prévue.

5. 27 juillet 2026 à 04:28 UTCpostmortem

   Ce qui s'est passé Aura Console et d'autres composants Aura ont subi des perturbations le 2026-07-10 à 16:14 UTC, entraînant des défaillances et des crashloops. Par conséquent, un segment de clients a dû faire face à des problèmes de visibilité concernant leurs cas. Il a été causé par une panne dans un service externe tiers intégré à Aura. La connectivité des bases de données n'a pas été compromise, et les instances touchées ont poursuivi leurs opérations normales. LaunchDarkly service a été rétabli pour résoudre le problème ## Comment le service a été affecté Plusieurs composants Aura, dont la Console Aura, ont subi des perturbations. Les utilisateurs ont rencontré 500 erreurs HTTP sur les pages et les opérations liées à la base de données, bien que les organisations et les projets puissent encore être consultés. Les connexions directes à des instances spécifiques de la base de données n'étaient pas complètement affectées Le plan de contrôle est devenu indisponible, ce qui signifie que les utilisateurs ne peuvent pas créer, supprimer, redimensionner ou ajuster les paramètres pour des cas via l'API ou la console Aura. Toutefois, les cas existants sont restés opérationnels. Le problème a été causé par une panne sur LaunchDarkly et nos services n'ont pas géré cet échec de dépendance gracieusement pendant le démarrage. Tous les systèmes touchés sont retournés au fonctionnement normal avant 2026-07-10 à 17h07 UTC Qu'est-ce qu'on fait maintenant L'équipe d'ingénierie Neo4j a rapidement diagnostiqué la cause profonde et rétabli le service. Lors de l'évaluation de cet incident, nous avons identifié des domaines clés pour accélérer les résolutions futures et atténuer les risques de récidive : * Analyse des paramètres clés de l'incident, en mettant l'accent sur la durée de l'alerte à la réponse afin de déterminer les possibilités d'accélérer l'efficacité de l'intervention. * Réalisation d'une rétrospective exhaustive mettant en évidence les résultats positifs, y compris l'analyse rapide des causes profondes grâce à l'enregistrement transparent, l'alignement sans faille grâce à l'outil de gestion des incidents et la dégradation résiliente et gracieuse de plusieurs composants qui ont maintenu la connectivité du plan de données intacte * Développement actif de fallbacks plus gracieuses par défaut pour les drapeaux de fonction pour protéger les opérations de base pendant les temps d'arrêt des fournisseurs * Renforcer la résilience architecturale en intégrant la planification avancée, les pratiques d'ingénierie du chaos et les essais d'injection de défauts au niveau de la production afin de découvrir et d'atténuer de façon préventive les trajectoires potentielles de défaillance * Abordé les limitations logiques dans la fonction de cache de drapeau de l'opérateur, soulignant la nécessité pour les opérateurs de stocker des drapeaux évalués localement pour préserver la continuité opérationnelle si les dépendances externes échouent.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 30 juin 2026 à 14:45 UTCidentified

   Lancer CREATE VECTOR INDEX échoue avec l'erreur 51N31 erreur: configuration du système ou exception de fonctionnement - non supporté. Créer un index vectoriel avec les paramètres fournis n'est pas pris en charge dans V2026 02. La version requise pour l'opération est V2026 06. Veuillez mettre à jour DBMS.. Cela affecte seulement un nouvel indice, l'INDEX VECTOR existant n'est pas affecté. Tout indice vectoriel créé avant 2026-06-30 à 09:00 continue à fonctionner normalement.

2. 30 juin 2026 à 15:41 UTCidentified

   Nous commençons maintenant à déployer un correctif pour régler ce problème et nous ferons le point sur les progrès réalisés.

3. 30 juin 2026 à 16:05 UTCmonitoring

   Une solution se déroule et progresse bien. Nous mettrons à jour les progrès réalisés.

4. 30 juin 2026 à 17:45 UTCresolved

   La correction a été entièrement déployée dans toutes les instances touchées. Cet incident est maintenant résolu.

5. 20 juillet 2026 à 08:40 UTCpostmortem

   Ce qui s'est passé Un problème a été identifié à la suite du déploiement de la version 2026.06 le 2026-06-30 à 08:00 UTC, où l'exécution de `CREATE VECTOR INDEX` sur des instances Aura mises à jour a déclenché une exception système. Cette défaillance dans la génération d'index s'est produite parce que le stockage sous-jacent et le noyau ont exigé des mises à jour supplémentaires pour soutenir l'opération Ce problème n'a eu qu'une incidence sur la création de nouveaux index; les index vectoriels existants ne sont pas affectés. Tout indice vectoriel créé avant 09:00 le 2026-06-30 n'était pas affecté et continuait à fonctionner normalement. ## Comment le service a été affecté Après le déploiement de la version 2026.06, l'exécution de l'instruction CREATE VECTOR INDEX a échoué, impactant des applications qui dépendaient de l'ajout de nouveaux index vectoriels. Les clients touchés ont reçu l'erreur : Créer un index vectoriel avec les paramètres fournis n'est pas pris en charge dans V2026\ 02. La version requise pour le fonctionnement est V2026\ 06. Veuillez mettre à jour DBMS . Les index existants \(créés avant cet incident\) et d'autres requêtes sont restés entièrement inchangés et pleinement fonctionnels. Qu'est-ce qu'on fait maintenant Les équipes Neo4j ont identifié la cause racine comme un bug dans le planificateur Cypher et ont résolu le problème avec une correction de code. Cette correction a été déployée dans toutes les instances Aura concernées, en résolvant complètement l'erreur Afin de prévenir les événements futurs, nous améliorons nos systèmes de surveillance et d'alerte afin de détecter des problèmes similaires plus tôt, particulièrement dans les environnements de mise en scène, avant que des déploiements ne se produisent. Simultanément, nous perfectionnons nos processus de déploiement pour minimiser l'impact client et les temps de récupération En outre, nous étudions les options pour mettre en œuvre des tests de validation automatisés et post-upgrade spécifiquement pour les opérations critiques telles que la création d'index vectoriaux

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 juin 2026 à 11:25 UTCidentified

   Aura console connaît quelques erreurs intermittentes: "Notre système connaît des problèmes en ce moment. essayer de nouveau plus tard ou contacter le support si le problème persiste." Cela peut vous obliger à recharger ou à attendre plus longtemps pour naviguer dans la console Les opérations et l'API Aura restent inchangées Nous travaillons activement sur une solution

2. 23 juin 2026 à 13:03 UTCidentified

   Nous continuons d'étudier une solution au problème

3. 23 juin 2026 à 13:39 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

4. 23 juin 2026 à 15:43 UTCmonitoring

   Nous déployons un changement. Nous surveillerons et mettrons à jour.

5. 23 juin 2026 à 19:27 UTCmonitoring

   Continuer de surveiller les changements déployés. Prochaine mise à jour prévue 6/24/2026 10h UTC.

6. 24 juin 2026 à 09:14 UTCmonitoring

   Nous avons vérifié et confirmé que la question est maintenant entièrement réglée.

7. 24 juin 2026 à 09:14 UTCresolved

   Cet incident a été résolu.

8. 10 juillet 2026 à 14:50 UTCpostmortem

   Ce qui s'est passé Le 22 janvier 2026, vers 12h00 UTC, les utilisateurs ont rencontré des bannières d'erreur intermittentes dans la console Aura : « Nous avons un problème. Essayez à nouveau. », qui s'est produit aux côtés de 500 erreurs des paramètres API console. Ces perturbations ont été transitoires et causées par le timing interne de l'API au cours du processus de poignée de main TLS, se résolvant généralement dans environ 10 secondes ou après une mise à jour de page ## Comment le service a été affecté L'API Console et Aura a connu des performances dégradées, qui se sont manifestées comme bannières d'erreur intermittentes dans l'interface utilisateur console Aura. Une enquête a identifié la cause racine comme l'utilisation élevée du processeur et le grottling dans l'API console. Cette question était principalement due à des listes répétées de grandes entités et à des demandes de rapprochement coûteuses. Pour résoudre ce problème, des correctifs ciblés ont été déployés avec succès sur la console Aura et l'API Aura. Ensuite, des ajustements ont été apportés à la configuration des ressources afin d'accroître la salle de classe opérationnelle et d'assurer la stabilité. Qu'est-ce qu'on fait maintenant Les mesures réactives et proactives suivantes ont été mises en œuvre pour réduire la probabilité d'incidents semblables : * Élaboration d'un tableau de bord de surveillance pour observer les gouttes de requête basées sur les données internes du journal de l'API pour mettre en œuvre la surveillance automatisée et l'alerte aux problèmes de capture avant qu'ils ne se produisent * Mise en œuvre d'un délai échelonné entre les demandes de rapprochement paginé afin d'atténuer la consommation élevée de ressources et d'améliorer la stabilité de l'API * Amélioration des calculs des ressources de sensibilisation à l'infrastructure pour améliorer les performances * Introduit un nouveau filtre pour les requêtes basées sur les niveaux de service pour optimiser les frais généraux du processeur pour chaque appel effectué par le conciliateur * Traitement redondant désactivé de requêtes pour optimiser les appels API

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 26 mai 2026 à 18:23 UTCinvestigating

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

2. 26 mai 2026 à 19:19 UTCmonitoring

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

3. 26 mai 2026 à 23:06 UTCresolved

   This incident has been resolved.

4. 9 juin 2026 à 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 mars 2026 à 10:18 UTCidentified

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

2. 6 mars 2026 à 10:24 UTCmonitoring

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

3. 6 mars 2026 à 10:25 UTCresolved

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

4. 30 mars 2026 à 07:25 UTCpostmortem

   ## What Happened On March 6, at 10:04 AM UTC,  the Aura Console became inaccessible following a recent deployment. The deployment included changes related to user organizations and switching to an org memberships entity. This change caused the console to become inaccessible for a short period. ## How the service was affected A deployment to the Aura Console introduced an issue that caused an unexpected increase in backend requests related to access validation. This led to elevated CPU usage, which impacted the availability of the console and dependent services. We rolled back to a previous version to restore access. The rollback ensured the full restoration of access to the Aura Console, resolving the core issue within the incident window ## What are we doing now We are currently implementing a comprehensive strategy to bolster system resilience and prevent future recurrence. Our immediate actions include integrating stricter and more robust safeguards into the deployment pipeline. Crucially, we are significantly enhancing our validation processes to proactively detect and flag any potential performance impacts _before_ code is promoted to the production environment

1. 3 mars 2026 à 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 mars 2026 à 01:39 UTCidentified

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

3. 4 mars 2026 à 04:52 UTCidentified

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

4. 4 mars 2026 à 14:07 UTCmonitoring

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

5. 4 mars 2026 à 15:19 UTCresolved

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

6. 8 avril 2026 à 06:39 UTCpostmortem

   ## What Happened An issue was introduced in the Neo4j 2026.02 release where MERGE queries that referenced the same property on both the left and right sides of an `ON MATCH SET` or `ON CREATE SET` clause could potentially delete that property from the node or set it to an invalid value during query execution. This behaviour was observed specifically when the node being matched had at least one property uniqueness constraint. ## How the service was affected A change in the Neo4j 2026.02 release introduced a potential risk of writes failing or invalid data being returned for queries using MERGE together with `ON MATCH`. This issue affected instances across Aura tiers and required immediate investigation by Neo4j Engineering. The team identified the root cause and deployed a fix in version 2026.02.1. ## What are we doing now The following proactive measures have been implemented to reduce the likelihood of similar incidents: * We have strengthened test coverage for `ON CREATE` and `ON MATCH` clauses, particularly those involving more complex expressions. * We are investigating additional safeguards to improve our ability to control MergeInto/MergeUnique behaviour more flexibly, as well as potential rollback capabilities to support recovery in future incidents

1. 2 mars 2026 à 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 mars 2026 à 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 mars 2026 à 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 mars 2026 à 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 mars 2026 à 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)

1. 26 janvier 2026 à 19:26 UTCidentified

   Nous avons identifié un problème qui pourrait affecter un ensemble limité de requêtes Cypher 25 pour AuraDB Free, Professional et AuraDS. Cela peut affecter: - Interroge l'utilisation de la requête conditionnelle WHEN en combinaison avec une agrégation non-groupée sur des valeurs null, ce qui entraîne un nombre incorrect de lignes retournées. - Les requêtes utilisant NEXT peuvent produire une variable inattendue non définie erreur dans certains cas. Nous travaillons activement sur un correctif et mettrons à jour cette page à mesure que de plus amples informations seront disponibles.

2. 27 janvier 2026 à 01:37 UTCidentified

   Nous avons trouvé une solution à ce problème et nous nous lancerons à Aura. Une fois la mise à jour déployée, nous mettrons à jour cette page de tatus.

3. 27 janvier 2026 à 09:50 UTCidentified

   Nous déployons le correctif et vous mettrons à jour lorsque cela sera terminé.

4. 27 janvier 2026 à 11:10 UTCmonitoring

   La correction s'est déployée sur les composants affectés, nous suivons maintenant la situation.

5. 27 janvier 2026 à 14:51 UTCmonitoring

   Nous continuons de suivre la situation à l'heure actuelle.

6. 27 janvier 2026 à 15:58 UTCresolved

   La correction a été entièrement déployée dans toutes les instances touchées. Cet incident est maintenant résolu.

7. 2 juillet 2026 à 04:22 UTCpostmortem

   Ce qui s'est passé Neo4j a commencé le déploiement de la version 2026.01.1 à Aura à 07:49 UTC le 26 janvier 2026. À la suite de la détection des défaillances lors des tests internes, le déploiement a été interrompu avant d'atteindre les niveaux supérieurs d'Aura. Les défaillances se sont produites sur les requêtes conditionnelles \(par exemple WHEN ...THEN ...\) après la phase planificateur pour se comporter différemment en cas d'agrégation sur des valeurs nulles. Nous avons identifié la cause profonde et développé une résolution, qui a été intégrée dans la version 2026.01.2. Le 27 janvier 2026, nous avons commencé à déployer 2026.01.2 dans les instances Aura, mettant à jour avec succès tous les environnements touchés à la version corrigée ## Comment le service a été affecté Les requêtes utilisant WHEN en 2026.01.1 en combinaison avec l'agrégation sur les valeurs null obtiennent un nombre incorrect de lignes retournées. Les requêtes utilisant NEXT peuvent dans certains cas produire une variable inattendue non définie erreur. Cela a amené la requête réécrite à se comporter différemment en cas d'agrégation sur des valeurs nulles. La requête conditionnelle devrait recevoir les lignes entrantes contenant des valeurs null et être agrégeant sur les valeurs sans utiliser un groupement. Les clients ont reçu un résultat incorrect s'ils utilisaient la construction de requêtes conditionnelles dans Cypher 25 \(voir [https://neo4j.com/docs/aura/managing-instances/cypher-version/](https://neo4j.com/docs/aura/managing-instances/cypher-version/)\), un impact limité à un nombre limité d'instances Aura. Qu'est-ce qu'on fait maintenant Nous avons amélioré nos procédures d'essai pour assurer une couverture complète dans tous les secteurs de produits. Cela comprend l'élaboration de nouveaux cas d'essai conçus pour traiter à la fois des problèmes identifiés et des scénarios futurs potentiels. De plus, nous avons intégré les tests de requête Cypher dans Aura en tant que composant standard de notre suite de tests de régression. Ces vérifications sont maintenant des étapes obligatoires dans notre pipeline d'intégration continue et nos environnements de mise en scène avant tout déploiement de production.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 janvier 2026 à 14:25 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. 16 janvier 2026 à 15:13 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. 16 janvier 2026 à 17:07 UTCmonitoring

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

4. 16 janvier 2026 à 19:36 UTCresolved

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

5. 23 avril 2026 à 13:27 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. 26 novembre 2025 à 15:47 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. 26 novembre 2025 à 20:33 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. 27 novembre 2025 à 14:33 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. 27 novembre 2025 à 17:07 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. 28 novembre 2025 à 00:09 UTCidentified

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

6. 28 novembre 2025 à 10:55 UTCidentified

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

7. 28 novembre 2025 à 16:23 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. 1 décembre 2025 à 09:54 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. 5 décembre 2025 à 10:20 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. 5 décembre 2025 à 16:59 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. 11 décembre 2025 à 10:24 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. 11 décembre 2025 à 15:39 UTCresolved

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

13. 4 février 2026 à 15:18 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. 18 novembre 2025 à 15:56 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. 18 novembre 2025 à 16:16 UTCmonitoring

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

3. 18 novembre 2025 à 16:39 UTCresolved

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

4. 14 janvier 2026 à 14:05 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. 20 octobre 2025 à 16:43 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. 20 octobre 2025 à 19:14 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. 20 octobre 2025 à 21:28 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. 15 janvier 2026 à 17:48 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. 20 octobre 2025 à 09:15 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. 20 octobre 2025 à 09:39 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. 20 octobre 2025 à 09:58 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. 20 octobre 2025 à 10:32 UTCmonitoring

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

5. 20 octobre 2025 à 11:13 UTCresolved

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

6. 15 janvier 2026 à 17:34 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. 25 août 2025 à 13:34 UTCinvestigating

   We are currently investigating this issue.

2. 25 août 2025 à 13:36 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. 25 août 2025 à 13:47 UTCinvestigating

   We are continuing to investigate this issue.

4. 25 août 2025 à 15:34 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. 25 août 2025 à 21:44 UTCmonitoring

   We continue to work towards the issue resolution.

6. 26 août 2025 à 04:06 UTCmonitoring

   We are continuing to investigate this issue.

7. 26 août 2025 à 10:53 UTCmonitoring

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

8. 26 août 2025 à 14:48 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. 26 août 2025 à 23:12 UTCmonitoring

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

10. 27 août 2025 à 06:36 UTCmonitoring

    We are continuing to monitor for any further issues.

11. 27 août 2025 à 11:16 UTCmonitoring

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

12. 27 août 2025 à 16:46 UTCresolved

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

13. 6 octobre 2025 à 13:32 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. 22 août 2025 à 11:02 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. 22 août 2025 à 11:42 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. 22 août 2025 à 13:31 UTCresolved

   This incident has been resolved.

4. 12 septembre 2025 à 15:45 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.