Historique des pannes de Statuscast

1. 29 octobre 2025 à 16:04 UTCupdate

   Entre 15h45 UTC le 29 octobre et 00h05 UTC le 30 octobre 2025, les clients et les services Microsoft exploitant Azure Front Door (AFD) ont connu des latences, des délais et des erreurs. Les services de livraison AFD & CDN restent stables et fonctionnent comme prévu. Par prudence, toutes les opérations de gestion de service (y compris la création, les mises à jour, les suppressions et les purges) à l'AFD via le portail ou les API continuent de rester temporairement suspendues. Nous travaillons à l'élaboration d'un plan global visant à les réactiver progressivement dans une approche progressive, tout en assurant la stabilité de la plateforme. Nous continuerons de partager des mises à jour périodiques à mesure que nous progresserons. Prochaine mise à jour sera d'ici 01:00 UTC le 31 Oct 2025 ou plus tôt.

2. 31 octobre 2025 à 01:08 UTCupdate

   Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été entièrement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Nous aviserons les clients une fois la restriction levée, et nous enverrons une communication périodique sur les progrès réalisés. Prochaine mise à jour sera d'ici 19:00 UTC le 31 Oct 2025 ou plus tôt que l'événement le justifie.

3. 31 octobre 2025 à 20:03 UTCupdate

   Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Nous travaillons à fournir une ETA sur quand nous pouvons lever la restriction et nous continuerons à envoyer des communications périodiques sur les progrès via Azure Service Health. La prochaine mise à jour sera d'ici 19h00 UTC le 1er novembre 2025 ou plus tôt si les événements le justifient.

4. 31 octobre 2025 à 21:35 UTCupdate

   Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Notre attente actuelle est de lever la restriction le 5 novembre 2025, et nous continuerons d'envoyer des communications périodiques sur les progrès réalisés via Azure Service Health. La prochaine mise à jour sera d'ici 19h00 UTC le 1er novembre 2025 ou plus tôt si les événements le justifient.

5. 1 novembre 2025 à 19:41 UTCupdate

   Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Nous nous attendons à ce que la restriction soit levée le 5 novembre 2025 et nous continuerons d'envoyer des communications périodiques sur les progrès réalisés via Azure Service Health. La prochaine mise à jour sera d'ici 19h00 UTC le 2 novembre 2025 ou plus tôt si les événements le justifient.

6. 2 novembre 2025 à 20:31 UTCupdate

   Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Nous nous attendons à ce que la restriction soit levée le 5 novembre 2025 et nous continuerons d'envoyer des communications périodiques sur les progrès réalisés via Azure Service Health. La prochaine mise à jour sera d'ici 03:00 UTC le 3 novembre 2025 ou plus tôt si les événements le justifient.

7. 2 novembre 2025 à 21:07 UTCupdate

   Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Nous nous attendons à ce que la restriction soit levée le 5 novembre 2025 et nous continuerons d'envoyer des communications périodiques sur les progrès réalisés via Azure Service Health. La prochaine mise à jour sera d'ici 03:00 UTC le 3 novembre 2025 ou plus tôt si les événements le justifient.

8. 3 novembre 2025 à 03:02 UTCupdate

   Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Nous nous attendons à ce que la restriction soit levée le 5 novembre 2025 et nous continuerons d'envoyer des communications périodiques sur les progrès réalisés via Azure Service Health. La prochaine mise à jour sera d'ici 19h00 UTC le 3 novembre 2025 ou plus tôt si les événements le justifient.

9. 4 novembre 2025 à 00:14 UTCupdate

   Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Dans le cadre de notre enquête complète et des vérifications sécuritaires, l'exécution des opérations de gestion du service (créer, mettre à jour, supprimer, purger, etc.) a été temporairement rendue indisponible. Les restrictions sur les opérations de gestion du service ont été supprimées pour cet ID d'abonnement Azure. Veuillez laisser environ 30 à 40 minutes pour que les changements se propagent complètement aux sites de bordure. Nous nous attendons à ce que toutes les restrictions concernant les abonnements, y compris les autres abonnements sous votre locataire, soient levées d'ici le 5 novembre 2025. Les progrès se poursuivront grâce à Azure Service Health. La prochaine mise à jour sera fournie avant 22h00 UTC le 4 novembre 2025, ou plus tôt si les circonstances changent.

10. 4 novembre 2025 à 00:25 UTCupdate

    Nous reconnaissons que la communication précédente peut avoir contenu des informations destinées à une autre liste de clients. Nous nous excusons pour le désagrément et vous demandons de noter ce qui suit. Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Le workflow de gestion et de rotation des certificats Bring Your Own Certificate (BYOC) a été réactivé. Nous surveillerons l'avancement des travaux dans la file d'attente des rotations nécessaires. Nous continuerons de fournir régulièrement des mises à jour sur les progrès réalisés. Notre attente actuelle demeure de lever la restriction le 5 novembre 2025. La prochaine mise à jour sera d'ici 22h00 UTC le 4 novembre 2025 ou plus tôt si les événements le justifient.

11. 4 novembre 2025 à 03:27 UTCupdate

    En vue de lever les restrictions de gestion du service, une communication incorrecte a été envoyée indiquant un retrait anticipé. Notre date actuelle pour lever toutes les restrictions d'avion de contrôle reste le 05 novembre 2025. La prochaine mise à jour sera fournie avant 22h00 UTC le 4 novembre 2025, ou plus tôt.

12. 4 novembre 2025 à 22:22 UTCupdate

    Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués à 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Au fur et à mesure que nous complétons notre enquête et mettons en œuvre d'autres vérifications sécuritaires, les opérations de gestion des services (créer, mettre à jour, supprimer, purger, etc.) sont temporairement indisponibles. Nous continuons de franchir des jalons dans l'attente de lever cette restriction le 5 novembre 2025. La prochaine mise à jour sera envoyée pour confirmer une fois que cela s'est produit, ou plus tôt si les événements le justifient.

13. 5 novembre 2025 à 23:36 UTCupdate

    Dernière mise à jour : À 23h00 UTC, le 5 novembre 2025, les restrictions sur les opérations de gestion des services Azure Front Door (AFD) et Content Delivery Network (CDN) ont été supprimées. Vous pouvez maintenant reprendre les opérations normales sur l'avion de gestion de service AFD. Pour une meilleure sécurité et protection, nous avons prolongé les temps de propagation de la configuration jusqu'à 45 minutes. D'autres améliorations de la plate-forme qui sont en cours devraient optimiser les temps de propagation. Contexte précédent: Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués par 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Nous vous avons déjà informé que, dans le cadre de notre enquête complète et des vérifications sécuritaires, l'exécution des opérations de gestion du service (créer, mettre à jour, supprimer, purger, etc.) étaient temporairement limitées. Cette notification vise à confirmer que ces restrictions temporaires ne s'appliquent plus. Prochaines étapes : Comme nous l'avons mentionné dans notre RIP préliminaire, nous complétons une rétrospective interne pour comprendre l'incident plus en détail. Une fois que cela sera terminé, ce qui est attendu dans environ 7 jours, nous publierons notre examen final de l'incident - y compris un lien pour s'inscrire à un flux de live rétrospectif de l'incident Azure, en discutant de l'incident et de nos leçons. Azure Front Door Questions fréquemment posées (FAQ)

14. 5 novembre 2025 à 23:42 UTCresolved

    Dernière mise à jour : À 23h00 UTC, le 5 novembre 2025, les restrictions sur les opérations de gestion des services Azure Front Door (AFD) et Content Delivery Network (CDN) ont été supprimées. Vous pouvez maintenant reprendre les opérations normales sur l'avion de gestion de service AFD. Pour une meilleure sécurité et protection, nous avons prolongé les temps de propagation de la configuration jusqu'à 45 minutes. D'autres améliorations de la plate-forme qui sont en cours devraient optimiser les temps de propagation. Contexte précédent: Les avions de données Azure Front Door (AFD) et Content Delivery Network (CDN) ont été complètement atténués par 00:05 UTC le 30 octobre 2025 et restent à des niveaux d'exploitation normaux. Nous vous avons déjà informé que, dans le cadre de notre enquête complète et des vérifications sécuritaires, l'exécution des opérations de gestion du service (créer, mettre à jour, supprimer, purger, etc.) étaient temporairement limitées. Cette notification vise à confirmer que ces restrictions temporaires ne s'appliquent plus. Prochaines étapes : Comme nous l'avons mentionné dans notre RIP préliminaire, nous complétons une rétrospective interne pour comprendre l'incident plus en détail. Une fois que cela sera terminé, ce qui est attendu dans environ 7 jours, nous publierons notre examen final de l'incident - y compris un lien pour s'inscrire à un flux de live rétrospectif de l'incident Azure, en discutant de l'incident et de nos leçons. Azure Front Door Questions fréquemment posées (FAQ)

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

1. 29 octobre 2025 à 16:01 UTCupdate

   Nous comprenons qu'il y a une panne mondiale pour MS Azure. Notre équipe est au courant du problème. Les pages d'état et le portail d'administration peuvent ne pas être accessibles. Nous nous excusons pour tout désagrément.

2. 29 octobre 2025 à 18:17 UTCupdate

   La panne Microsoft Azure affecte toujours les noms de domaine, mais pas le domaine status.page. Vous pouvez utiliser https:// yourpagename .status.page pour accéder à votre page et au portail d'administration. Nous nous excusons pour tout désagrément.

3. 30 octobre 2025 à 05:40 UTCresolved

   Les services sont maintenant opérationnels. Cet événement a été résolu.

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

1. 4 avril 2025 à 13:37 UTCupdate

   Les ingénieurs ont été alertés des retards dans le traitement des notifications. Nous enquêtons actuellement sur cette question et nous en assurerons le suivi avec plus de détails.

2. 4 avril 2025 à 18:30 UTCresolved

   À 9 h 37 HAE, un incident a retardé le traitement des notifications d'incident. L'incident a été entièrement résolu par 14 h 30 HAE. Plus de détails sur la cause racine suivront. Les abonnés verraient toujours les pages d'état comme prévu, mais la notification de l'incident aurait été retardée.

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

1. 27 février 2025 à 14:53 UTCupdate

   Xurrent acquiert Zendust SANTA BARBARA, Californie, 27 février 2025 – XurrentTM, la plateforme de gestion de services et d'opérations conçue pour les entreprises modernes et les fournisseurs de services gérés, a acquis Zenduty, un leader dans les solutions de gestion des incidents et des alertes de pointe. Cette acquisition marque une autre étape importante dans le cheminement continu de Xurrent pour transformer les TI et redéfinir la façon dont les organisations traitent les incidents majeurs du début à la fin. Phil Christianson, chef des produits Xurrent, a fait remarquer, Xurrent est heureux d'annoncer une avancée majeure dans nos capacités ITOM. Notre acquisition de StatusCast en avril dernier a amélioré notre plateforme pour améliorer considérablement les capacités des organisations de communiquer les détails des incidents majeurs. Maintenant, avec l'acquisition de Zendust, nous allons permettre aux TI d'automatiser et de rationaliser la résolution des incidents et la réparation des causes profondes, en assurant des correctifs plus rapides et en prévenant les incidents répétés. Zendety est un innovateur dans la gestion des incidents et des alertes. La plate-forme a acquis une réputation pour permettre aux commandants d'incidents de rassembler rapidement les bonnes équipes dans une salle de guerre virtuelle, de trier les problèmes et de conduire la résolution rapidement. Grâce à l'intégration de Zendust avec les fonctionnalités robustes de gestion des services informatiques (ITSM) de Xurrent, les clients bénéficieront d'opérations informatiques de bout en bout et de capacités de gestion des services au sein d'une plate-forme unique et unifiée. Cette intégration garantit que lorsqu'un incident majeur survient, les organisations peuvent non seulement gérer et résoudre le problème rapidement, mais aussi mettre en œuvre une approche structurée pour l'empêcher de se reproduire. Zendety habilite les commandants d'incidents à coordonner efficacement les équipes d'intervention, tandis que Xurrent est la plate-forme ITSM qui veille à ce que les tâches soient assignées aux bonnes équipes, suivies et achevées à temps, ce qui entraîne une amélioration continue entre les incidents. En intégrant Zendust à la plate-forme Xurrent, les organisations bénéficient des avantages clés suivants : • Automatiser les salles de guerre virtuelles pour une intervention rapide. • Gérer et résoudre rapidement les incidents. • Faire en sorte que les tâches de remise en état après les incidents soient exécutées de façon responsable. La combinaison d'outils de gestion d'incidents et d'alertes de haute qualité Zenduty avec la puissance de XurrentS de classe mondiale IT Service Management, permettra à nos clients de prendre pleinement le contrôle de leurs opérations informatiques et de la gestion de service avec une approche plus moderne, connectée et automatisée, a déclaré Kevin McGibben, Xurrent PDG. Avec Xurrent, les équipes prennent des mesures plus tôt, résolvent les incidents plus rapidement et s'assurent qu'ils ne se reproduisent plus jamais – accomplissant des tâches critiques avec efficacité, précision et pleine responsabilité. À propos de Xurrent XurrentTM rationalise l'ITSM et la gestion des opérations informatiques avec l'automatisation assistée par l'IA. Notre plateforme simplifie les workflows, améliore la collaboration et stimule la productivité. Conçu pour l'évolutivité, Xurrent s'adapte parfaitement aux besoins changeants des entreprises modernes, minimisant les efforts tout en maximisant l'efficacité. En savoir plus sur www.xurrent.com . À propos de Zendust Zendust est une solution de gestion des incidents et des appels de bout en bout qui fournit des alertes cross-canal par e-mail, téléphone, SMS, Slack et Microsoft Teams pour s'assurer que votre équipe est rapidement informée pendant les temps d'arrêt du service. Conçu pour améliorer l'efficacité de la réponse aux incidents, Zendust offre des fonctionnalités telles que l'alerte personnalisable, la programmation sur appel et des intégrations sans faille avec plus de 150 outils, dont Datadog, Jira et Slack. Les organisations utilisant Zenduty ont signalé des améliorations importantes, notamment une réduction des temps d'arrêt, une amélioration de 50 % du temps moyen de reconnaissance (MTTA) et du temps moyen de résolution (MTTR) et des économies de coûts. Pour en savoir plus, visitez www.zendust.com . Communiqué de presse: https://www.xurrent.com/press-release/xurrent-aquires-zenty-completing-the-incident-response-and-remediation-loop/

2. 27 février 2025 à 14:54 UTCresolved

   auto-fermé

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

1. 23 février 2025 à 14:00 UTCupdate

   Les ingénieurs StatusCast ont noté une certaine dégradation du traitement qui peut avoir causé des retards dans certaines actions.

2. 24 février 2025 à 02:00 UTCresolved

   L'équipe a identifié le problème.

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

1. 4 février 2025 à 22:30 UTCupdate

   StatusCast engineers noted a background processing degradation that caused delays in some actions from being completed in a timely fashion.

2. 5 février 2025 à 02:00 UTCresolved

   This has been resolved. We apologize for any inconvenience.

1. 29 décembre 2024 à 23:00 UTCupdate

   Le domaine pour accéder au portail de support de StatusCast a été mis à jour à https://xurrent-statuscast-portal.xurrent.com/ . Alors que l'ancien domaine redirigera vers notre actuel, nous vous recommandons de mettre à jour vos signets de manière appropriée.

2. 29 décembre 2024 à 23:01 UTCresolved

   auto-fermé

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

1. 25 novembre 2024 à 19:24 UTCupdate

   Les ingénieurs de StatusCast ont identifié une sauvegarde dans le traitement de ses antécédents qui cause des retards dans certaines actions d'être terminées en temps opportun.

2. 25 novembre 2024 à 20:32 UTCupdate

   Les ingénieurs ont déterminé la cause profonde de la sauvegarde dans le traitement. Pendant ce temps, nous avons réduit le service qui est responsable pour aider à effacer les éléments restants plus rapidement.

3. 25 novembre 2024 à 22:06 UTCresolved

   Les services devraient fonctionner comme prévu.

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

1. 16 novembre 2024 à 01:00 UTCupdate

   Les ingénieurs StatusCast ont été alertés d'un éventuel événement impactant les performances affectant les pages d'état et les temps de réponse de l'application admin. Cet événement n'a pas d'incidence sur le traitement des notifications. Nous nous excusons pour ce désagrément et fournirons une mise à jour sous peu.

2. 18 novembre 2024 à 19:00 UTCresolved

   Tous les services devraient être pleinement fonctionnels et fonctionner régulièrement.

3. 27 novembre 2024 à 20:00 UTCupdate

   Les ingénieurs de StatusCast ont déterminé qu'à environ 20h00 HNE le 15 novembre 2024, plusieurs serveurs d'applications de StatusCast ont éprouvé un problème qui a causé le temps de réponse à pic. L'infrastructure de StatusCast à Azure est conçue pour effectuer des procédures d'échelle pour les services sous contrainte, et pour tous les services d'application en question sauf un, cela a été fait avec succès pour rétablir le service à un niveau acceptable de performance. Le service d'application restant dans l'UE n'a pas été correctement évalué et est resté dans un état dégradé pendant plusieurs jours. Le 18 novembre, les ingénieurs ont été avertis que certains clients subissaient encore des retards dans le temps de chargement et à ce moment le dernier serveur a été corrigé. Après cet événement, l'équipe DevOps de StatusCast a entrepris une vérification de toutes les procédures de mise à l'échelle afin de s'assurer que les services d'application dans nos régions opérationnelles d'Azure respectent un processus de mise à l'échelle cohérent et de s'assurer que la surveillance est correctement déployée dans tous les services, car un seul service d'application reste dans un état dégradé pendant des jours.

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

1. 5 septembre 2024 à 13:00 UTCupdate

   Notre équipe est heureuse d'annoncer la rebrand officielle de 4me au nom Xurrent . Notre look rafraîchi et notre identité mise à jour reflètent l'essence de notre activité, notre plateforme, notre vision et sa valeur. Notre nouveau look est déployé dans un nouveau site Web, des matériaux de marketing, et l'application Xurrent! Dates importantes : • 5 septembre (aujourd'hui!) • Un communiqué de presse a annoncé le lancement de la nouvelle marque. • Notre nouveau site est en direct! Consultez le site www.xurrent.com . • 7 septembre • Toutes les communications de Xurrent émaneront de notre nouveau domaine, www.xurrent.com . Cela signifie les courriels et toute autre communication officielle. Qu'est - ce que cela signifie pour vous? À partir de maintenant, vous verrez notre nouvelle marque dans les courriels, sur le site Web, et dans d'autres communications. Soyez assuré que ce changement n'affectera pas vos services actuels. Merci d'avoir fait partie de la famille Xurrent (anciennement 4me). Alors que notre apparence évolue, notre engagement à fournir des produits de haute qualité et un support client exceptionnel demeure inchangé. Notre mission et nos valeurs continuent de nous conduire vers un avenir dynamique et collaboratif.

2. 5 septembre 2024 à 13:01 UTCresolved

   auto-fermé

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

1. 1 août 2024 à 17:45 UTCupdate

   As of August 1st, 2024 we have removed the link to the Legacy Incident Editor from the admin portal to ensure that users maintain a unified experience and are able to take advantage of all of our latest improvements to the incident creation process.

2. 1 août 2024 à 17:46 UTCresolved

   auto-closed

1. 30 juillet 2024 à 13:30 UTCupdate

   Les ingénieurs StatusCast ont été avertis plus tôt que certains utilisateurs éprouvaient des problèmes sporadiques en essayant de se connecter à la page d'état et au portail d'administration. Notre fournisseur d'hébergement, Microsoft Azure, nous a alerté via leur page de statut qu'ils connaissent certains problèmes de réseau à l'échelle mondiale. Nous fournirons une mise à jour dès que de plus amples renseignements seront disponibles.

2. 30 juillet 2024 à 14:44 UTCupdate

   L'accès aux pages d'état est demeuré stable et Azure a mis à jour leur état indiquant que des processus d'échec ont été engagés pour améliorer la disponibilité de leurs services. Les ingénieurs de StatusCast continueront de surveiller cette situation de près et publieront des mises à jour supplémentaires au besoin.

3. 30 juillet 2024 à 20:47 UTCupdate

   L'application StatusCast a continué de rester stable. Nos ingénieurs continueront à surveiller le système de près car Microsoft n'a pas complètement fermé l'événement de leur côté. Pour plus de détails sur la question d'Azure, veuillez consulter leur page de statut. Nous fournirons des mises à jour supplémentaires au besoin.

4. 30 juillet 2024 à 22:00 UTCresolved

   Microsoft a fermé le problème de leur côté et la plate-forme de StatusCast continue à fonctionner comme prévu. Une fois que Microsoft a publié plus de détails à ce sujet, nous fournirons ici sous la forme d'un RCA.

5. 1 août 2024 à 17:07 UTCupdate

   DE MICROSOFT: Déclaration d'atténuation - Azure Front Door Questions d'accès à un sous-ensemble de services Microsoft Numéro de suivi: KTY1-HW8 Que s'est-il passé ? Entre environ 11h45 UTC et 19h43 UTC le 30 juillet 2024, un sous-ensemble de clients peut avoir éprouvé des problèmes de connexion à un sous-ensemble de services Microsoft à l'échelle mondiale. Les services impactés comprenaient les services Azure App, Application Insights, Azure IoT Central, Azure Log Search Alerts, Azure Policy, ainsi que le portail Azure lui-même et un sous-ensemble de services Microsoft 365 et Microsoft Purview. Que savons-nous jusqu'ici ? Un pic d'utilisation inattendu a donné lieu à des composants Azure Front Door (AFD) et Azure Content Delivery Network (CDN) qui se sont révélés inférieurs aux seuils acceptables, ce qui a entraîné des erreurs intermittentes, des délais et des pics de latence. Alors que l'événement déclencheur initial était une attaque de déni de service distribué (DDoS), qui a activé nos mécanismes de protection DDoS, les enquêtes initiales suggèrent qu'une erreur dans la mise en œuvre de nos défenses amplifie l'impact de l'attaque plutôt que de l'atténuer. Comment avons-nous réagi ? L'impact client a commencé à 11h45 UTC et nous avons commencé à enquêter. Une fois que la nature du pic d'utilisation a été comprise, nous avons mis en place des modifications de configuration de réseau pour soutenir nos efforts de protection DDoS, et effectué des basculements vers d'autres chemins de réseau pour fournir un soulagement. Notre configuration initiale du réseau a permis d'atténuer la majorité de l'impact par 14:10 UTC. Certains clients ont déclaré moins de 100 % de disponibilité, que nous avons commencé à atténuer vers 18h00 UTC. Nous avons procédé à une mise à jour de l'approche en matière d'atténuation, d'abord dans les régions de l'Asie-Pacifique et de l'Europe. Après avoir confirmé que cette approche révisée a permis d'éliminer les effets secondaires de l'atténuation initiale, nous l'avons déployée dans les régions des Amériques. Les taux d'échec sont revenus à des niveaux antérieurs à l'incident à 19h43 UTC - après avoir surveillé le trafic et les services pour s'assurer que la question était entièrement atténuée, nous avons déclaré l'incident atténué à 20h48 UTC. Certains services en aval ont pris plus de temps à récupérer, selon la façon dont ils ont été configurés pour utiliser l'AFD et/ou CDN. Et ensuite ? Notre équipe effectuera une rétrospective interne pour comprendre l'incident plus en détail. Nous publierons un examen préliminaire des incidents (EIP) dans environ 72 heures, afin de partager plus de détails sur ce qui s'est passé et sur la façon dont nous avons réagi. Une fois notre rétrospective interne terminée, généralement dans un délai de 14 jours, nous publierons un examen final des incidents avec tous les détails et apprentissages supplémentaires. Pour être informé lorsque cela se produit, et/ou pour rester informé des futurs problèmes de service Azure, assurez-vous de configurer et de maintenir Azure Service Alertes de santé – ceux-ci peuvent déclencher des courriels, SMS, notifications push, webhooks, et plus encore: https://aka.ms/ash-alertes. Pour en savoir plus sur les avis d'incidents, consultez https://aka.ms/AzurePIRs. Enfin, pour obtenir des directives plus générales sur la préparation aux incidents liés aux nuages, consulter https://aka.ms/incidentreadness.

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

1. 22 juillet 2024 à 16:30 UTCupdate

   StatusCast et l'équipe de support de 4me sont prêts à passer à la prochaine étape de la migration de nos services de support du système de billetterie historique de StatusCast à l'utilisation de 4me directement pour toutes les demandes de changement et les incidents. Cette prochaine étape dans l'intégration des opérations StatusCast-S à 4me vous fournira finalement beaucoup plus d'information sur les demandes que vous soumettez et leur statut. Qu'est-ce qui change? Le mercredi 24 juillet 2024 StatusLe portail d'assistance de Cast est déplacé vers https://4me-statuscast-portal.4me.com/, ce portail de libre-service sera votre nouvelle ressource pour soumettre de nouveaux tickets et voir l'état de tous ceux que vous avez soumis. Ce nouveau portail vous donnera un statut plus précis du billet, et dans le cas où vous demanderiez un changement ou tomber dans un problème qui nécessite un travail de développement, vous aurez une visibilité dans le statut de celui d'un développement à une QA, à une perspective de production. En outre, les clients pourront trouver des réponses à leurs questions en passant par le portail qui contient une base de connaissances qui sera étendue au fur et à mesure que nous irons. Nous sommes très heureux d'apporter cette visibilité étendue à nos clients car nous croyons qu'elle représente un grand pas en avant dans le soutien que nous fournissons. Suite à ce changement, l'emailing [email protected] n'ouvrira plus de tickets. Vous aurez besoin d'accéder au portail en libre-service pour soumettre et accéder aux demandes de soutien. Un lien vers ce portail d'auto-assistance a été ajouté au portail d'administration StatusCast. Vous pouvez y accéder en sélectionnant les Tickets du Centre d'aide > Les administrateurs de StatusCast existants ont obtenu l'accès à ce nouveau portail. Pour accéder au portail StatusCast, allez à https://xurrent-statuscast-portal.xurrent.com/ et commencez par « Forgot your 4me password? » (1) afin que vous puissiez recevoir un e-mail pour enregistrer votre mot de passe de portail de support. Si vous n'obtenez pas d'e-mail pendant que vous faites cela, vous n'avez peut-être pas obtenu l'accès automatisé, dans ce cas vous pouvez vous enregistrer en cliquant sur le bouton «Enregistrer comme nouvel utilisateur» (2): Le portail StatusCast vous demande d'utiliser une adresse e-mail et de configurer un mot de passe de 18 caractères.

2. 22 juillet 2024 à 16:31 UTCresolved

   auto-fermé

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

1. 5 juillet 2024 à 13:00 UTCupdate

   Conformément à notre engagement en matière de sécurité et de transparence, nous voulions vous informer que notre fournisseur de SMS, Twilio, a averti notre équipe de sécurité d'un incident survenu. Voici la déclaration que nous avons reçue de Twilio qui donne un compte rendu détaillé de l'incident et de ce qui a été fait : --------------------------------------- Twilio a été informé par l'un de nos transporteurs de sauvegarde, iBasis, que IdentifMobile a par inadvertance exposé certaines données liées aux SMS envoyées par iBasis publiquement sur l'Internet qui comprenait des données personnelles. Nous vous écrivons pour vous informer que certaines de vos données personnelles et non personnelles (comme les données liées aux campagnes de marketing) ont été consultées par un groupe de recherche sur la sécurité alors qu'elles ont été publiquement exposées par IdentityMobile. Bien que cet incident ait été hors du contrôle de Twilio, nous le prenons très au sérieux et nous nous engageons à vous aider à comprendre l'impact total. Que voulez-vous savoir ? Afin de transmettre des messages dans des régions spécifiques, Twilio compte sur de nombreux transporteurs pour maximiser la livraison à ses destinations finales. Twilio a été informé que iBasis (un transporteur de secours Twilio) avait utilisé IdentityMobile (le transporteur de secours supplémentaire d'iBasis) qui a permis par inadvertance l'accès public sur un seau S3 AWS pendant les travaux de développement. Les renseignements contenus dans ce seau ont été rendus publics du 10 au 15 mai 2024 et accessibles entre le 13 et le 14 mai 2024. D'après une enquête conjointe entre IdentityMobile et Amazon AWS, nous avons appris qu'une partie de ces données avait été consultée par le Chaos Computing Club (CCC). La CCC est un groupe de recherche sur la sécurité qui identifie les problèmes de sécurité; la CCC a confirmé qu'elle ne détient aucune donnée téléchargée à partir du seau S3 de l'AWS. Nous n'avons pas de preuves qui nous permettent de confirmer qu'aucun autre tiers n'a accédé aux données. Twilio ne possède pas ce seau, et aucun de nos systèmes n'a été compromis en relation avec cette exposition de données. Cet incident est le résultat de mesures prises par IdentificationMobile et en dehors du contrôle de Twilio. Bien que nous continuions à collaborer avec ces transporteurs afin de vous fournir les renseignements les plus exacts concernant cette exposition, la partie des données exposées par IdentificationMobile liées aux SGS envoyées entre le 1er janvier 2024 et le 15 mai 2024 comprenait : • Numéro mobile • Contenu du message SMS • ID de l'expéditeur SMS • Timetamp SMS Qu'avons-nous fait jusqu'ici? • Twilio a lancé notre processus d'intervention pour enquêter rapidement sur cette affaire. • Twilio a intensifié ce problème à l'équipe exécutive d'iBasis; par la suite, nous avons fait une analyse sur les journaux de données qui ont été compromis pour vous fournir autant d'informations que possible. • Par prudence, nous avons cessé d'envoyer du trafic à iBasis dans la mesure du possible. iBasis a informé Twilio qu'il a arrêté le routage avec IdentityMobile. • Nous continuerons à travailler avec nos transporteurs de la 3e partie pour vous obtenir tous les détails supplémentaires qui pourraient découler de cet incident. Que devez-vous faire ? Nous vous recommandons d'examiner le trafic SMS que vous avez envoyé entre le 1er janvier 2024 et le 15 mai 2024, de discuter des implications d'une exposition avec votre(s) équipe(s) interne(s) et de décider si vous devez communiquer avec les personnes touchées. Si vous avez besoin d'informations supplémentaires sur cet incident, nous sommes ici pour vous soutenir tout au long de cette situation. Nous regrettons vivement tout inconvénient que cela pourrait causer et apprécions votre compréhension et votre coopération. --------------------------------------- Qu'a fait StatusCast ? Une fois que l'équipe de sécurité de StautsCast a été alertée, un audit a été effectué pour essayer de déterminer l'impact potentiel de cette situation sur notre service. Sur la base du rapport de Twilio, il est possible que certaines notifications envoyées par l'intermédiaire du service StatusCast. Selon les données du rapport, le numéro de téléphone du destinataire ainsi que le message SMS auraient été inclus. Les notifications SMS dans StatusCast sont conçues pour être brèves et conduire les utilisateurs à la page d'état. Les messages SMS ne comprennent pas le nom des destinataires ou d'autres renseignements personnels identifiables (IPI). Comme toujours dans StatusCast, vous avez le droit de choisir si les notifications SMS sont envoyées ou non. Les options SMS peuvent être contrôlées dans les sections Paramètres et Intégration de l'application si vous souhaitez revoir vos configurations. Pour l'instant, il n'y a pas de mesures supplémentaires à prendre par StatusCast en ce qui concerne son application ou son infrastructure, mais nous allons maintenir une communication étroite avec Twilio et si des informations supplémentaires sont publiées, nous les transmettrons par notre propre page de statut. StautsCast est partenaire de Twilio depuis des années et a maintenu un engagement fort en matière de sécurité et de transparence. Nous prendrons cela en considération ainsi que cet incident en continuant d'offrir des notifications SMS dans la demande. Si vous avez des questions supplémentaires, veuillez nous contacter à [email protected]

2. 5 juillet 2024 à 13:01 UTCresolved

   auto-fermé

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

1. 7 juin 2024 à 13:00 UTCupdate

   Suite à l'acquisition de 4me, nous nous préparons à intégrer les opérations de soutien de StatusCast dans l'infrastructure de 4me. En combinant nos opérations de support avec les 4mes, nos clients auront l'avantage d'un support 24x7 et le nombre de représentants disponibles sera presque quadruple. Pour faire le premier pas en avant dans la fusion officielle de ces équipes, nous allons supprimer l'option de chat en direct disponible dans le portail admin à partir de vendredi 7 Juin 2024. Vous pouvez continuer à communiquer avec notre support via email( [email protected] ) ou en accédant à notre portail de support actuel. Dans les prochains mois, vous remarquerez plusieurs changements dans la façon dont StatusCast est fourni. Cela impliquera l'introduction d'un nouveau portail de soutien amélioré pour le suivi des demandes de changement ou des problèmes que vous avez enregistrés avec support. De plus, plus d'outils et d'information sur la vérification seront mis à disposition dans l'application, et les ressources d'aide et de connaissances seront accrues et accessibles directement. Nous sommes très heureux d'élargir notre offre de soutien avec 4me et savons qu'elle aidera en fin de compte notre communauté de clients et d'utilisateurs appréciés!

2. 7 juin 2024 à 13:01 UTCresolved

   auto-fermé

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

1. 4 avril 2024 à 00:19 UTCupdate

   À environ 8:19PM EDT, les ingénieurs de StatusCast ont été alertés que certaines pages d'état et applications administratives étaient inaccessibles. L'équipe a constaté que son partenaire d'accueil, Microsoft, rencontrait certains problèmes dans sa région des États-Unis-Est liés aux services d'applications et aux connexions SQL. À partir de 9:03PM les services d'EDT ont été restaurés et l'équipe de StatusCasts travaille actuellement avec Microsoft pour enquêter pleinement sur l'incident. Une fois que l'équipe aura terminé l'enquête, nous ferons le suivi avec une ACR. Pour l'instant, StatusCast devrait fonctionner comme prévu, si vous continuez à avoir d'autres problèmes veuillez nous contacter à [email protected]

2. 4 avril 2024 à 01:03 UTCresolved

   À partir de 9:03PM les services d'EDT ont été restaurés et l'équipe de StatusCasts travaille actuellement avec Microsoft pour enquêter pleinement sur l'incident. Une fois que l'équipe aura terminé l'enquête, nous ferons le suivi avec une ACR.

3. 5 avril 2024 à 21:00 UTCupdate

   En travaillant avec Microsoft, l'équipe de StatusCasts a confirmé que la perturbation était due à une panne avec des bases de données SQL situées dans la région d'Azure. StatusCast lui-même a été touché par cette panne d'environ 8:19 PM EDT et avait complètement récupéré par 9:03 PM EDT. StatusL'équipe de StatusCastS continuera de travailler en étroite collaboration avec Microsoft pour optimiser davantage son offre afin de s'assurer que l'impact des pannes de fournisseurs de services est le plus minime possible.

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

1. 2 avril 2024 à 13:00 UTCupdate

   We are very excited to announce that StatusCast has been acquired by 4Me! Since 2013 we have been working hard to close the gap between service outages and those who are impacted, and this acquisition is one large step further in our journey of providing critical information to those who need it most. The inclusion of StatusCast's features will aid 4Me in it's mission to modernize service management for organizations. Click here to read more!

2. 2 avril 2024 à 13:01 UTCresolved

   auto-closed

1. 8 mars 2024 à 15:01 UTCinvestigating

   We are experiencing SMS delivery delays when sending messages to Telefonica Network In Mexico. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 1 hour or as soon as more information becomes available.

2. 8 mars 2024 à 15:12 UTCinvestigating

   We are continuing our investigation and have discovered SMS Latin America is affected by SMS delivery delays when sending messages to Telefonica Network in Mexico.

3. 8 mars 2024 à 16:22 UTCmonitoring

   We are observing recovery in SMS delivery delays when sending messages to Telefonica Network in Mexico. We will continue monitoring the service to ensure a full recovery. We will provide another update in 2 hours or as soon as more information becomes available.

4. 8 mars 2024 à 16:23 UTCresolved

   auto-closed

1. 8 mars 2024 à 13:26 UTCinvestigating

   We are continuing to experience SMS Delivery Delays when sending messages to Multiple Networks in Thailand. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 2 hours or as soon as more information becomes available.

2. 8 mars 2024 à 15:20 UTCmonitoring

   We are observing recovery in SMS delivery delays when sending messages to Multiple Networks in Thailand. We will continue monitoring the service to ensure a full recovery. We will provide another update in 2 hours or as soon as more information becomes available.

3. 8 mars 2024 à 17:05 UTCresolved

   We are no longer experiencing SMS delivery delays when sending messages to Multiple Networks in Thailand. This incident has been resolved.

1. 7 mars 2024 à 07:27 UTCinvestigating

   We've become aware of a potential issue with SMS Message Delivery delay to Tigo Network In Chad. Our engineering team has been alerted and is actively investigating. We will update as soon as we have more information.

2. 7 mars 2024 à 07:37 UTCinvestigating

   We are experiencing SMS delivery delays when sending messages to Tigo Network In Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 1 hour or as soon as more information becomes available.

3. 7 mars 2024 à 07:43 UTCinvestigating

   We are experiencing SMS delivery delays when sending messages to Tigo Network In Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 1 hour or as soon as more information becomes available.

4. 7 mars 2024 à 08:34 UTCinvestigating

   We are continuing to experience SMS delivery delays when sending messages to Tigo Network In Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 2 hours or as soon as more information becomes available.

5. 7 mars 2024 à 10:28 UTCinvestigating

   We are continuing to experience SMS delivery delays when sending messages to Tigo Network In Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 4 hours or as soon as more information becomes available.

6. 7 mars 2024 à 14:18 UTCinvestigating

   We are continuing to experience SMS delivery delays when sending messages to Tigo Network in Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 8 hours or as soon as more information becomes available.

7. 7 mars 2024 à 15:12 UTCmonitoring

   We are observing recovery in SMS delivery delays when sending messages to Tigo Network In Chad. We will continue monitoring the service to ensure a full recovery. We will provide another update in 30 min or as soon as more information becomes available.

8. 7 mars 2024 à 15:13 UTCresolved

   auto-closed