Historique des pannes de Elastic Cloud

1. 23 octobre 2026 à 04:04 UTCinvestigating

   Nous enquêtons actuellement sur un problème qui empêche l'accès au portail Elastic Support. À l'heure actuelle, les clients peuvent éprouver des problèmes authentifiant le portail de support.

2. 23 octobre 2026 à 04:59 UTCidentified

   Nous avons identifié un problème empêchant l'accès au portail Elastic Support causé par un fournisseur en amont. Le fournisseur a confirmé un correctif qui a rétabli l'accès pour certains de ses environnements touchés et le fait maintenant rouler vers le reste. À l'heure actuelle, les clients peuvent éprouver des problèmes authentifiant le portail de support.

3. 23 octobre 2026 à 06:33 UTCresolved

   Le fournisseur en amont a terminé sa réparation, et l'accès au portail Elastic Support a été restauré. Les clients peuvent à nouveau s'authentifier sur le portail de support. Nous envisageons de résoudre ce problème et nous ne fournirons aucune autre mise à jour. Si vous continuez à avoir des problèmes, veuillez nous contacter.

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

1. 22 octobre 2026 à 11:19 UTCinvestigating

   Nous enquêtons sur un problème affectant AutoOps pour les comptes nouvellement créés dans la région AWS us-east-1. Les comptes créés après 00:00 UTC le 22 octobre 2026 peuvent être incapables d'accéder à AutoOps et peuvent voir une erreur (HTTP 403) lors de son ouverture. Elastic Cloud hébergé: AutoOps n'est pas disponible pour les nouveaux comptes touchés. Elastic Cloud Serverless: AutoOps n'est pas disponible pour les nouveaux comptes touchés. Les déploiements et projets existants, ainsi que toutes les autres fonctionnalités Elastic Cloud, ne sont pas affectés. Nos équipes d'ingénieurs travaillent à identifier la cause et à restaurer l'accès. Nous fournirons la prochaine mise à jour dans les 60 minutes, ou plus tôt s'il y a un changement important

2. 22 octobre 2026 à 12:00 UTCidentified

   Nous avons identifié la cause du problème affectant AutoOps et déployons une correction. Elastic Cloud Hosted et Elastic Cloud Serverless: Les clients qui ont créé un nouveau compte dans la région AWS us-east-1 depuis environ 00:30 UTC le 22 octobre 2026 n'ont pas pu accéder à AutoOps et ont peut-être vu une erreur (HTTP 403) lors de son ouverture. La solution est en cours et nous nous attendons à ce que la situation soit complètement réglée d'ici 13h00 UTC. Les déploiements et projets existants, ainsi que toutes les autres fonctionnalités Elastic Cloud, ne sont pas affectés.

3. 22 octobre 2026 à 20:50 UTCresolved

   Nous avons résolu le problème concernant les AutoOps à 12h30 UTC. Elastic Cloud Hosted et Elastic Cloud Serverless: Les clients qui ont créé un nouveau compte dans la région AWS us-east-1 depuis environ 00:30 UTC le 22 octobre 2026 n'ont pas pu accéder à AutoOps et ont peut-être vu une erreur (HTTP 403) lors de son ouverture.

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

1. 20 octobre 2026 à 20:07 UTCinvestigating

   Nous enquêtons sur un problème affectant la capacité d'écheller les déploiements Elastic Cloud hébergés et les projets sans serveur en Azure. La création d'un nouveau projet et d'un nouveau déploiement à Azure peut être retardée.

2. 20 octobre 2026 à 21:24 UTCidentified

   Nous avons identifié un problème affectant la capacité d'écheller les déploiements Elastic Cloud hébergés et les projets sans serveur en Azure. La création d'un nouveau projet et d'un nouveau déploiement à Azure peut être retardée. Les ingénieurs travaillent activement à atténuer le problème.

3. 20 octobre 2026 à 22:27 UTCmonitoring

   Les ingénieurs ont identifié et atténué un problème affectant la capacité d'écheller les déploiements Elastic Cloud hébergés et les projets sans serveur existants à Azure. Nous surveillons la question pour nous assurer que les opérations se poursuivent normalement.

4. 21 octobre 2026 à 03:05 UTCresolved

   Les ingénieurs ont atténué un problème affectant la capacité d'écheller les déploiements Elastic Cloud hébergés et les projets sans serveur à Azure. L'échelle fonctionne comme prévu.

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

1. 20 octobre 2026 à 06:51 UTCinvestigating

   Nous enquêtons sur une question touchant une zone de disponibilité dans la région du GCP Europe-West2 (Londres). À partir d'environ 06:15 UTC, certains déploiements Elastic Cloud hébergés et sans serveur avec une capacité dans cette zone peuvent subir une dégradation de la disponibilité ou de la connectivité. Le suivi et l'enregistrement des déploiements dans la région peuvent également être retardés. Les déploiements dans d'autres zones et régions ne sont pas affectés. Nos ingénieurs travaillent activement sur la question, et nous sommes en contact avec notre fournisseur de cloud.

2. 20 octobre 2026 à 07:56 UTCidentified

   Notre fournisseur de cloud a confirmé un incident d'infrastructure affectant une seule zone de disponibilité (europe-west2-b) dans la région GCP-europe-west2 (Londres), causant une perte de connectivité réseau et l'indisponibilité des ressources dans cette zone. Elastic Cloud Les déploiements hébergés et les projets Elastic Serverless avec des ressources dans la zone touchée peuvent ne pas être disponibles ou connaître des performances dégradées. Nous avons pris des mesures pour éviter de placer de nouveaux projets sans serveur dans la zone touchée, et nous travaillons à restaurer des services qui en dépendent. La réduction des capacités dans la région pourrait retarder l'élargissement et la création de nouvelles ressources. Nous n'avons pas encore de temps estimé pour la récupération de notre fournisseur de cloud. Nous travaillons en étroite collaboration avec eux et fournirons la prochaine mise à jour dans une heure.

3. 20 octobre 2026 à 09:15 UTCidentified

   L'incident d'infrastructure chez notre fournisseur de cloud affectant la zone de disponibilité europe-west2-b dans la région GCP europe-west2 (Londres) est en cours. Elastic Cloud hébergé : La plupart des déploiements avec des ressources dans la zone affectée restent indisponibles ou dégradés. Nous observons des signes précoces et limités de rétablissement, et un petit nombre des déploiements initialement touchés se rétablissent. Nous poursuivons nos travaux d'atténuation et nous en partagerons davantage à mesure que le rétablissement progressera. Sans serveur élastique : Nous avons pris des mesures pour éviter de placer de nouveaux projets dans la zone touchée, et nous rééquilibrons maintenant les projets existants vers d'autres zones de disponibilité. Nous voyons des signes de reprise - certains projets restent indisponibles ou dégradés entre-temps. La réduction des capacités dans la région pourrait retarder l'élargissement et la création de nouvelles ressources. Nous n'avons pas encore un temps estimé pour la récupération complète de notre fournisseur de cloud. Nous travaillons en étroite collaboration avec eux et fournirons la prochaine mise à jour d'ici 10h15 UTC.

4. 20 octobre 2026 à 10:32 UTCidentified

   L'incident d'infrastructure chez notre fournisseur de cloud affectant la zone de disponibilité europe-west2-b dans la région GCP europe-west2 (Londres) est en cours. Elastic Cloud Les déploiements hébergés et les projets Elastic sans serveur avec des ressources dans la zone touchée peuvent rester indisponibles ou dégradés. Nos équipes continuent de travailler sur l'atténuation et la récupération, et nous travaillons en étroite collaboration avec notre fournisseur de services en nuage. Nous n'avons pas encore le temps prévu pour le rétablissement complet. Nous fournirons la prochaine mise à jour d'ici midi UTC, ou plus tôt s'il y a un changement important.

5. 20 octobre 2026 à 12:24 UTCidentified

   L'incident d'infrastructure chez notre fournisseur de cloud affectant la zone de disponibilité europe-west2-b dans la région GCP europe-west2 (Londres) est en cours. Nous observons de légers signes de récupération, tant de notre fournisseur de cloud que de notre propre travail d'atténuation. Elastic Cloud hébergé: Certains des déploiements affectés sont en cours de récupération. Les clients dont les changements de plan ou d'autres opérations ont échoué pendant l'incident sont invités à les essayer à nouveau à partir de la console Elastic Cloud. Les opérations qui dépendent de la zone touchée peuvent prendre plus de temps que d'habitude, ou échouer à nouveau, jusqu'à ce que le rétablissement progresse. Certains déploiements peuvent rester indisponibles ou dégradés. Sans serveur élastique : Certains projets peuvent rester indisponibles ou dégradés.

6. 20 octobre 2026 à 14:15 UTCidentified

   L'incident d'infrastructure de notre fournisseur de cloud affectant la zone de disponibilité europe-west2-b dans la région de GCP europe-west2 (Londres) se rétablit. Notre fournisseur de cloud signale la récupération des services pour la plupart des charges de travail dans la région, et nous voyons des progrès de notre côté lorsque la zone touchée revient. Elastic Cloud hébergé : Un nombre croissant de déploiements affectés se rétablissent. Les clients dont les changements de plan ou d'autres opérations ont échoué pendant l'incident sont invités à les essayer à nouveau à partir de la console Elastic Cloud. Certains déploiements peuvent encore être indisponibles ou dégradés, et certains peuvent nécessiter des étapes de récupération supplémentaires que notre équipe de soutien travaillera au cas par cas. Si votre déploiement est encore malsain, veuillez contacter Support. Les opérations peuvent prendre plus de temps que d'habitude pendant que la capacité est rétablie.

7. 20 octobre 2026 à 17:27 UTCidentified

   L'incident d'infrastructure chez notre fournisseur de cloud affectant la zone de disponibilité europe-west2-b dans la région GCP europe-west2 (Londres) a été résolu. Nous continuons d'œuvrer à la récupération complète de nos services. Elastic Cloud hébergé : Un nombre croissant de déploiements affectés se rétablissent. Les clients dont les changements de plan ou d'autres opérations ont échoué pendant l'incident sont invités à les essayer à nouveau à partir de la console Elastic Cloud. Certains déploiements peuvent encore être indisponibles ou dégradés, et certains peuvent nécessiter des étapes de récupération supplémentaires que notre équipe de soutien travaillera au cas par cas. Si votre déploiement est encore malsain, veuillez contacter Support. Les opérations peuvent prendre plus de temps que d'habitude pendant que la capacité est rétablie.

8. 20 octobre 2026 à 21:54 UTCresolved

   L'incident d'infrastructure chez notre fournisseur de cloud affectant la zone de disponibilité europe-west2-b dans la région GCP europe-west2 (Londres) a été résolu. L'ingénierie a terminé la récupération de l'infrastructure dans la zone de disponibilité touchée. Elastic Cloud hébergé: Les clients dont le plan a été modifié ou d'autres opérations ont échoué pendant l'incident sont invités à les réessayer à partir de la console Elastic Cloud. Certains déploiements peuvent encore être indisponibles ou dégradés, et peuvent nécessiter des étapes de récupération supplémentaires que notre équipe de soutien travaillera au cas par cas. Si votre déploiement est encore malsain, veuillez contacter Support.

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

1. 8 octobre 2026 à 16:42 UTCinvestigating

   Nous enquêtons sur un problème affectant certains projets Elastic Cloud Serverless dans la région GCP-central1. Les clients peuvent être retardés ou indisponibles.

2. 8 octobre 2026 à 17:21 UTCidentified

   Nous avons identifié un problème de stockage cloud affectant certains projets Elastic Cloud Serverless dans la région GCP-central1. Les clients peuvent subir des opérations de projet retardées ou indisponibles. Le fournisseur enquête sur la question, et nous surveillons la récupération. Nous fournirons une autre mise à jour lorsque plus d'information sera disponible.

3. 8 octobre 2026 à 19:17 UTCidentified

   Certains projets Elastic Cloud Serverless dans la région GCP us-central1 peuvent encore connaître des opérations de projet retardées ou indisponibles. Le fournisseur continue d'enquêter sur la question. Nous surveillons la situation et fournirons une autre mise à jour lorsque de plus amples renseignements seront disponibles.

4. 8 octobre 2026 à 20:47 UTCmonitoring

   Nous avons observé des améliorations après l'application des mesures d'atténuation par notre fournisseur de stockage en amont. Certains projets Elastic Cloud Serverless dans la région GCP us-central1 peuvent encore connaître des opérations de projet retardées ou indisponibles pendant que la récupération se poursuit. Nous surveillons la situation et fournirons une autre mise à jour lorsque de plus amples renseignements seront disponibles.

5. 9 octobre 2026 à 00:54 UTCresolved

   Le problème de stockage en amont de certains projets Elastic Cloud Serverless dans la région GCP-central1 a été résolu. Les opérations du projet sont revenues à la normale, et nous ne voyons plus de projets touchés dans un état de santé rouge.

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

1. 6 octobre 2026 à 14:04 UTCinvestigating

   Les clients ayant des projets sans serveur dans la région Nord d'Azure EAU peuvent voir des retards dans les mesures affichées dans Cloud UI. L'équipe enquête sur le problème et nous publierons une mise à jour dans 2 heures ou plus tôt si nécessaire

2. 6 octobre 2026 à 17:54 UTCresolved

   Le problème touchant la disponibilité métrique des projets sans serveur dans Azure Nord des Émirats arabes unis a été résolu. Retardé l'utilisation et la performance les métriques sont en cours de récupération, et les enregistrements d'utilisation en attente sont en cours de traitement. Aucune perte de données n'est prévue.

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

1. 23 septembre 2026 à 14:04 UTCinvestigating

   Nous sommes actuellement en retard dans la fourniture de nouvelles ressources en nuage en raison de la lenteur avec un fournisseur externe d'image de conteneur. Il peut en résulter des retards lors de la création de nouveaux déploiements, de l ' extension des déploiements existants ou du déplacement de cas touchés par l ' entretien de l ' infrastructure. Comme atténuation, vous pouvez essayer de relancer les changements de plan échoués. Les déploiements en cours ne sont pas touchés. Notre équipe surveille activement la situation et s'emploie à atténuer le problème. Nous fournirons une mise à jour dans les 12 prochaines heures.

2. 23 septembre 2026 à 16:03 UTCresolved

   Cette question a été résolue.

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

1. 17 septembre 2026 à 15:50 UTCinvestigating

   Nous enquêtons sur les rapports de métriques manquantes au niveau des nœuds (CPU, mémoire, disque, pools de thread) pour des intervalles de temps récents dans un sous-ensemble de régions AutoOps. Cela peut apparaître comme un message "Pas de données" sur la vue des nœuds. Les données sur la santé des grappes, la shard et le déploiement ne sont pas affectées, et aucune perte de données n'a eu lieu. Nous fournirons une mise à jour dans les 2 prochaines heures ou plus tôt.

2. 17 septembre 2026 à 16:13 UTCidentified

   Nous avons identifié la cause des métriques manquantes (CPU, mémoire, disque, pools de fils) dans les régions touchées. Les données sur la santé des grappes, la shard et le déploiement n'ont jamais été affectées, et aucune perte de données n'a eu lieu. Un correctif a été validé dans une région et est actuellement déployé dans les autres régions touchées. Nous fournirons une nouvelle mise à jour une fois le déploiement terminé.

3. 17 septembre 2026 à 16:31 UTCresolved

   Le problème des métriques manquantes (CPU, mémoire, disque, pools de threads) pour les intervalles de temps récents dans un sous-ensemble de régions AutoOps a été entièrement résolu. Les données sur la santé des grappes, la shard et le déploiement n'ont pas été affectées et aucune donnée n'a été perdue.

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

1. 16 septembre 2026 à 13:17 UTCinvestigating

   Nous sommes actuellement conscients que certains clients pourraient ne pas être en mesure d'accéder au portail de support élastique pour le moment. Nous travaillons avec notre fournisseur pour enquêter. Si vous avez besoin de contacter le support dans l'intervalle, veuillez contacter [email protected].

2. 16 septembre 2026 à 14:49 UTCmonitoring

   Nous voyons des signes de récupération sur le portail de support élastique, et les clients devraient maintenant pouvoir accéder comme d'habitude. Nous continuerons de surveiller pendant 30 minutes avant de marquer cet incident tel qu'il a été résolu.

3. 16 septembre 2026 à 15:38 UTCresolved

   Le Portail d'assistance élastique reste disponible et stable - nous considérons actuellement que cet incident est résolu.

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

1. 12 septembre 2026 à 23:21 UTCinvestigating

   Nous enquêtons sur les retards des mesures dans la console.

2. 13 septembre 2026 à 00:18 UTCidentified

   Nous avons identifié et corrigé la cause du retard des mesures. La file d'attente est en cours de traitement et les mesures différées seront visibles une fois terminées.

3. 13 septembre 2026 à 02:55 UTCmonitoring

   Les files d'attente sont en cours de traitement et les données retardées commencent à apparaître. Nous surveillerons pour être sûrs que tout rattrape comme prévu.

4. 13 septembre 2026 à 07:45 UTCresolved

   Le retard de l'ingestion des paramètres dans le GCP-East4 a été complètement résolu. Toutes les données en attente ont été traitées et les métriques sont maintenant affichées dans la console en temps réel.

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

1. 10 septembre 2026 à 01:30 UTCidentified

   Nous avons identifié et sommes en train de fixer+imiter un bug dans notre interface de gestion des permissions qui empêche les utilisateurs avec le rôle de propriétaire de l'organisation et Cloud Console, Elasticsearch et Kibana d'accéder à Kibana dans les déploiements hébergés.

2. 10 septembre 2026 à 06:03 UTCidentified

   Mettre à jour : Cet incident est toujours en cours et nous continuons d'enquêter.

3. 10 septembre 2026 à 09:51 UTCmonitoring

   Mise à jour : La correction a été déployée à la production et nous avons appliqué une correction de données aux comptes affectés, rétablissant l'accès à Kibana pour les utilisateurs touchés. Nous veillons à confirmer la résolution complète.

4. 10 septembre 2026 à 22:31 UTCresolved

   Cet incident a été résolu.

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

1. 9 septembre 2026 à 20:44 UTCidentified

   Nous avons identifié un bug dans Fleet Server 9.5.3 (également présent en 9.4.6) qui peut faire planter des agents élastiques et se déconnecter lorsque Fleet pousse une mise à jour de configuration, y compris l'inscription, un changement de politique, ou une bosse de révision de routine. Cela n'affecte que les politiques qui utilisent la fonction de sortie Elasticsearch distante de Fleet. Recommandation: Si vous utilisez la sortie Elasticsearch distante de Fleet, ne mettez pas à niveau à 9.5.3 ou 9.4.6 jusqu'à ce qu'une version fixe soit disponible. Si vous êtes déjà sur une version affectée et que vous rencontrez des défaillances d'enregistrement de l'agent, contactez le support pour les étapes d'assainissement. Une correction a été fusionnée et sera envoyée dans les prochaines versions 9.5.x et 9.4.x. Documentation connue sur les problèmes : serveur de flotte no 7791, agent élastique no 16542.

2. 11 septembre 2026 à 14:25 UTCidentified

   Nous avons patché les versions 9.5.3 et 9.4.6 de Fleet Server avec des versions corrigées déployées au 10 septembre 2026 à 21h20 UTC. - La mise à niveau des versions actuelles 9.4.6 ou 9.5.3 ne sera pas affectée par ce bogue puisque la version mise à jour contient la correction. - Si vous avez atteint 9.4.6 ou 9.5.3 avant 21:20 UTC le 10 septembre 2026, effectuez les mesures d'atténuation suivantes : 1. Force redémarrer la composante Serveur d'intégration de votre déploiement affecté 2. Exécuter des procédures de nettoyage sur les agents élastiques affectés (voir https://support.elastic.co/knowledge/bee1c75c) — requis si les agents n'ont pas vérifié ou sont restés hors ligne après le redémarrage du serveur d'intégration

3. 11 septembre 2026 à 16:00 UTCidentified

   Nous avons patché les versions 9.5.3 et 9.4.6 de Fleet Server avec des versions corrigées déployées au 10 septembre 2026 à 21h20 UTC. - La mise à niveau des versions actuelles 9.4.6 ou 9.5.3 ne sera pas affectée par ce bogue puisque la version mise à jour contient la correction. - Si vous avez atteint 9.4.6 ou 9.5.3 avant 21:20 UTC le 10 septembre 2026, effectuez les mesures d'atténuation suivantes : 1. Force redémarrer la composante Serveur d'intégration de votre déploiement affecté 2. Exécuter des procédures de nettoyage sur les agents élastiques affectés (voir https://support.elastic.co/knowledge/bee1c75c) — requis si les agents n'ont pas vérifié ou sont restés hors ligne après le redémarrage du serveur d'intégration IMPORTANT: Le Fleet Server patché n'est pas disponible en dehors de Elastic Cloud Enterprise (ECE) Stack Packs et Elastic Cloud Hosted (ECH).

4. 17 septembre 2026 à 10:30 UTCresolved

   Nous avons confirmé que les agents élastiques ne connaissent plus de défaillances d'inscription liées à cette question. Les versions corrigées de Fleet Server (9.5.4 / 9.4.6) sont disponibles depuis le 10 septembre 2026 sur les paquets Elastic Cloud Hosted et Elastic Cloud Enterprise, et tous les déploiements connus ont confirmé la récupération. Si vous êtes passé à un rejet touché avant cette date et que vous n'avez pas encore appliqué les mesures d'atténuation, veuillez consulter les lignes directrices à l'adresse suivante : https://support.elastic.co/knowledge/bee1c75c.

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

1. 2 septembre 2026 à 00:04 UTCresolved

   De 21:50 à 23:42 UTC, nous avons rencontré des taux d'erreur élevés pour l'anthropique Claude Haiku 4.5, OpenAI GPT-5.6 et Google Gemini 2.5 Flash avec le service d'inférence élastique dans les régions de l'UE. Cette question a été réglée.

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

1. 1 septembre 2026 à 15:18 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant les services fonctionnant dans GCP-central1. Nous fournirons des mises à jour supplémentaires à mesure que nous en apprendrons davantage sur la portée de l'impact.

2. 1 septembre 2026 à 15:51 UTCidentified

   Un problème permanent concerne les services fonctionnant dans GCP-central1. Cela inclut, mais ne se limite pas aux projets Elastic Cloud hébergés et sans serveur dans la région et notre service d'enregistrement Docker. Nous continuons de surveiller la situation et fournirons des mises à jour lorsqu'elles seront disponibles.

3. 1 septembre 2026 à 16:15 UTCidentified

   Un problème continu en amont du PSC est l'impact des services fonctionnant dans GCP-central1. Cela inclut, mais ne se limite pas aux projets Elastic Cloud hébergés et sans serveur dans la région et notre service d'enregistrement Docker. Nous continuons de surveiller la situation et fournirons des mises à jour lorsqu'elles seront disponibles.

4. 1 septembre 2026 à 16:22 UTCmonitoring

   Nous voyons des signes de récupération pour les services dans GCP nous-central1 touchés par un problème CSP en amont. Nous continuons de surveiller la situation et fournirons des mises à jour à mesure qu'elles seront disponibles.

5. 1 septembre 2026 à 20:05 UTCresolved

   Cette question a été résolue.

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

1. 1 septembre 2026 à 08:16 UTCinvestigating

   Nous sommes conscients d'un bug affectant les clients sur Elasticsearch versions 9.5.0, 9.5.1 et 9.5.2 où les opérations d'index en vrac traitées sur le shard primaire peuvent entraîner une divergence sur les répliques résultant en une utilisation de disque élevée et des récupérations à long terme. L'équipe travaille sur une solution. Pour de plus amples renseignements, consulter le site https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.5.2-known-issues La prochaine mise à jour sera dans les 2 prochaines heures ou plus tôt si nécessaire.

2. 1 septembre 2026 à 11:07 UTCidentified

   Nous avons identifié la cause profonde et l'équipe travaille sur un correctif prévu pour être publié dans la version 9.5.3 d'Elasticsearch Ce que vous pouvez faire: - Si vous n'avez pas encore passé à 9.5.*, vous n'êtes pas affecté car les mises à jour à 9.5 ont été désactivées jusqu'à ce que 9.5.3 soit libéré - Si vous utilisez déjà 9.5 et ressentez les symptômes de ce problème, veuillez contacter Elastic Support. Pour de plus amples renseignements, consulter le site https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.5.2-known-issues

3. 1 septembre 2026 à 15:46 UTCidentified

   La correction a été identifiée et renvoyée à la branche du patch Elasticsearch 9.5. Les équipes effectuent les validations nécessaires avant de programmer et de lancer la version 9.5.3.

4. 3 septembre 2026 à 12:13 UTCmonitoring

   Elasticsearch 9.5.3 a été publié et tous les clients en cours d'exécution 9.5.0, 9.5.1 ou 9.5.2 sont invités à mettre à jour cette nouvelle version dès que possible.

5. 3 septembre 2026 à 15:47 UTCmonitoring

   Elasticsearch 9.5.3 a été publié et tous les clients en cours d'exécution 9.5.0, 9.5.1 ou 9.5.2 sont invités à mettre à jour cette nouvelle version dès que possible. Il est conseillé aux clients touchés de suivre les étapes de contournement de https://github.com/elastic/elasticsearch/issues/158212 après la mise à niveau.

6. 30 septembre 2026 à 20:44 UTCresolved

   Ce problème a été résolu dans la version 9.5.3 d'Elasticsearch. Les clients exécutant les versions 9.5.0, 9.5.1 ou 9.5.2 d'Elasticsearch sont invités à mettre à jour une version plus récente dès que possible.

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

1. 27 août 2026 à 17:11 UTCmonitoring

   Le 26 août, vers 00h00 UTC, nous avons déployé un changement dans Managed Inputs qui a affecté certaines règles dans notre fournisseur DNS interne, en supprimant les paramètres .amm certains de nos clients sans serveur. Le service a été restauré vers 9h00 UTC le même jour. Pendant ce temps, certains clients auraient connu l'indisponibilité du paramètre .apm, pendant une période dans la fenêtre de 9 heures. Nous mettons en place des contrôles et des alertes pour éviter que cela ne se reproduise.

2. 27 août 2026 à 18:33 UTCresolved

   Ceci est maintenant résolu

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

1. 20 août 2026 à 20:22 UTCinvestigating

   Nous enquêtons actuellement sur les taux d'erreur élevés affectant l'OTLP géré sur Elastic Cloud Serverless. Notre équipe enquête activement sur la cause profonde. Nous fournirons une mise à jour dans les 30 minutes.

2. 20 août 2026 à 20:53 UTCinvestigating

   Nous continuons d'étudier les taux d'erreur élevés affectant l'OTLP géré sur Elastic Cloud Serverless. Nous fournirons une mise à jour dans 1 heure.

3. 20 août 2026 à 21:59 UTCidentified

   Nous avons identifié la cause profonde des taux d'erreur élevés affectant OTLP géré sans serveur. Une mesure d'atténuation a été appliquée et nous surveillons le retour des taux d'erreur au niveau de référence. Selon notre enquête, la charge de travail des clients n'a pas été affectée.

4. 20 août 2026 à 22:13 UTCresolved

   Cet incident a été résolu. La cause profonde a été identifiée et traitée. La charge de travail des clients n'a pas été touchée durant cet incident.

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

1. 20 août 2026 à 12:48 UTCinvestigating

   Un problème affectant la création de nouveaux projets sans serveur dans la région est d'Azure a été identifié. Notre équipe enquête activement pour déterminer la cause profonde. Nous fournirons une mise à jour de l'état de suivi dans la prochaine heure ou dès que la cause racine est établie, selon la première éventualité.

2. 20 août 2026 à 14:05 UTCmonitoring

   Nous avons déterminé que le problème provient d'un problème en amont avec la composante de stockage d'Azure. À l'examen, l'impact se limite strictement aux nouveaux temps d'initialisation du projet, ce qui entraîne des délais de création plus longs pour les projets sans serveur dans la région d'Azure estus. Nous fournirons une nouvelle mise à jour une fois la question réglée.

3. 20 août 2026 à 16:22 UTCresolved

   Les problèmes de la composante stockage d'Azure dans la région de l'Est ont été résolus. Par conséquent, les temps de création de projet sans serveur sont revenus à la normale et fonctionnent comme prévu.

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

1. 14 août 2026 à 09:22 UTCidentified

   Elasticsearch 9.5.1 contient un problème connu où les requêtes booléennes contenant une clause must, filter, ou devrait utiliser une requête de termes multi-valeurs, ainsi qu'une clause must not sur les champs avec indexation désactivée, peuvent toujours retourner des correspondances faussement positives. Alors que le patch du 9.5.1 (https://github.com/elastic/elasticsearch/pull/155936) a résolu le défaut de la corbeille pour les chemins de requêtes de terme et de portée; les requêtes de termes à valeur multiple utilisent un type de requête Lucene différent qui n'était pas couvert par cette correction. Les flux de données des séries chronologiques (TSDB) et les indices et flux de données des colonnes restent affectés pour ce modèle de requête, l'indexation étant désactivée par défaut sur ces champs. Les requêtes relatives aux termes touchés peuvent renvoyer des correspondances faussement positives (y compris des documents qui auraient dû être exclus) et signaler des nombres de documents plus élevés que prévu. Aucune erreur n'est soulevée, de sorte que les requêtes sembleront compléter avec succès. Ce que vous pouvez faire: - Si vous n'avez pas encore mis à jour à 9.5.*, nous vous recommandons de reporter la mise à jour jusqu'à ce que la version 9.5.2 soit disponible. - Si vous utilisez déjà 9.5.*, contactez le support élastique si vous avez besoin d'aide pour déterminer si vos recherches sont affectées. Nous avons identifié la cause profonde, une correction est en cours, et nous préparons une libération de patch. Nous fournirons une mise à jour supplémentaire lorsque la correction est prête.

2. 20 août 2026 à 17:09 UTCresolved

   Elasticsearch 9.5.2 a été publié et contient la correction pour ce problème. Les clients utilisant 9.5.0 ou 9.5.1 devraient passer à 9.5.2. À l'heure actuelle, nous envisageons de résoudre cette question et nous ne fournirons aucune autre mise à jour.

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

1. 13 août 2026 à 08:32 UTCinvestigating

   Nous voyons des taux d'erreur élevés du fournisseur en amont pour le modèle d'intégration microsoft-multilingual-e5-large. Les requêtes d'intégration de recherche à ce modèle peuvent échouer. Nous enquêtons

2. 13 août 2026 à 14:45 UTCinvestigating

   Nous constatons une certaine amélioration de la disponibilité, mais nous continuons de surveiller la situation. Nous ferons le suivi avec plus d'informations en temps utile.

3. 13 août 2026 à 18:26 UTCmonitoring

   Malheureusement, nous ne pouvons plus soutenir le modèle E5 Multilingual Large sur le service d'inférence élastique en raison des problèmes continus des fournisseurs en amont. Tout client ayant besoin de ce modèle doit configurer des paramètres d'inférence personnalisés en utilisant ses propres clés API.

4. 17 août 2026 à 11:40 UTCresolved

   Le modèle microsoft-multilingue-e5-large a été retiré du service d'inférence élastique. Les demandes de ce modèle renvoient maintenant une erreur. Les clients qui souhaitent utiliser ce modèle avec le cloud élastique doivent créer un paramètre d'inférence personnalisé en utilisant leur propre clé API. Pour plus de détails, voir la documentation de l'inférence: https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-inference

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