Historique des pannes de Neo4j Aura

1. 26 octobre 2026 à 14:50 UTCinvestigating

   Nous sommes actuellement au courant d'un problème qui affecte les clients utilisant Aura sur Azure, lors de la tentative de télécharger des instantanés d'instance de base de données.

2. 26 octobre 2026 à 15:09 UTCidentified

   Nous avons identifié le problème et travaillons actuellement au déploiement de la correction.

3. 26 octobre 2026 à 16:22 UTCidentified

   Le fix est actuellement testé dans des environnements inférieurs, avant d'être déployé.

4. 26 octobre 2026 à 17:43 UTCidentified

   Les essais se poursuivent et le déploiement se fera une fois les essais terminés.

5. 26 octobre 2026 à 19:14 UTCresolved

   Nos ingénieurs ont déployé avec succès une solution, et le problème est maintenant résolu. Les clients Aura sur Azure peuvent maintenant télécharger des instantanés de base de données sans problèmes.

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

1. 20 octobre 2026 à 07:35 UTCinvestigating

   Nous enquêtons actuellement sur une question qui touche la région Europe-Ouest 2 du GCP et qui a une incidence sur certaines opérations, y compris la création d'exemples de base de données dans la région.

2. 20 octobre 2026 à 08:36 UTCinvestigating

   Nous continuons d'enquêter sur la question actuellement, en travaillant avec le GCP pour trouver une solution. À l'heure actuelle, certaines opérations, y compris la création d'exemples de base de données dans la région, continuent d'être touchées.

3. 20 octobre 2026 à 09:15 UTCidentified

   Nous avons identifié la source du problème qui affecte actuellement les clients sur l'europe-west2 sur GCP. De plus amples renseignements sont disponibles sur la page d'état du GCP à l'adresse https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj. À l'heure actuelle, certaines opérations, y compris la création d'exemples de base de données dans la région, continuent d'être touchées.

4. 20 octobre 2026 à 10:42 UTCidentified

   Nous mettons actuellement en œuvre des mesures correctives pour atténuer la question dans l'intervalle. Suivez les dernières données de GCP sur la page d'état à https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.

5. 20 octobre 2026 à 12:38 UTCmonitoring

   La fonctionnalité devrait maintenant être rétablie dans les services Aura concernés. Nous surveillerons la situation de près avant d'envisager cette solution.

6. 20 octobre 2026 à 14:06 UTCmonitoring

   Nous continuons à surveiller la situation avec le PCG à l'heure actuelle et, à ce stade, nous n'avons pas vu de nouveaux problèmes.

7. 20 octobre 2026 à 14:50 UTCresolved

   Cet incident a été résolu

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

1. 13 octobre 2026 à 09:15 UTCinvestigating

   Nous enquêtons sur un problème touchant les mesures dans la Console Aura et via le paramètre métrique.

2. 13 octobre 2026 à 10:13 UTCidentified

   Nous avons constaté qu'un problème lié au fournisseur de services Cloud a une incidence sur la situation actuelle. Nous avons ouvert un dossier de support avec le fournisseur de services Cloud et nous le mettrons à jour une fois que nous aurons plus de détails.

3. 13 octobre 2026 à 11:01 UTCmonitoring

   Nous croyons que le problème du fournisseur de services Cloud a été résolu, car nous ne voyons plus de problèmes de nos systèmes internes. Nous continuerons à surveiller la situation, en attendant la confirmation du fournisseur de services Cloud.

4. 13 octobre 2026 à 12:08 UTCresolved

   Nous avons reçu la confirmation du fournisseur de services Cloud que le problème a maintenant été entièrement résolu.

5. 16 octobre 2026 à 17:06 UTCpostmortem

   **Erreurs lors de l'envoi des métriques de GCP europe-west1** **Ce qui s'est passé** Le mardi 13 octobre, 2026 à 08:54 UTC, les métriques pour les cas de GCP europe-west1 ont cessé d'être livrées et n'ont pu être lues. La cause était un problème du côté de Google Cloud, où une réduction de capacité de son service de surveillance a conduit à des demandes valides ont été incorrectement rejetées. Les mesures sont revenues à la normale à 10:49 UTC après que Google Cloud ait appliqué une correction, et nous avons résolu l'incident à 12:08 UTC une fois Google Cloud confirmé la pleine résolution. Les installations sont restées disponibles tout au long de cet événement, sans impact sur la performance de la requête ou l'intégrité des données. Seule la visibilité des mesures a été affectée. **Comment le service a été affecté** Les clients ont vu de courtes lacunes dans les paramètres d'instance : * **Mesures de la console:** Les cas de GCP europe-west1 peuvent avoir montré des données métriques incomplètes ou manquantes pendant la fenêtre d'incident. * **Cloud Surveillance de l'intégration \(CMI\):** Les mesures transmises à vos propres systèmes de surveillance de cette région peuvent aussi avoir des lacunes. Tous les cas dans la région n'ont pas été touchés, et d'autres fournisseurs de cloud et régions n'ont pas été touchés. Les mesures générées pendant l'incident n'ont pas été enregistrées, de sorte que l'écart restera dans les graphiques historiques des instances touchées. Ce que nous faisons maintenant La correction est venue de Google Cloud à cette occasion, mais notre pipeline de métriques s'est appuyé sur un chemin d'une seule région, donc nous prenons des mesures pour réduire cette exposition: * **Resilience régionale:** Nous évaluons le routage transrégional afin que le trafic de métriques puisse échouer vers une région saine. * ** Trafic :** Nous explorons des options dans notre couche de réseau cloud pour réacheminer à la fois \(Console et CMI\) et écrit \(ingestion\) loin d'une région touchée.

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

1. 8 octobre 2026 à 14:58 UTCinvestigating

   Nous enquêtons sur un problème avec les mesures dans la Console Aura et via le paramètre métrique.

2. 8 octobre 2026 à 15:36 UTCidentified

   Nous continuons d'enquêter sur la cause profonde. Le problème est limité aux clients sur nous-central1 sur GCP Les instances Aura fonctionnent et aucune opération n'est affectée.

3. 8 octobre 2026 à 16:30 UTCidentified

   Nous travaillons avec le fournisseur de services en nuage pour étudier la nature du problème. Nos contrôles confirment que seul un sous-ensemble de clients opérant dans les régions du centre1 est affecté.

4. 8 octobre 2026 à 18:41 UTCidentified

   Nous continuons à travailler avec le fournisseur de services cloud pour obtenir une solution.

5. 8 octobre 2026 à 19:11 UTCresolved

   Cet incident a maintenant été résolu, les mesures devraient maintenant fonctionner comme normale.

6. 16 octobre 2026 à 17:04 UTCpostmortem

   **Erreurs lors de l'envoi des métriques de GCP-central1** **Ce qui s'est passé** Le jeudi 8 octobre, 2026 à 14:05 UTC, les métriques de certains cas dans GCP nous-central1 ont cessé d'être livrées. La cause était un problème du côté Google Cloud qui a rejeté incorrectement les requêtes métriques valides. La livraison métrique a repris à 18h00 UTC après que Google Cloud ait appliqué une correction, et nous avons résolu l'incident à 18h48 UTC. Les installations sont restées disponibles tout au long de cet événement, sans impact sur la performance de la requête ou l'intégrité des données. Seule la visibilité des mesures a été temporairement affectée. **Comment le service a été affecté** Les clients ont vu des lacunes dans les paramètres d'instance : * **Mesures de la console:** Les cas dans GCP us-central1 peuvent avoir montré des données métriques incomplètes ou manquantes pendant la fenêtre d'incident. * **Cloud Surveillance de l'intégration \(CMI\):** Les mesures transmises à vos propres systèmes de surveillance de cette région peuvent aussi avoir des lacunes. Toutes les instances de la région n'ont pas été touchées, et d'autres fournisseurs et régions de cloud n'ont pas été touchés. Ce que nous faisons maintenant La correction est venue de Google Cloud, mais nous prenons des mesures pour attraper et répondre à des événements similaires plus tôt: * **Agrément des erreurs de livraison métriques :** Nous ajoutons l'alerte sur les taux d'erreur de transmission métrique, de sorte que les défaillances côté fournisseur sont détectées plus tôt et distinguées des lacunes de routine. * ** Suivi continu :** Nous continuerons à surveiller la région avec Google Cloud pour toute récurrence.

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

1. 6 octobre 2026 à 09:22 UTCinvestigating

   Nous enquêtons sur un problème où, malgré les sauvegardes terminées avec succès, les téléchargements instantanés retournent les dumps vides. La restauration à partir d'un instantané via la console ou l'API Aura n'est pas censée être affectée, et nous en vérifions maintenant. Nous partagerons une mise à jour dès que nous aurons plus d'informations.

2. 6 octobre 2026 à 10:43 UTCinvestigating

   Nous continuons d'enquêter sur cette question. Les opérations de restauration ne sont pas touchées dans le cadre de cette question.

3. 6 octobre 2026 à 13:41 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

4. 6 octobre 2026 à 13:41 UTCinvestigating

   Nous poursuivons nos recherches sur le problème.

5. 6 octobre 2026 à 15:19 UTCresolved

   Une correction a été déployée; les téléchargements instantanés contiennent maintenant les données appropriées.

6. 26 octobre 2026 à 08:58 UTCpostmortem

   Que s'est-il passé ? Le ven, 18 sept. 2026 14:33 UTC, nous avons identifié que les téléchargements instantanés pour les instances Aura hébergées sur Azure retournaient des fichiers d'environ 24Ko au lieu de la taille multi-gigaoctets attendue. Les sauvegardes sous-jacentes stockées dans Azure étaient la bonne taille, mais le chemin de téléchargement dans la console servait des fichiers presque vides. La cause profonde était un problème de reconnaissance Azure qui s'est produit lors d'un déploiement et a empêché que des données de sauvegarde soient fournies pour téléchargement. Une première correction a été déployée sur lun, 21 Sep 2026 10:31 UTC, la restauration des tailles de téléchargement correctes. Cependant, le même numéro de reconnaissance a réapparu sur mar, 06 Oct 2026 08:20 UTC, produisant à nouveau des téléchargements instantanés en blanc sur tous les niveaux Azure. Notre équipe d'ingénierie a identifié la récurrence, l'a liée à la même cause racine, a déployé un correctif d'identification ciblé à la production, et a vérifié que les téléchargements sont revenus à leur taille prévue. Nous n'avons pas posté sur la page d'état le 18 septembre parce qu'un petit nombre de clients ont été touchés, et nous avons travaillé avec eux directement. Nous avons posté le 6 octobre à 09:22 UTC, environ une heure après le début de la récurrence, une fois qu'elle était clairement plus large. # Comment le service a été affecté Les téléchargements instantanés ont été touchés pour les instances AuraDS Professional et Enterprise, AuraDB Professional, Business Critical et Virtual Dediced Cloud fonctionnant sur Azure. * Les téléchargements instantanés ont retourné des fichiers inutilisables. Lorsque les clients ont téléchargé des instantanés de la console, ils ont reçu des fichiers d'environ 24Ko au lieu des données de sauvegarde réelles, ce qui pourrait être plusieurs gigaoctets de taille. Cela a rendu les instantanés téléchargés inutilisables à des fins de restauration hors ligne ou de migration. * Les sauvegardes elles-mêmes n'étaient pas perdues. Les artefacts de sauvegarde sous-jacents stockés à Azure sont restés intacts et correctement dimensionnés. Le problème était strictement dans le chemin de téléchargement, pas dans le processus de capture ou de stockage de sauvegarde. * La restauration via la console n'a pas été affectée. Les opérations de restauration en plate-forme \(par opposition au téléchargement d'un fichier dump\) ont continué à fonctionner parce qu'ils ont accédé aux données de sauvegarde directement plutôt que par le chemin de téléchargement affecté. Ce que nous faisons maintenant Nous avons pris de multiples mesures pour résoudre le problème et mis en place des mesures de protection pour éviter que cela ne se reproduise. * Correction de la valeur probante déployée. Nous avons corrigé le problème de reconnaissance Azure dans la production, qui a immédiatement restauré les téléchargements instantanés pour toutes les instances touchées. * Prévenir la rotation involontaire des titres. Un changement de code a été soumis pour revenir à la logique qui a déclenché la rotation des titres Azure pour chaque déploiement. Cela garantit que les déploiements futurs n'invalideront pas par inadvertance les pouvoirs existants, mécanisme qui a causé à la fois l'incident initial et sa récurrence. * Surveillance continue. Nous surveillons les téléchargements d'instantanés Azure à tous les niveaux pour confirmer qu'ils restent stables. Nous avons demandé aux clients touchés de vérifier que leurs téléchargements retournent maintenant les tailles de fichiers attendues. Ces changements portent à la fois sur le symptôme immédiat et sur le comportement de déploiement sous-jacent qui a permis au problème de se reproduire

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

1. 6 octobre 2026 à 08:07 UTCidentified

   Nous avons identifié un problème lorsque nous tentons de restaurer des instantanés sur AuraDS. Nous avons une solution prête et nous la déploierons bientôt. En attendant, vous pouvez restaurer à partir d'une sauvegarde à la place.

2. 6 octobre 2026 à 09:07 UTCidentified

   Nous avons clairement identifié la cause fondamentale et nous continuons de travailler sur une solution à cette question.

3. 6 octobre 2026 à 10:03 UTCidentified

   Nous continuons de travailler sur une solution à cette question.

4. 6 octobre 2026 à 12:14 UTCidentified

   Un correctif est en cours de déploiement et sera déployé prochainement auprès des clients touchés.

5. 6 octobre 2026 à 13:35 UTCmonitoring

   La solution est en marche et les clients touchés devraient voir la fonctionnalité rétablie progressivement.

6. 6 octobre 2026 à 14:04 UTCresolved

   Nous avons déployé la solution à tous les clients.

7. 26 octobre 2026 à 08:51 UTCpostmortem

   Que s'est-il passé ? Un défaut logiciel dans une composante de gestion centrale de Neo4j Aura snapshot restaure à l'échec pour les instances AuraDS Professional et AuraDS Enterprise hébergées sur AWS. Lorsqu'une restauration a été demandée, le système a cherché l'instance en utilisant un type de ressource incorrect et a retourné une erreur. L'incident a été déclaré le lundi 05 octobre 2026 21:52 UTC. Notre équipe d'ingénieurs a identifié la cause profonde, développé et validé un correctif, et l'a déployé à la production le mardi 06 octobre 2026 13:37 UTC. # Comment le service a été affecté L'impact a été projeté pour des opérations de restauration instantanée pour AuraDS Professional et AuraDS Enterprise instances. Les clients touchés n'ont pas été en mesure de restaurer des instantanés via la console Aura ou l'API Aura pour la durée du problème. * Restaurer les tentatives d'erreurs retournées, en perturbant les workflows qui dépendent des restaurations d'instantanés. * Des instances sont restées disponibles tout au long de cet événement. L'intégrité des données n'a pas été affectée. La restauration à partir des sauvegardes complètes et exportées est restée disponible comme solution de rechange. Ce que nous faisons maintenant * Nous avons corrigé le défaut dans la couche de gestion d'Aura qui a affecté AuraDS Professional et AuraDS Enterprise snapshot restaure et a déployé le correctif à la production. * Optimisation du pipeline de déploiement: Lors de cet incident, le pipeline de déploiement a pris plus de temps que l'idéal en raison de la création d'instances de test séquentielle. Nous avons évalué la parallélisation de la création d'instances de test pour réduire les temps d'attente pendant les déploiements critiques. Cette amélioration vise à raccourcir le temps qu'il faut pour valider et expédier une correction dans les incidents futurs, en réduisant l'impact face au client

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

1. 17 septembre 2026 à 16:46 UTCinvestigating

   Nous sommes actuellement conscients d'un problème qui affecte certaines opérations de base de données, comme créer, supprimer, clone pour les clients utilisant Aura sur Azure.

2. 17 septembre 2026 à 17:11 UTCidentified

   Nous avons identifié la question et nous travaillons à une solution. À l'heure actuelle, certaines opérations de base de données, comme créer, supprimer et cloner pour les clients utilisant Neo4j Aura uniquement sur Azure, continuent d'être affectées.

3. 17 septembre 2026 à 19:06 UTCmonitoring

   Une correction a été déployée dans tous les environnements touchés. Nous surveillerons la situation pour veiller à ce que la solution soit entièrement résolue.

4. 17 septembre 2026 à 19:55 UTCresolved

   Après avoir déployé la correction, nous avons surveillé les instances touchées, les paramètres opérationnels et les erreurs. Cet incident est maintenant résolu. Un post mortem sera disponible dès qu'il sera terminé.

5. 16 octobre 2026 à 16:23 UTCpostmortem

   Que s'est-il passé ? Le jeudi 17 septembre 2026 à 13h52 UTC, un conflit de temps de déploiement entre des opérations simultanées a provoqué l'élimination d'un titre utilisé par un composant de base Aura pour authentifier l'infrastructure hébergée par Azure. Lorsque les jetons d'authentification existants ont expiré, le composant a commencé à renvoyer des erreurs pour certaines instances Aura hébergées sur Azure, affectant certaines opérations de base de données. Nous avons retracé les erreurs au titre manquant, en avons créé une nouvelle, l'avons stockée en toute sécurité et nous avons effectué un déploiement roulant de la composante touchée, qui s'est terminé à 18h39 UTC. Un petit nombre de demandes de création de bases de données qui étaient en cours pendant la panne ont été laissées dans un état incomplet et ont besoin d'un assainissement manuel. Cela a été terminé à 19h48 UTC, et l'incident a été marqué résolu à 19h55 UTC. # Comment le service a été affecté L'impact a été limité aux instances Aura hébergées sur Azure. D'autres fournisseurs de cloud n'ont pas été touchés. * **Opérations de base de données :** Les clients n'ont pas pu effectuer certaines opérations de base de données, telles que créer, supprimer et cloner, sur certaines instances Azure pendant la fenêtre d'incident. Un petit nombre de créations en cours sont devenues bloquées et ont été récupérées manuellement. * **Visibilité de gestion :** Certaines instances hébergées par Azure n'étaient temporairement ni visibles ni gérables dans la console Aura. * **Différences de mesure:** Les paramètres de mesure pour certains cas d'azur ont retourné des erreurs intermittentes, laissant de courtes lacunes dans les données de mesure pour la période touchée. Ces données ne seront pas remplies à nouveau. Des cas d ' azur qui étaient déjà en cours d ' exécution sont demeurés disponibles et ont continué à servir normalement la charge de travail. Ce que nous faisons maintenant Nous prenons les mesures suivantes pour prévenir une récidive et améliorer notre réponse : * ** Détection et communication plus précoces :** Nous améliorerons la surveillance et l'alerte, et évaluerons les vérifications automatisées des titres de compétence, de sorte que les problèmes sont détectés et que les clients sont informés plus tôt. * **Reprise de la création incomplète de la base de données :** Nous corrigerons un défaut qui peut laisser une création de base de données bloquée si un appel d'infrastructure échoue par la partie, donc le système récupère de lui-même. * **Examen de l'authentification :** Nous examinerons comment ce composant s'authentifie avec les fournisseurs de cloud, pour supprimer les points d'échec uniques et réduire le risque de ce type de conflit récurrent.

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

1. 16 septembre 2026 à 08:50 UTCidentified

   Notre fournisseur de services pour le portail de support connaît une certaine panne - Voir https://status.salesforce.com/products/Salesforce Services Si vous éprouvez des problèmes à soumettre un nouveau dossier de support, veuillez envoyer un courriel à [email protected]

2. 16 septembre 2026 à 09:16 UTCidentified

   Notre fournisseur de portails d'assistance travaille toujours à résoudre le problème. Voir détails ici https://status.salesforce.com/incidents/20004433

3. 16 septembre 2026 à 10:11 UTCidentified

   Notre fournisseur de portail de soutien continue de s'occuper de la question. Voir détails ici https://status.salesforce.com/incidents/20004433

4. 16 septembre 2026 à 11:30 UTCmonitoring

   Une correction est en cours de déploiement et le portail devrait être moins affecté par les erreurs au fil du temps. Voir détails https://status.salesforce.com/incidents/20004433

5. 16 septembre 2026 à 12:29 UTCmonitoring

   Notre fournisseur de portail d'assistance continue de déployer un correctif.

6. 16 septembre 2026 à 14:31 UTCresolved

   Une correction a été déployée et toutes les fonctionnalités devraient maintenant être récupérées.

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

1. 9 septembre 2026 à 12:31 UTCinvestigating

   Nous enquêtons actuellement sur un problème affectant la console Aura console.neo4j.io et l'API api.neo4j.io

2. 9 septembre 2026 à 12:54 UTCidentified

   Nous avons identifié la source du problème et nous travaillons actuellement sur une solution.

3. 9 septembre 2026 à 13:10 UTCidentified

   Nous continuons de travailler sur cette question.

4. 9 septembre 2026 à 13:26 UTCidentified

   Nous avons fait de bons progrès et nous regagnons la composante problématique.

5. 9 septembre 2026 à 13:36 UTCmonitoring

   Nous avons déployé une solution et les services touchés se rétablissent.

6. 9 septembre 2026 à 13:39 UTCresolved

   Tous les composants touchés sont maintenant entièrement récupérés.

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

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.

4. 17 septembre 2026 à 10:09 UTCpostmortem

   Que s'est-il passé ? Le jeudi 20 août 2026 14:58:00 UTC, notre pipeline d'ingestion de métriques a commencé à connaître des échecs d'exportation élevés lors de l'envoi de données à Google Managed Prometheus \(GMP\). La cause sous-jacente a été un incident de service Google Cloud Platform dans la région `us-west1`, qui a perturbé le chemin d'exportation utilisé par notre infrastructure de collecte de métriques. Par conséquent, les files d'attente des exportations métriques ont commencé à s'accumuler dans un sous-ensemble d'environnements de production. Les défaillances se sont manifestées principalement sous la forme d'interruptions de réseau lorsqu'on tentait de fournir des données métriques aux BPF, empêchant ainsi l'ingestion normale des grappes touchées. Notre équipe d'ingénieurs a identifié la concentration géographique des systèmes touchés - couvrant AWS `us-west-2`, Google Cloud `us-west1` et Azure `westus2` - tous les itinéraires passant par l'infrastructure dans la région de l'Oregon. Une fois l'incident régional de GCP atténué par Google, les erreurs d'exportation ont diminué et les files d'attente ont commencé à s'épuiser. # Comment le service a été affecté L'impact a été limité à la visibilité **métrique** pour un sous-ensemble d'environnements Aura. Environ 45 environnements clients ont été touchés, ce qui signifie que les données métriques des bases de données n'ont pas été ingérées dans notre plateforme de surveillance pendant la fenêtre d'incident. La région la plus touchée était l ' AWS 'us-west-2 ', avec un impact supplémentaire dans Google Cloud `us-west1 ' et Azure `westus2 '. Les clients ayant des bases de données dans ces régions ont peut-être connu des lacunes dans leurs tableaux de bord et les données de surveillance pour la durée de l'incident. Les opérations de base de données, y compris la lecture, l'écriture et la disponibilité, ont été **non affectées**; seule la collecte et la visibilité des mesures de performance ont été perturbées. Une fois que Google a atténué le problème régional sous-jacent, l'ingestion métrique a repris et l'arriéré de données en attente a été traité. Ce que nous faisons maintenant Nous avons procédé à un examen approfondi de cet incident et nous prenons les mesures suivantes pour améliorer notre capacité de résilience et d'intervention : * **Tableau de bord amélioré pour l'observation**: Nous améliorons nos tableaux de bord d'exportateurs de métriques afin d'offrir une visibilité plus claire et plus rapide sur les taux d'erreurs en matière de santé et d'exportation, ce qui permettra de détecter et de diagnostiquer plus rapidement des problèmes similaires. * **Améliorer l'agrégation des alertes**: Nous mettons en place un groupe d'alerte automatique afin qu'un incident régional touchant plusieurs grappes soit mieux présenté comme un seul événement corrélé et traité avec la sévérité et l'attention appropriées. * **Alerte proactive sur les taux d'erreurs d'ingestion:** Nous ajoutons des alertes dédiées sur les taux élevés d'erreurs d'ingestion de BPF, donnant à notre équipe un signal plus tôt avant que les files d'attente des exportateurs atteignent la capacité. Ces améliorations visent à réduire le temps de détection, à simplifier le tri des incidents et à renforcer notre pipeline de mesures contre les futures perturbations des fournisseurs en amont.

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)