Historique des pannes de Rightscale

1. 24 août 2026 à 13:04 UTCinvestigating

   Description de l'incident : Nous enquêtons sur une question touchant le traitement des stocks au sein de Flexera One IT Asset Management en Amérique du Nord. Les clients peuvent avoir des retards dans le traitement des stocks et la disponibilité de données d'inventaire mises à jour au sein de la plateforme. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement la question et examinent les activités de traitement des stocks dans l'ensemble du service touché. Nous nous efforçons d'identifier la cause des retards de traitement et de rétablir un traitement normal. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 24 août 2026 à 14:57 UTCinvestigating

   Les équipes techniques ont constaté que le comportement de traitement des stocks varie selon les clients touchés. Bien que les stocks continuent d'être traités pour certains clients, d'autres connaissent des taux de traitement sensiblement réduits ou des stocks qui ne progressent pas au moyen de processus de traitement normaux. Les équipes techniques ont également relevé des erreurs de disponibilité du service affectant certaines tentatives de téléchargement des stocks et étudient activement la portée de l'impact et la cause sous-jacente. L'analyse des organisations touchées et des activités de traitement se poursuit. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

3. 24 août 2026 à 16:38 UTCidentified

   Les équipes techniques ont effectué des mesures ciblées de recouvrement des services et observent le curriculum vitæ du traitement des stocks pour les clients précédemment touchés, les niveaux d'arriéré diminuant. Les enquêtes se poursuivent à mesure que les équipes techniques continuent de surveiller le rétablissement et d'évaluer la cause sous-jacente. Bien que des progrès aient été observés, les équipes continuent de valider la stabilité des services et de surveiller les répercussions restantes. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

4. 24 août 2026 à 21:21 UTCmonitoring

   La reprise continue de progresser, les activités de traitement des stocks revenant aux niveaux prévus pour les clients précédemment touchés. Les équipes techniques observent une réduction continue des arriérés et surveillent activement la stabilité des services. L'enquête sur la cause sous-jacente se poursuit. L'analyse actuelle porte sur plusieurs facteurs contributifs potentiels identifiés au cours de la période touchée, tandis que les équipes techniques continuent de valider le rétablissement et de surveiller tout impact restant.

5. 25 août 2026 à 10:00 UTCmonitoring

   Les équipes techniques continuent d'observer une réduction régulière des arriérés tout en surveillant de près la stabilité globale des services. Une enquête sur la cause sous-jacente est en cours. Nous continuerons de fournir des mises à jour au fur et à mesure que des renseignements supplémentaires seront disponibles.

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

1. 18 août 2026 à 09:32 UTCinvestigating

   Description de l'incident: Nous enquêtons actuellement sur une question touchant l'accès aux services Flexera One dans la région APAC. Les clients touchés peuvent éprouver des difficultés à accéder à la plateforme ou rencontrer des erreurs après l'authentification. Priorité: P1 Activité de restauration : Notre technique a été engagée et étudie activement la question afin d'identifier la cause sous-jacente et de rétablir le service normal le plus rapidement possible.

2. 18 août 2026 à 10:18 UTCidentified

   Notre enquête a identifié un problème de configuration comme étant la cause probable de l'impact. Les équipes s'emploient activement à mettre en oeuvre et à valider des mesures correctives pour rétablir l'exploitation normale du service. D'autres mises à jour seront fournies à mesure que l'enquête progressera.

3. 18 août 2026 à 10:43 UTCidentified

   Au fur et à mesure que l'enquête progresse, nos équipes ont identifié des indications selon lesquelles la question n'est pas isolée de la gestion des actifs de TI et pourrait avoir un impact plus large sur la plate-forme Flexera One dans APAC. Des efforts d'assainissement sont en cours contre la cause identifiée, et les équipes se concentrent sur le rétablissement de la pleine stabilité du service. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

4. 18 août 2026 à 10:50 UTCidentified

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

5. 18 août 2026 à 11:47 UTCmonitoring

   Un correctif a été mis en place et l'accès à la plate-forme Flexera One a été restauré. Nos équipes mènent d'autres activités de validation et continuent de surveiller de près la santé et le rendement des services pour confirmer la stabilité et s'assurer que tous les services demeurent pleinement opérationnels.

6. 18 août 2026 à 12:13 UTCresolved

   Suite aux activités de surveillance et de vérification étendues, nos équipes ont confirmé que les services demeurent stables et qu'aucun impact supplémentaire n'a été observé. L'incident a été résolu et tous les services touchés sont pleinement opérationnels.

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

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

   Incident Description: We are currently investigating an issue impacting the reconciliation process within the IT Asset Management platform in the EU region. Affected customers may experience failures when attempting to run reconciliation jobs. As a result, reconciliation processes may not complete successfully, potentially delaying data updates and downstream processing. Priority: P2 Restoration Activity: Our technical teams have been engaged and are actively working to identify the root cause and restore services. Further updates will be provided as we continue working toward resolution.

2. 13 août 2026 à 03:27 UTCmonitoring

   Our teams identified a configuration issue introduced during the completion of a standard release earlier today, which prevented an instance from successfully communicating with the Reconcile service. The affected instance's configuration process was successfully re-executed, restoring the required settings and re-establishing connectivity with the Reconcile service. Validation testing confirmed normal service operation, and reconciliation processing has resumed successfully. The environment remains under monitoring to ensure continued stability.

3. 13 août 2026 à 03:27 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 13 août 2026 à 05:57 UTCresolved

   Following extended monitoring, our teams have confirmed that the platform has remained stable and no recurrence of the issue has been observed since the remediation actions were completed. Reconciliation processing continues to operate normally, connectivity with the Reconcile service remains healthy, and all validation checks have been successful. Based on the sustained stability of the environment and the absence of any further failures, this incident has been resolved

1. 11 août 2026 à 17:26 UTCinvestigating

   Incident Description: We are investigating an issue affecting Cloud Cost Optimization (CCO) services in the North America (NAM) region. Customers may experience pages failing to load, prolonged loading behavior, or difficulty accessing certain Cloud Cost Optimization functionality within Flexera One. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and working to restore normal service. Current efforts are focused on identifying the cause of the degradation and validating corrective actions. We will provide additional updates as more information becomes available.

2. 11 août 2026 à 17:48 UTCidentified

   Our investigation has identified the issue affecting certain Cloud Cost Optimization (CCO) functionality in the North America region. Following a recent service migration, some application components were not operating with the expected resource configuration, resulting in certain requests failing to complete and impacted pages remaining in a continuous loading state. Our technical teams have implemented configuration changes to restore the appropriate resource allocation for the affected services and are currently deploying those changes. We are monitoring recovery and validating service functionality as the update takes effect. We will provide additional updates as progress continues.

3. 11 août 2026 à 18:08 UTCmonitoring

   The configuration changes have been deployed, and the affected service components are now operating with the intended resource configuration. Our technical teams have observed recovery of the impacted Cloud Cost Optimization (CCO) functionality in the North America region and are performing final validation to confirm service stability. We will continue to monitor the environment closely and provide a further update once validation activities are complete.

4. 11 août 2026 à 20:26 UTCresolved

   Following a period of monitoring, services have remained stable and no further issues have been observed. This incident is now considered resolved.

5. 14 août 2026 à 20:02 UTCpostmortem

   **Description:** Flexera One - Cloud Cost Optimization \(CCO\) - North America - Service Degradation Affecting Certain Functionality **Timeframe:** August 11, 2026, 9:51 AM PDT – August 11, 2026, 10:45 AM PDT **Incident Summary** On August 11, 2026, customers may have experienced issues accessing certain Cloud Cost Optimization \(CCO\) functionality in the North America region. Impacted pages could remain in a continuous loading state and fail to render correctly. Technical teams began investigating after identifying that certain application requests were not completing successfully. The impact was limited to specific functionality rather than the entire CCO service. During the investigation, technical teams determined that dependent application services were unable to successfully retrieve required configuration information from a supporting service component, resulting in rendering issues for affected functionality. Corrective configuration changes were implemented and updated service components were deployed. Following deployment, technical teams validated recovery and continued monitoring the environment to confirm stable operation. All affected functionality subsequently returned to normal operation. **Root Cause** During a recent service migration, a supporting application component was deployed with an incorrect resource configuration. As processing demand increased, the affected service components exhausted available resources and became unavailable. As a result, dependent application services were unable to successfully retrieve required configuration information needed to process certain requests. This resulted in rendering issues affecting specific Cloud Cost Optimization \(CCO\) functionality. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Investigation Initiated: Technical teams investigated reports of affected CCO functionality remaining in a continuous loading state and failing to render correctly. 2. Service Dependency Analysis Performed: Technical teams identified that dependent application services were unable to successfully retrieve required configuration information from a supporting service component. 3. Configuration Issue Identified: Investigation determined that a supporting application component had been deployed with an incorrect resource configuration following a recent service migration. 4. Corrective Configuration Changes Applied: Technical teams implemented configuration changes to restore the intended operating parameters for the affected service components. 5. Service Recovery Validation Performed: Updated service components were deployed, affected functionality was validated, and the environment was monitored to confirm stable operation before incident closure. **Future Preventative Measures** Following this incident, technical teams reviewed the migration and deployment process associated with the affected service component. 1. Configuration Validation Enhancements: An additional validation step has been added to verify that service configurations are appropriate for forecasted processing requirements following migration activities. This additional review is intended to help identify configuration discrepancies before they can affect production workloads.

1. 7 août 2026 à 04:55 UTCinvestigating

   Description de la question: Nos équipes ont identifié que certains systèmes d'email des clients Flexera rejettent les e-mails envoyés contenant des notifications de mises à jour sur les cas Flexera Support. Priorité: P3 Activité de restauration : Les équipes techniques étudient activement la question. Entre-temps, veuillez vous connecter à la communauté Flexera et utiliser le portail Support Case à l'adresse https://community.flexera.com/s/case/Case/Default pour examiner l'état du cas et vérifier toute mise à jour.

2. 7 août 2026 à 12:28 UTCidentified

   Nos équipes ont identifié la cause du problème et travaillent actuellement à le résoudre.

3. 8 août 2026 à 10:48 UTCidentified

   Nos équipes continuent de travailler à une résolution. Au cours de l'enquête en cours, nous avons constaté que, dans certains cas, les courriels de Flexera pourraient être bloqués par SharePoint. Pour remédier à cette situation, il faut mener des enquêtes supplémentaires et assurer la coordination avec les parties concernées afin de s'assurer que les mesures correctives appropriées sont prises. Nous continuerons de fournir des mises à jour à mesure que de plus amples renseignements seront disponibles.

4. 10 août 2026 à 10:10 UTCidentified

   Nos équipes continuent de travailler vers une résolution. Des recherches et une coordination supplémentaires avec les équipes compétentes sont en cours pour rétablir un flux normal de courriels. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

5. 12 août 2026 à 13:50 UTCmonitoring

   Nos équipes ont mis en œuvre des mesures correctives et observent des résultats positifs. Les essais initiaux de validation ont été couronnés de succès, ce qui indique que les mesures d'atténuation sont efficaces. Nous continuerons de surveiller de près le service afin d'assurer une stabilité continue et fournirons d'autres mises à jour au fur et à mesure qu'elles seront disponibles.

6. 14 août 2026 à 05:41 UTCresolved

   Après un suivi prolongé, nos équipes ont confirmé que toutes les mises à jour par courriel sont livrées avec succès. Cet incident a été déclaré résolu.

7. 21 août 2026 à 09:13 UTCpostmortem

   **Description:** Cas de soutien Flexera – Notifications de courriel différées ou ratées **Calendrier:** 5 août 2026, 12 h 00 PDT au 13 août 2026, 11 h 10 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le 5 août 2026, nos équipes ont identifié un problème touchant les notifications par courriel pour les cas Flexera Support. Au cours de l'incident, certains clients n'ont pas reçu d'avis par courriel lorsque des mises à jour ont été faites à leurs dossiers de soutien, ce qui peut avoir retardé la connaissance de l'activité et des progrès réalisés. Nos équipes techniques ont enquêté sur la question et ont déterminé qu'un problème lié à la configuration de la livraison des courriels a causé le rejet par les systèmes de courrier électronique des notifications de cas de soutien sortant. À titre provisoire, il a été conseillé aux clients d'accéder directement au portail Flexera Community Support Case pour examiner leur situation et leurs mises à jour. Nos équipes ont apporté un changement permanent à la configuration de livraison des courriels et ont ensuite validé la livraison des notifications. Après l'assainissement, on a confirmé que les notifications par courriel fonctionnaient comme prévu, et l'incident a été résolu le 13 août 2026, à 11 h 10. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) * Configuration de livraison du courriel : Un problème avec la configuration utilisée pour fournir des notifications de cas d'assistance face au client a causé le rejet de certains courriels par les systèmes de messagerie des destinataires. * Notification Delivery: La configuration affectée a conduit certains clients à ne pas recevoir de notifications par courriel lorsque des mises à jour ont été faites à leurs cas de support. * Impact client : Le problème n'a été signalé que par e-mail ; les clients pourraient continuer à accéder à leurs dossiers de support directement via le portail Flexera Community Support Case. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) * Mise à jour de la configuration de livraison du courriel : La configuration de livraison des courriels a été mise à jour en permanence afin d'utiliser l'infrastructure principale de livraison des courriels. * Validation de la notification : Les équipes ont validé la livraison de la notification à l'étranger après le changement de configuration. * Solutions de rechange pour les clients : Au cours de l'incident, les clients ont été invités à accéder au portail Flexera Community Support Case pour examiner l'état des cas et les mises à jour. * Surveillance des services : Les équipes ont surveillé l'envoi des notifications par courriel après l'assainissement afin de confirmer la stabilité continue. (en milliers de dollars) ** Mesures préventives à venir** * Maintenez l'acheminement des courriels approuvé : Les avis de cas de soutien adressés aux clients continueront d'utiliser l'infrastructure principale de livraison des courriels établie par l'assainissement permanent. * Surveillance de la prestation des courriels : améliorer la surveillance et l'alerte en cas d'échec de la notification des cas de soutien à l'étranger et les messages rejetés afin de permettre une détection plus rapide des problèmes potentiels de livraison.

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

1. 5 août 2026 à 08:28 UTCresolved

   Description de l'incident: Nos équipes ont identifié une interruption de service affectant un sous-ensemble de clients de Flexera One IT Asset Management (ITAM) dans l'environnement de production APAC du 4 août 2026, 04:04 PDT à 04:25 PDT . Pendant la période touchée, un sous-ensemble de nos clients ont connu une lenteur intermittente, un manque de service ou des défaillances de chargement de données au sein de la plateforme. Priorité : P2 Activité de restauration : Nos équipes techniques ont étudié la question et déterminé qu'une situation inattendue d'épuisement des ressources de la base de données s'est produite pendant la période touchée. L'état s'est ensuite autocorrigé, ce qui a permis aux services touchés de se rétablir et de reprendre le fonctionnement normal. La validation après incident a confirmé que les opérations de la plate-forme se déroulent comme prévu. Nous effectuons un examen détaillé de l'incident et nous évaluons des mesures de protection supplémentaires, des contrôles de capacité et des améliorations de surveillance afin de réduire davantage la probabilité d'événements semblables à l'avenir.

2. 21 août 2026 à 09:03 UTCpostmortem

   **Description:** Flexera One - Gestion des biens informatiques - APAC - Défaillances/faiblesse du chargement des données **Calendrier:** 4 août 2026, 4:04 PDT au 4 août 2026, 4:25 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le mardi 4 août 2026, nos équipes ont identifié un problème touchant un sous-ensemble de clients dans l'environnement APAC Production. Au cours de l'incident, certains clients ont connu une lenteur d'application intermittente, une inadaptation temporaire et des défaillances lors du chargement des données dans Flexera One IT Asset Management. Nos équipes techniques ont étudié la question et déterminé qu'un événement inattendu d'épuisement des ressources de base de données a affecté l'environnement de production. Cette situation a entraîné une dégradation temporaire de la performance d'un sous-ensemble de locataires. L'état de la base de données s'est résolu automatiquement après environ 20 minutes, et la performance de l'application est revenue à la normale sans nécessiter une intervention technique directe. Nos équipes ont continué à surveiller l'environnement après la récupération et ont confirmé que les services touchés fonctionnaient normalement sans impact client permanent. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) * Épuisement imprévu de la base de données : Une augmentation temporaire de la consommation de la base de données a épuisé la capacité de stockage temporaire de la base de données utilisée par le groupe de la base de données de production. * Demandes de renseignements sur la consommation élevée de ressources : Il a été identifié que des requêtes inattendues spécifiques sont exécutées manuellement par un utilisateur qui a consommé des quantités importantes de ressources de base de données temporaires, ce qui a entraîné un épuisement temporaire des ressources. * Impact sur le rendement de l'application : L'épuisement des ressources a affecté les opérations de la base de données et a entraîné la lenteur de l'application, la non-réactivité et des défaillances du chargement des données pour un sous-ensemble de clients. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) * Récupération automatique du service : l'état de la ressource de la base de données s'est effacé automatiquement, permettant aux services d'application de revenir à l'exploitation normale. * Surveillance des services : Les équipes ont surveillé l ' environnement à la suite du relèvement et ont confirmé que les services restaient stables. * Analyse des incidents : Les équipes du génie ont examiné l'activité de la base de données et l'utilisation des ressources associées à l'événement afin d'identifier les demandes de renseignements et de comprendre le comportement. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) * Gouvernance des ressources: évaluer SQL supplémentaire Contrôles de gouvernance des ressources du serveur pour réduire l'impact potentiel des requêtes de base de données à ressources élevées. * Améliorations de l'intervention en cas d'alerte : Examiner les procédures de traitement des alertes afin d'améliorer la détection, l'évaluation et l'intervention en cas d'état semblable des ressources de la base de données. * Améliorations opérationnelles : La question a été examinée par nos équipes techniques et une mesure a été mise en place pour éviter un scénario similaire à l'avenir.

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

1. 3 août 2026 à 06:56 UTCinvestigating

   Description de l'incident: Nous enquêtons actuellement sur un problème touchant les téléchargements de paquets d'inventaire (*.zip) dans la région Europe pour Flexera One IT Asset Management. Les clients qui tentent de télécharger des paquets d'inventaire spécifiques peuvent rencontrer des erreurs, ce qui entraîne des retards dans le traitement des données d'inventaire. Priorité : P2 Activité de restauration : Notre équipe technique étudie activement la question et passe en revue les activités actuelles de traitement pour confirmer la portée et les progrès. Nous surveillons la situation de près et fournirons des mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 3 août 2026 à 08:10 UTCinvestigating

   Nos équipes continuent d'enquêter activement sur la question et effectuent un examen détaillé des registres et des diagnostics du système afin d'identifier et de confirmer la cause fondamentale sous-jacente. Nous fournirons des mises à jour supplémentaires à mesure que de plus amples renseignements seront disponibles.

3. 3 août 2026 à 09:38 UTCinvestigating

   Au cours de l'enquête en cours, nos équipes ont identifié que le problème pourrait également avoir un impact sur les communications par balises avec l'environnement de production Flexera One EU. Par conséquent, d'autres opérations qui reposent sur la communication de la balise à la plate-forme peuvent être affectées. L'équipe continue d'étudier la cause sous-jacente, d'évaluer l'ampleur de l'impact et de travailler à la mise en oeuvre d'une résolution le plus rapidement possible.

4. 3 août 2026 à 10:40 UTCmonitoring

   Nos équipes ont identifié un changement de configuration récent comme étant la cause probable du problème. La configuration a depuis été repoussée, et nous observons la récupération du service à travers les composants touchés, la fonctionnalité de la plate-forme revenant progressivement aux niveaux attendus. Les équipes restent actives dans la surveillance de l'environnement afin de valider la récupération complète, d'assurer la stabilité de la plate-forme et de traiter rapidement les impacts résiduels.

5. 3 août 2026 à 10:40 UTCmonitoring

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

6. 3 août 2026 à 17:09 UTCmonitoring

   Les mesures d'atténuation demeurent efficaces et le traitement des stocks se poursuit avec succès. Nous surveillons activement les progrès en matière de recouvrement et nous nous attelons à l'arriéré pour nous assurer que tous les processus sont terminés avec succès. Nous continuerons de fournir des mises à jour à mesure que les efforts de rétablissement progresseront.

7. 4 août 2026 à 07:02 UTCmonitoring

   Le rétablissement des services est toujours en bonne voie et les mesures d'atténuation demeurent efficaces. Le traitement des stocks fonctionne avec succès, et l'arriéré a été considérablement réduit, ce qui rapproche les volumes des niveaux normaux. Nos équipes continuent de surveiller l'environnement et de traiter le reste de l'arriéré pour terminer le rétablissement. D'autres mises à jour seront fournies le cas échéant.

8. 4 août 2026 à 11:09 UTCresolved

   L'environnement est revenu à des niveaux d'exploitation normaux. Le traitement des stocks et les communications par balises sont stables et l'arriéré est revenu aux seuils prévus. La plate-forme demeure saine, la surveillance continue confirmant une stabilité soutenue. Des détails supplémentaires sur la cause profonde, les mesures de réparation et les initiatives d'amélioration à long terme seront communiqués dans un rapport post mortem après validation des résultats.

9. 18 août 2026 à 12:41 UTCpostmortem

   **Description:** Flexera One- Gestion des actifs informatiques - UE - Erreurs de téléchargement d'inventaire **Calendrier :** 31 juillet 2026, 18 h PDT au 4 août 2026, 16 h 09 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le dimanche 2 août 2026, à 23h42 PDT, Flexera a identifié un problème affectant le paquet d'inventaire \(\*.zip\) télécharge et sélectionne les communications de balises dans l'environnement Flexera One IT Asset Management EU Production. Les clients touchés ont connu des téléchargements de paquets d'inventaire échoués, y compris les réponses HTTP 504 \(Gateway Timeout\) et HTTP 405 \(Méthod Non Autorisé\). La question a également perturbé certaines communications de balises à plates-formes, entraînant des retards ou des défaillances dans le traitement des stocks et l'ingestion de données d'inventaire. L'enquête a permis de déterminer que les premiers impacts ont commencé à 18 h HAP le 31 juillet 2026. L'analyse a mis en évidence un problème de communication dans le cadre d'un cheminement critique des services qui a empêché un sous-ensemble de demandes d'atteindre avec succès les services de traitement en aval. Cela s'est traduit par des rappels répétés, un retard dans le traitement des stocks et une accumulation d'arriérés. Pour atténuer le problème et rétablir le service, le trafic a été redirigé vers un autre chemin de communication. À la suite de ce changement, les communications par balises se sont stabilisées, les chargements d'inventaire ont repris avec succès le traitement et l'arriéré d'inventaire a commencé à diminuer. À 3 h 42, le 3 août 2026, les chargements d'inventaire ont été effectués avec succès et aucune nouvelle erreur n'a été observée. L'environnement est resté sous surveillance étendue tandis que les volumes de traitement sont revenus à des niveaux d'exploitation normaux. À 4 h 09, le 4 août 2026, Flexera a confirmé que les communications de balises, le traitement des stocks et les services de plate-forme associés fonctionnaient normalement, que l'arriéré était revenu aux seuils prévus et que l'incident avait été officiellement déclaré résolu. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) Le 31 juillet 2026, une mise à jour du certificat d'un chemin de communication de service critique a créé un décalage de configuration entre les composants de la plateforme. Le problème est apparu plus tard, lorsque les composants d'application ont été redémarrés et ont commencé à établir de nouvelles connexions en utilisant la configuration mise à jour. Cela a causé des erreurs de poignée de main et des défaillances de communication, entraînant l'indisponibilité du service. Par conséquent, les demandes des balises client de télécharger les fichiers \(\*.zip\) de l'inventaire dans l'environnement de production de l'UE n'ont pas pu être traitées, ce qui a entraîné des défaillances de téléchargement et empêché la réception et le traitement des données d'inventaire. Un sous-ensemble d'autres interactions de balise à plate-forme a également été affecté, bien que l'impact client n'ait pas été observé immédiatement. Le service a été rétabli en redirigeant le trafic vers un autre chemin de communication qui n'était pas affecté par le problème de configuration lié au certificat. Les chargements d'inventaire et les communications de balises ont ensuite repris leur fonctionnement normal. Facteurs contributifs * Défauts de la demande d'envoi : Les tentatives d'établissement de connexion échouées ont causé l'échec d'une partie des demandes avant d'atteindre les services de traitement en aval. * Délais de traitement des stocks : Les défaillances de communication ont empêché certains colis d'inventaire et les importations connexes d'être traitées avec succès, ce qui a retardé les mises à jour des stocks. * Croissance de l'arriéré d'essais : Les mécanismes automatisés de réessai ont permis à de nombreuses transactions de réussir, mais ils ont contribué à augmenter les délais de traitement et l'accumulation d'arriérés pendant que le problème demeurait actif. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) Pour rétablir le service, les équipes techniques ont effectué les actions suivantes : * Réacheminement du trafic : Rediriger le trafic hors de la voie de service affectée pour restaurer les communications de balises stables et les téléchargements de paquets d'inventaire. * Surveillance de la plate-forme : Effectuer une surveillance continue des communications de balises, des chargements d'inventaire et des activités de traitement pour vérifier la récupération du service. * Backlog Recovery Management : Suivi du débit de traitement des stocks et validation de la réduction constante des arriérés de traitement et du retour aux seuils d'exploitation prévus. * Validation de la stabilité : a effectué une surveillance étendue après la restauration afin de confirmer la stabilité soutenue de la plate-forme et le traitement réussi des stocks. * Confirmation de la restauration du service : Le 4 août 2026, à 4 h 09, PDT a confirmé que les communications par balises, le traitement des stocks et les services connexes fonctionnaient normalement. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) * Service Communication Résilience: Examiner et améliorer la voie de communication affectée pour améliorer la fiabilité, la résilience et la récupération à partir de futures perturbations liées à la connectivité. * Validation renforcée des changements : Améliorer les processus de validation et d'essai pour les changements d'infrastructure, de configuration, de certificat et de voie de service afin d'identifier les erreurs de communication avant le déploiement dans les environnements de production. * Amélioration de la détection et de l'alerte : améliorer les capacités de surveillance et d'alerte afin de permettre d'identifier plus tôt les perturbations de communication soutenues, d'accroître l'activité de réessayer, les taux d'erreurs anormales et les nouveaux arriérés de traitement. Ces améliorations permettront d'accélérer la détection, l'enquête et l'assainissement des problèmes avant qu'ils ne se transforment en un impact plus large sur la clientèle.

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

1. 29 juillet 2026 à 04:36 UTCinvestigating

   Description de l'incident : Nous enquêtons sur une question touchant le service de recherche sur la vulnérabilité des logiciels (SVR). Les clients peuvent éprouver des difficultés à accéder au SVR ou à l'utiliser. Priorité: P1 Activité de restauration : Nos équipes enquêtent activement sur la question et travaillent à la restauration du service. Des activités d'atténuation sont actuellement en cours alors que nous travaillons à remettre le service en ligne. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 29 juillet 2026 à 06:02 UTCinvestigating

   Des mesures de recouvrement ont été mises en œuvre; toutefois, le service continue de connaître une instabilité dans les conditions actuelles de la charge de travail, ce qui entraîne des perturbations continues. Nos équipes s'emploient activement à réduire l'impact et à rétablir la disponibilité des services. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

3. 29 juillet 2026 à 09:52 UTCresolved

   Les équipes techniques ont rétabli la disponibilité du service pour la recherche sur la vulnérabilité des logiciels (SVR). Des mesures de rétablissement ont été mises en place pour contrer l'instabilité du service, et la validation a confirmé que la fonctionnalité de SVR a été rétablie. Nous continuerons de surveiller de près le service afin d'assurer une stabilité continue. Un rapport post mortem contenant des détails supplémentaires, y compris la cause profonde et les mesures préventives, sera publié dans les prochains jours.

4. 11 août 2026 à 10:28 UTCpostmortem

   **Description:** Recherche sur la vulnérabilité des logiciels \(SVR\) - Perturbation du service **Calendrier:** 28 juillet 2026, 14h00 PDT au 29 juillet 2026, 14h53 PDT (en milliers de dollars) **Résumé de l'incident** Mardi 28 juillet 2026, à 14h00 PDT, l'environnement de production de Flexera Software Vulnerability Research\(SVR\) a connu une perturbation du service qui a affecté la disponibilité des API et la fonctionnalité de l'application. L'incident s'est produit lorsque l'instance de base de données principale appuyant la plate-forme SVR est devenue indisponible. Les connexions existantes à la base de données ont été interrompues de façon inattendue, et les serveurs d'application n'ont pas pu établir de nouvelles connexions. Par conséquent, les clients n'ont pas pu accéder de façon fiable aux services SVR et aux API pendant l'incident. Au cours de l'enquête, nos équipes ont déterminé que la perturbation était causée par une panne imprévue déclenchée par le fournisseur de services cloud. Selon l'historique de l'événement du fournisseur, un problème d'infrastructure a été détecté sur le serveur de base de données principal, ce qui a incité le fournisseur à lancer automatiquement le processus d'échec. Nos équipes techniques ont immédiatement engagé le fournisseur de services cloud pour enquêter sur l'incident et restaurer le service. À la suite des activités de récupération et de validation, tous les services de production ont été rétablis avec succès et rendus à l'exploitation normale le 29 juillet 2026 à 14 h 53. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) L'incident a été déclenché par une panne imprévue de la base de données de production, déclenchée par le fournisseur de services en nuage en réponse à un problème d'infrastructure touchant l'hôte principal de la base de données. Pendant la mise en échec, l'instance principale de la base de données est devenue temporairement indisponible. Cela a provoqué la cessation brutale des connexions de base de données actives, empêchant les services d'application d'établir de nouvelles connexions. Par conséquent, les demandes d'API ont échoué et la disponibilité du service dans toute la plate-forme SVR a été touchée. Flexera a officiellement demandé une analyse détaillée des causes profondes \(RCA\) au fournisseur de services en nuage pour déterminer la condition précise de l'infrastructure qui a déclenché la panne et pour identifier les possibilités d'empêcher la récurrence. (en milliers de dollars) ** Facteurs contributifs** (en milliers de dollars) Au cours de l'enquête, les facteurs suivants ont été identifiés comme pouvant contribuer à l'impact global de l'incident : * Au cours de la période de l'incident, on a observé une augmentation significative du volume des tentatives de connexion des clients. * Les volumes de connexion ont dépassé les niveaux d'exploitation normaux, augmentant la charge sur les services de backend pendant la récupération des services de base de données. * L'activité de connexion élevée a peut-être amplifié l'impact de la faillite de la base de données et accru la complexité de la récupération. * Les comportements de ré-essai et de connexion existants ont généré une demande de connexion supplémentaire pendant les activités de récupération de la base de données. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) * Engagement du fournisseur Cloud : Nos équipes ont immédiatement engagé le fournisseur de services Cloud et ont travaillé directement avec leurs ingénieurs sur appel tout au long de l'effort de récupération. * Récupération de la base de données : Exécuté une base de données contrôlée en coordination avec le fournisseur de services Cloud. * Connectivité rétablie : Disponibilité de la base de données rétablie et connectivité à l'environnement de production. * Validation de la récupération de l'application : Confirmé que les services d'application se sont réconnectés avec succès aux services de base de données. * Validation du service : Récupération vérifiée des API et fonctionnalité d'application SVR critique. * Surveillance post-récupération : Mise en oeuvre d'une surveillance améliorée de la santé des bases de données, du rendement des applications et des activités de connexion après restauration. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) * Continuer de surveiller les volumes de connexion client et l'utilisation de la base de données. * Revoir et optimiser la mise en commun de la connexion à la base de données, la gestion de la connexion, la logique de réessayer et la gestion des défaillances afin d'améliorer la résilience lors des futures infrastructures. * Remplir l'engagement du fournisseur de services en nuage et examiner l'analyse détaillée de la cause racine du fournisseur une fois disponible. * Procéder à un examen interne post-incident et mettre en oeuvre des mesures préventives supplémentaires identifiées dans le cadre du processus d'examen.

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

1. 28 juillet 2026 à 23:14 UTCinvestigating

   Description de l'incident : Nous enquêtons sur un problème intermittent touchant les services Flexera One dans la région APAC. Les clients peuvent éprouver des problèmes d'accès intermittents ou des erreurs lors de l'utilisation des applications et des services Flexera One. La question semble actuellement limitée à la région de l'APAC. Priorité : P2 Activité de restauration : Nos équipes étudient activement la question. La portée et l'impact sont évalués dans l'ensemble des services Flexera One dans la région de l'APAC, et nous nous efforçons d'identifier la cause sous-jacente et de rétablir la stabilité du service. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 29 juillet 2026 à 00:34 UTCinvestigating

   Nos équipes techniques étudient activement la question. La question semble être intermittente, certaines demandes étant suivies tandis que d'autres continuent d'échouer. Nous examinons les services touchés et leurs dépendances afin de déterminer la portée de l'impact, de déterminer la cause sous-jacente et de rétablir la stabilité des services.

3. 29 juillet 2026 à 02:05 UTCresolved

   Les équipes techniques ont atténué le problème touchant les services Flexera One dans la région de l'APAC. La fonctionnalité du service a été rétablie et la validation confirme que les applications et les services touchés fonctionnent comme prévu. Au cours de l'enquête, les équipes ont relevé des problèmes de communication intermittente qui ont causé des problèmes d'accès et des erreurs à certains clients. Dans le cadre de l'effort d'atténuation, les équipes techniques ont redémarré les services touchés, après quoi la fonctionnalité du service a été récupérée et la validation a confirmé la restauration réussie des services touchés. Nous continuerons d'examiner l'incident et de surveiller la santé des services.

4. 12 août 2026 à 17:33 UTCpostmortem

   **Description:** Flexera One - APAC - Perturbation du service intermittent Calendrier **Calendrier:** 28 juillet 2026, 15 h 49 PDT - 28 juillet 2026, 17 h 40 PDT ## Résumé de l'incident Le mardi 28 juillet, 2026, à 15:49 PDT, les clients utilisant Flexera Un des services de la région de l'APAC a commencé à subir des perturbations intermittentes touchant plusieurs applications et capacités de plate-forme. Les clients peuvent avoir rencontré des problèmes de connexion, des erreurs d'application, des chargements de pages échoués, des erreurs d'API et un accès intermittent à certaines fonctionnalités Flexera One. Au cours de l'incident, plusieurs services ont connu des défaillances de communication intermittentes avec des services de plate-forme partagée. Par conséquent, les clients ont connu un comportement d'application incohérent, certaines demandes ayant réussi tandis que d'autres ont échoué. Les équipes techniques ont étudié la question dans toutes les applications touchées et les composantes de la plateforme afin de déterminer la portée et la source des défaillances. L'enquête a mis en évidence un problème de connectivité affectant la communication entre les services d'application et une dépendance à la plate-forme partagée. Des modifications de configuration correctives ont été apportées pour rétablir la communication de service et stabiliser la fonctionnalité affectée. À la suite de la mise en oeuvre des modifications correctives, les équipes techniques ont validé la fonctionnalité des applications touchées et confirmé que les services étaient revenus à l'exploitation normale. La surveillance continue a montré un comportement de service stable, et l'incident a été résolu à 17h40 PDT le 28 juillet 2026. La cause profonde L'enquête a permis de déterminer que l'incident était causé par un problème de connectivité introduit lors d'une migration d'infrastructure de plate-forme. Après la migration, certains services d'application ont continué à utiliser les ports de connexion existants lorsqu'ils communiquent avec des services de plate-forme partagée. Lorsque les services touchés ont redémarré, ils ont tenté de communiquer en utilisant des combinaisons de terminaux et de ports qui n'étaient plus alignés sur la configuration mise à jour de la plate-forme. Cette inadéquation de configuration a entraîné des défaillances de communication intermittentes entre les services d'application et les composantes de la plate-forme partagée, ce qui a entraîné des erreurs d'application face aux clients et des perturbations de service dans plusieurs services Flexera One dans la région APAC. Mesures correctives Les mesures suivantes ont été prises pendant l'intervention : 1. **Incident Enquête ouverte :** Les équipes techniques ont examiné les rapports de défaillances intermittentes affectant plusieurs services Flexera One dans la région APAC et ont évalué l'étendue de l'impact client. 2. **Analyse de la dépendance effectuée :** Les équipes techniques ont examiné les voies de communication entre les applications touchées et les services de plate-forme partagée pour identifier la source des défaillances de connectivité. 3. **Configuration Mismatch identifiée :** L'enquête a permis de déterminer que certains services tentaient de communiquer par l'intermédiaire de ports existants qui n'étaient pas alignés sur la configuration mise à jour de la plate-forme après la migration. 4. ** Configuration de la plate-forme Mise à jour :** Les ports requis ont été ajoutés à la configuration mise à jour de la plate-forme, ce qui a permis de rétablir la connectivité des services touchés. 5. **Validation de la récupération du service:** Les équipes techniques ont validé la fonctionnalité de toutes les applications touchées et ont confirmé que la communication de service et la fonctionnalité orientée vers le client étaient de retour à la normale. Mesures préventives futures Les améliorations suivantes ont été identifiées pour réduire davantage le risque d'incidents similaires à l'avenir : 1. **Validation de compatibilité de la migration:** Examiner et renforcer les processus de validation des changements d'infrastructure et des migrations de plate-forme pour aider à identifier les erreurs de configuration de service avant le déploiement, en réduisant le risque de problèmes de connectivité causés par les anciennes configurations de terminaux ou de ports.

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

1. 27 juillet 2026 à 00:11 UTCinvestigating

   Description de l'incident: Nous enquêtons sur un problème touchant les clients d'Atlas des neiges dans la région de l'APAC. Les utilisateurs touchés peuvent être incapables d'accéder à la plate-forme et peuvent rencontrer 404 erreurs lorsqu'ils tentent de se connecter. L'enquête en cours indique que la question est limitée à la région de l'APAC, et aucun impact n'a été confirmé dans d'autres régions à l'heure actuelle. Priorité: P1 Activité de restauration : Nos équipes techniques étudient activement la question pour identifier la cause sous-jacente et rétablir le service. Nous surveillons l'environnement de près et mettons en oeuvre des mesures correctives, selon qu'il convient. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 27 juillet 2026 à 02:00 UTCinvestigating

   Nos équipes ont résolu le problème touchant les clients d'Atlas des neiges dans la région APAC. Le problème s'est posé lorsqu'un service de plate-forme n'a pas démarré correctement, entraînant des erreurs intermittentes et des problèmes d'accès pour certains clients. Les équipes techniques ont identifié la défaillance sous-jacente du démarrage et ont rétabli le service en redémarrant les composants de la plateforme affectée. Les activités de validation ont confirmé le succès de l'accès à la plateforme, et nous n'observons aucun impact client en cours à l'heure actuelle. Nos équipes continueront de surveiller de près l'environnement afin d'assurer une stabilité continue.

3. 27 juillet 2026 à 02:00 UTCresolved

   Cet incident a été résolu.

4. 7 août 2026 à 08:40 UTCpostmortem

   **Description:** Snow Atlas - APAC - Login Failures and 404 Errors **Timeframe:** July 26, 2026, 5:00 PM PDT to July 26, 2026, 6:15 PM PDT ‌ **Incident Summary** ‌ On Sunday, 26 July 2026, Flexera experienced a service disruption affecting Snow Atlas customers in the APAC Production environment, resulting in login failures and temporary inability to access Agreement pages. The issue was isolated to the APAc region, with no impact to other production regions. Investigation by our technical teams determined that the disruption was caused by a backend service communication issue that prevented Agreement data from being retrieved successfully. The condition was consistent with a runtime synchronization issue following recent platform infrastructure maintenance. Flexera teams validated platform health, restored the affected services, and confirmed successful recovery. Customer access was fully restored, and post-recovery monitoring confirmed stable operations with no recurrence of the underlying service communication errors. A detailed post-incident review was completed, and corrective measures have been implemented to further strengthen platform resilience and recovery processes. ‌ **Root Cause** ‌ The incident was caused by an application communication failure within the APAC Production environment. A component responsible for processing requests between internal application services did not successfully handle Agreement-related requests, preventing those requests from being completed and resulting in customer-facing 404 errors and failures accessing Agreement pages. ‌ **Contributing Factors** ‌ * The application communication failure occurred following a recent infrastructure upgrade to the APAC Production environment. * Although the application services and underlying infrastructure remained healthy, an internal service responsible for processing Agreement requests did not fully recover after the upgrade. * Existing health checks validated application and infrastructure availability but did not verify the successful initialization of the internal communication path following the upgrade. * The issue was therefore not detected until customers began experiencing login failures and HTTP 404 errors when accessing Agreement pages. ‌ **Remediation Actions** ‌ To restore service, technical teams: * Confirmed the underlying infrastructure remained healthy throughout the incident. * Identified the failed internal service communication affecting Agreement requests. * Restarted the affected application services. * Validated successful recovery across impacted tenants. * Continued monitoring to confirm service stability. ‌ **Future Preventative Measures** ‌ * Enhanced Post-Upgrade Validation: Introduce additional validation checks following infrastructure upgrades to verify that critical application components and internal service communications are functioning as expected. * Improved Monitoring and Alerting: Enhance monitoring and alerting to detect internal service communication failures and responder registration issues more quickly. * Synthetic Health Checks: Implement synthetic health checks that validate critical customer workflows, including Agreement page functionality, following infrastructure changes.

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

1. 22 juillet 2026 à 10:33 UTCinvestigating

   Description de l'incident: Nous enquêtons sur un problème affectant la visibilité informatique dans la région d'Europe où plusieurs rapports Power BI ne sont pas en charge. Les clients de la région touchée peuvent ne pas être en mesure de consulter les rapports touchés dans l'application. L'enquête en cours indique que la question est limitée à la région de l'Europe, sans impact observé dans d'autres régions à l'heure actuelle. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement la question pour identifier la cause sous-jacente et restaurer la fonctionnalité du rapport. Nous continuons d'évaluer l'ampleur de l'impact, de surveiller la santé des services et de mettre en oeuvre des mesures correctives au besoin. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 22 juillet 2026 à 11:53 UTCidentified

   Notre enquête a permis d'identifier un problème potentiel lié à la configuration dans l'environnement touché. Dans le cadre de nos efforts de validation, des mesures correctives ont été appliquées à un sous-ensemble d'organisations touchées, et les rapports sont maintenant chargés avec succès. Nos équipes se concentrent actuellement sur la mise en oeuvre d'un assainissement plus large dans toutes les organisations touchées et effectuent un examen détaillé pour comprendre pourquoi les changements de configuration ne se propagent pas comme prévu. Nous continuons de valider l'assainissement et de surveiller de près le rendement du service tout en travaillant à la résolution complète.

3. 22 juillet 2026 à 13:43 UTCidentified

   Des mesures correctives ont maintenant été appliquées à un plus grand nombre d'organisations touchées, et la validation initiale indique que les rapports sont chargés avec succès. Nous validons actuellement toutes les organisations concernées pour confirmer que la fonctionnalité du rapport et la performance du service ont été entièrement rétablies. Parallèlement, les équipes continuent de mettre en œuvre des mesures d'assainissement plus larges dans l'ensemble de l'environnement et surveillent de près le service afin d'assurer la stabilité tout en continuant de travailler à la résolution intégrale.

4. 23 juillet 2026 à 04:39 UTCidentified

   Nos équipes ont appliqué la correction à toutes les organisations identifiées. La validation initiale indique que les organisations touchées se rétablissent comme prévu. Les équipes techniques continuent de valider l'efficacité de l'assainissement dans toute la région de l'Europe pour confirmer que le service a été entièrement rétabli. Nous surveillons de près les performances de la plateforme et fournirons une nouvelle mise à jour une fois la validation régionale terminée.

5. 23 juillet 2026 à 07:52 UTCresolved

   Une enquête plus approfondie a révélé qu'un problème de synchronisation était la cause sous-jacente de l'incident. Nos équipes techniques ont mis en œuvre des mesures d'assainissement ciblées, y compris des redémarrages de service, pour rétablir des opérations normales. À la suite d'une surveillance prolongée et d'une validation après l'assainissement, le rendement des services est demeuré stable, et nous avons confirmé que tous les services touchés sont revenus à la normale. La question est maintenant considérée comme résolue.

6. 3 août 2026 à 18:37 UTCpostmortem

   **Description:** Flexera One – Visibilité informatique – UE – Non-chargement des rapports **Calendrier:** 22 juillet 2026, 3h11 PDT – 22 juillet 2026, 23h04 PDT **Résumé de l'incident** Le 22 juillet 2026, vers 3h11, un problème a commencé à affecter la fonctionnalité de rapport de visibilité informatique dans l'environnement de production de Flexera One EU. Au cours de la période concernée, les clients de la région de l'UE ont connu des défaillances lorsqu'ils ont tenté de charger des rapports de visibilité informatique et des tableaux de bord, y compris l'inventaire des logiciels, l'inventaire des matériels, l'intelligence technologique \(TI\), la durabilité et les rapports FinOps. Les équipes techniques ont commencé à enquêter après la réception de plusieurs rapports de clients concernant des défaillances de chargement dans toute la région de l'UE. L'analyse initiale a confirmé que la question se limitait à l'environnement de production de l'UE, tandis que la fonctionnalité de déclaration équivalente dans d'autres régions continuait à fonctionner normalement. L'enquête a permis de déterminer qu'un problème d'authentification s'était produit dans l'environnement de déclaration de l'UE. En conséquence, les rapports et les tableaux de bord touchés n'ont pas pu récupérer les données nécessaires pour charger avec succès, ce qui a causé des défaillances de chargement des rapports pour les clients touchés. Les équipes techniques ont mis en oeuvre des mises à jour correctives dans l'environnement de rapport touché et ont effectué des activités de validation dans les organisations clientes touchées. À la suite de ces actions, les rapports et les tableaux de bord ont repris leurs activités normales et les clients ont de nouveau pu accéder avec succès aux données de déclaration. Après validation des environnements clients touchés et confirmation que les rapports étaient chargés avec succès, la fonctionnalité de service a été rétablie et l'incident a été considéré résolu. Les équipes techniques ont poursuivi la surveillance après la restauration afin d'assurer la stabilité du service. ** Cause de la mort** L'incident a été causé par un problème d'authentification dans l'environnement de déclaration de l'UE. Ce problème a empêché les rapports et les tableaux de bord touchés de récupérer avec succès les données requises pour afficher les résultats, ce qui a entraîné des défaillances du chargement des rapports pour les clients touchés. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : 1. Évaluation d ' impact régionale: les équipes techniques ont examiné les rapports des clients et confirmé que la question était isolée de l ' environnement de production de l ' UE. Des validations supplémentaires ont été effectuées dans d'autres régions pour vérifier que la fonctionnalité de déclaration demeurait opérationnelle en dehors de l'environnement touché. 2. Analyse des défaillances d'authentification: Les équipes techniques ont examiné le traitement des rapports, les flux de travail d'authentification, les espaces de travail de rapport et les changements récents de plate-forme pour identifier la source des défaillances. L'enquête a permis de déterminer que les rapports touchés n'étaient pas en mesure d'authentifier avec succès les données sous-jacentes requises pour l'établissement des rapports. 3. Activités de restauration et de validation: Les équipes techniques ont appliqué des mises à jour dans les environnements clients touchés et des espaces de travail de rapport pour restaurer la récupération réussie des données de rapport. Après la mise en œuvre, les organisations clientes touchées ont été validées pour confirmer les rapports et les tableaux de bord ont été chargés avec succès et ont affiché les données comme prévu. 4. Vérification après le rétablissement: Après la restauration, des activités supplémentaires de surveillance et de validation ont été menées pour vérifier la fonctionnalité continue du rapport, confirmer la récupération réussie et assurer la stabilité des services dans l'ensemble de l'environnement de production de l'UE. ** Mesures préventives à venir** Les mesures de suivi suivantes ont été identifiées au cours de l'incident : • Examen du processus de mise à jour de l'authentification: les équipes techniques examinent le processus de mise à jour de l'authentification pour comprendre pourquoi la mise à jour n'a pas été appliquée avec succès dans tous les espaces de travail touchés dans l'environnement de production de l'UE et pour identifier les améliorations qui aideront à prévenir des problèmes similaires dans les futures mises à jour.

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

1. 22 juillet 2026 à 08:25 UTCidentified

   Description de l'incident: Nous avons identifié un problème affectant le traitement des stocks dans Flexera One IT Asset Management suite au déploiement de la version 2026 R1.1 dans notre environnement de production américain. Par conséquent, certains clients peuvent éprouver des problèmes de performance et de fiabilité intermittents lors de l'accès à certains domaines de l'interface utilisateur et de l'exécution de tâches liées au système. Priorité : P2 Activité de restauration : Notre enquête a déterminé que la question est liée à un défaut logiciel introduit avec la version 2026 R1.1. Bien que le défaut ait déjà été identifié et que des procédures d'atténuation aient été intégrées au processus de déploiement, l'assainissement automatisé a rencontré des problèmes d'exécution imprévus. En conséquence, les équipes techniques ont mis en œuvre d'autres mesures d'atténuation pour réduire l'impact du client et stabiliser les performances du système. Nous continuons de surveiller activement l'environnement et d'appliquer des mesures correctives pour corriger le défaut sous-jacent et rétablir l'exploitation normale du service.

2. 22 juillet 2026 à 13:38 UTCidentified

   Nos équipes continuent de travailler à la mise en œuvre d'un correctif pour résoudre le problème. Pendant le déploiement, le hotfix a rencontré des conditions de base de données qui l'empêchent de terminer avec succès. Nos équipes techniques s'emploient activement à résoudre ce problème et évaluent les mesures d'atténuation ciblées pour permettre au hotfix de s'achever. Une fois que le hotfix a été appliqué avec succès, les équipes valideront la performance du service et continueront à surveiller pour confirmer la récupération. Nous fournirons une autre mise à jour à mesure que de plus amples renseignements seront disponibles.

3. 22 juillet 2026 à 15:40 UTCmonitoring

   Le hotfix a été déployé avec succès, et les équipes d'ingénierie valident actuellement son efficacité. Les équipes continuent de surveiller le comportement des plates-formes et d'examiner la télémétrie pour confirmer la résolution du problème.

4. 22 juillet 2026 à 16:16 UTCresolved

   Nos équipes ont terminé la validation après le déploiement et ont confirmé que le rendement des services était revenu aux niveaux prévus. La surveillance continue a montré un fonctionnement stable de la plate-forme sans autre impact observé. Sur la base de ces résultats, cette question est maintenant considérée comme résolue.

5. 4 août 2026 à 20:57 UTCpostmortem

   **Description:** Flexera One – IT Asset Management – North America – Degraded Performance **Timeframe:** July 20, 2026, 8:13 PM PDT – July 22, 2026, 8:41 AM PDT ‌ **Incident Summary** On July 20, 2026, at approximately 8:13 PM PDT, an issue began affecting Flexera One IT Asset Management customers in the North America production environment following completion of the production release. During the affected period, some customers experienced intermittent application slowness, delayed processing, reconcile failures, timeout conditions, and degraded performance across inventory-related workflows. Technical teams investigated performance and reliability issues observed following the release and worked to determine the underlying cause and scope of impact. The investigation determined that the observed behavior was associated with a defect previously identified in the release. Corrective changes intended to address the defect were included as part of the release activity; however, the corrective changes did not successfully apply across all North America production databases during the deployment process. As a result, some environments continued to experience significantly increased database processing activity during inventory-related operations, contributing to elevated resource consumption, processing delays, timeout conditions, and degraded application performance. Technical teams worked to successfully deploy the corrective changes across the affected North America production databases. Following deployment, teams performed validation activities and monitored processing workflows to confirm recovery. By July 22, 2026, at approximately 8:41 AM PDT, validation confirmed successful processing of previously impacted workloads and that the previously observed failure patterns were no longer occurring. The incident was considered resolved and technical teams continued monitoring to confirm service stability. ‌ **Root Cause** The incident was caused by corrective changes intended to address a previously identified defect not successfully applying across all North America production databases during the release deployment process. As a result, the underlying defect remained active in affected environments and caused significantly more database processing activity than intended during inventory-related processing operations. This increased workload resulted in elevated resource consumption, processing delays, timeout conditions, and degraded platform performance. These conditions contributed to intermittent application slowness, delayed processing, reconcile failures, and degraded performance affecting some IT Asset Management functionality within the North America production environment. ‌ **Remediation Actions** 1. **Incident Investigation Initiated:** Technical teams investigated reports of application slowness, processing delays, reconcile failures, and degraded platform performance affecting the North America production environment. 2. **Impact Assessment Performed:** Teams reviewed customer-reported symptoms, system performance data, processing activity, and platform behavior to determine the scope and nature of the issue. 3. **Cause Identified:** Investigation determined that corrective changes intended to address a previously identified defect did not successfully apply across all North America production databases during the release deployment process. 4. **Processing Behavior Corrected:** Technical teams deployed corrections designed to eliminate the inefficient processing behavior that was contributing to elevated database workload, processing delays, timeout conditions, and degraded application performance. 5. **Recovery Validated:** Teams validated the effectiveness of the deployed changes through monitoring and successful execution of previously impacted processing activities. 6. **Post-Restoration Monitoring Performed:** Additional monitoring confirmed that the previously observed failure patterns and performance degradation were no longer occurring and that service stability had been restored. ‌ **Future Preventative Measures** Based on the investigation, the following follow-up activities have been identified: * **Processing Logic Improvements:** Technical teams implemented and validated corrective changes to the inventory-processing logic responsible for the increased database workload observed following the release. These changes were designed to eliminate the inefficient processing behavior that contributed to processing delays, reconcile failures, timeout conditions, and degraded application performance. * **Critical Hotfix Deployment Process Review:** Technical teams will review the deployment process for critical database hotfixes and evaluate alternative approaches to help ensure required corrective changes are successfully applied during future release activities.

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

1. 17 juillet 2026 à 10:24 UTCinvestigating

   Description de l'incident : Nous avons identifié un problème qui a une incidence sur la facturation et la visibilité des coûts pour les clients des SSFE dans toutes les régions. En raison d'une perturbation active du fournisseur de services, les clients peuvent observer des renseignements inexacts, incomplets ou retardés sur les coûts estimatifs et l'utilisation dans la console de facturation et de gestion des coûts. Ce problème se limite aux services basés sur AWS et n'affecte pas les clients qui utilisent d'autres plateformes cloud. Priorité : P2 Activité de restauration : Nos équipes techniques ont confirmé que le problème est lié à un événement de service actif du SSFE touchant toutes les régions. Nous surveillons activement la situation et travaillons en étroite collaboration avec les mises à jour AWS pour évaluer l'impact client. La restauration du service dépend de la résolution du problème sous-jacent par les SSFE, et nous continuerons de fournir des mises à jour au fur et à mesure que des renseignements supplémentaires seront disponibles.

2. 17 juillet 2026 à 10:27 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 17 juillet 2026 à 13:14 UTCidentified

   Nous continuons de surveiller de près la panne des fournisseurs de services et son incidence sur les services touchés. D'autres mises à jour seront fournies à mesure que de nouvelles informations seront disponibles.

4. 17 juillet 2026 à 18:24 UTCidentified

   À ce jour, nos efforts d'enquête et de validation n'ont révélé aucune incidence sur les données de facturation ou d'analyse des coûts. Les données de facturation et de prix examinées demeurent conformes aux valeurs prévues. Bien que les résultats initiaux de validation soient positifs, nous poursuivons d'autres activités de validation à mesure que d'autres données seront disponibles pour confirmer ces constatations. Nous demeurons en contact avec l'AWS et continuerons de surveiller la situation de près. Nous partagerons d'autres mises à jour à mesure que nos activités de validation se poursuivront.

5. 18 juillet 2026 à 08:05 UTCidentified

   Nous demeurons actifs avec le SGA et continuons de suivre de près la situation. Le SSFE a déterminé la cause fondamentale et mis en oeuvre des mesures d'atténuation pour régler le problème sous-jacent qui a entraîné l'affichage de données sur les coûts et l'utilisation inexactes. AWS a commencé à remblayer les données pour restaurer des informations précises sur les coûts et l'utilisation pour tous les clients et la récupération complète est attendue d'ici le 18 juillet 2026, 12h00 PDT.

6. 18 juillet 2026 à 19:33 UTCmonitoring

   Nous continuons de surveiller l'événement de service AWS et de rester en contact avec AWS alors qu'ils terminent leurs activités de rétablissement. La validation effectuée à ce jour n'a révélé aucune incidence sur les données de facturation ou d'analyse des coûts. Nous continuons de surveiller la situation et de mener à bien les activités de validation restantes avant de déterminer la clôture de cet incident.

7. 19 juillet 2026 à 12:59 UTCresolved

   AWS a résolu leur interruption de service le 18 juillet à 6h57 PDT. Après une validation réussie par nos équipes techniques, nous avons confirmé que la fonctionnalité de service a été rétablie.

8. 30 juillet 2026 à 18:10 UTCpostmortem

   **Description:** Spot Flexera – Perturbation du service de facturation AWS Calendrier: 17 juillet 2026, 1:33 PDT – 18 juillet 2026, 6:57 PDT **Résumé de l'incident** Le 17 juillet 2026, vers 1:33 AM PDT, les équipes techniques de Flexera ont pris connaissance d'un problème concernant la facturation estimative et les données d'utilisation affichées dans les rapports sur la facturation et la gestion des coûts, l'explorateur des coûts et les rapports sur les coûts et l'utilisation. Compte tenu de la nature de la perturbation du service SSFE, les équipes techniques ont entrepris une enquête afin de déterminer si la facturation, l'analyse des coûts ou les calculs d'économie des clients SSFE étaient touchés. Au cours de l'enquête, les équipes ont examiné les données de facturation et de prix utilisées par Spot, validé les tableaux de coûts et de prix pertinents, surveillé les mises à jour du SSFE et évalué si des données de facturation ou d'économies avaient été touchées par les clients. Les équipes techniques ont validé les données de facturation et de tarification utilisées par Spot et confirmé que les tableaux de coûts et de tarification pertinents fonctionnaient comme prévu. L'enquête n'a relevé aucun problème dans les données utilisées par Spot, et aucun calcul de facturation ou d'économie incorrect n'a été observé. Par la suite, le SSFE a confirmé que le problème provenait des services de facturation et de gestion des coûts du SSFE, a identifié et atténué le problème sous-jacent et a complété les activités de récupération et de remblayage des données. D'après la validation effectuée tout au long de l'enquête, aucun impact client n'a été observé chez Spot. À la suite de la confirmation du rétablissement du SGA et de l'achèvement des activités de validation après le rétablissement, l'incident a été considéré résolu. ** Cause de la mort** L'incident a été causé par un problème de service du SSFE affectant les données estimatives de facturation et d'utilisation affichées dans les rapports de facturation et de gestion des coûts du SSFE, de l'Explorateur des coûts et des coûts et d'utilisation. Les SSFE ont identifié et atténué le problème sous-jacent et achevé les activités de récupération des données. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : • Incident Investigation Initiated: Les équipes techniques ont commencé à enquêter sur la question de la facturation et de l'utilisation des données AWS pour déterminer si les clients de Spot ont été touchés. • Analyse d'impact réalisée: Les équipes techniques ont évalué si la perturbation du service AWS avait affecté l'analyse de facturation Spot et les calculs d'économies. • Validation des données terminée : Les équipes ont examiné et validé les données de facturation et de tarification utilisées par Spot et ont confirmé que les tableaux de coûts et de tarification pertinents fonctionnaient comme prévu. • AWS Recovery Monitored: Les équipes techniques ont surveillé les communications, les mises à jour de service et les activités de rétablissement tout au long de l'incident. • Validation post-récupération effectuée : Une validation supplémentaire a été effectuée à la suite des activités de récupération AWS et de remplissage des données afin de confirmer l'intégrité des données de facturation et de tarification utilisées par Spot. • Incident résolu: L'incident a été fermé après la récupération confirmée de l'AWS et la validation technique n'a révélé aucun impact dans Spot. ** Mesures préventives à venir** Les mesures de suivi suivantes ont été identifiées au cours de l'incident : • Collaboration et examen des SSFE : Continuer de travailler en étroite collaboration avec les SSFE pour comprendre la cause sous-jacente des incidents gérés par les fournisseurs et examiner les recommandations ou les enseignements découlant de leur enquête. • Examen de la résilience et de la validation : Examiner les possibilités de renforcer encore les processus de validation des données relatives à la facturation afin d'accélérer l'évaluation de l'impact et l'intervention lors de perturbations de services similaires à l'avenir.

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

1. 17 juillet 2026 à 08:24 UTCidentified

   Description de l'incident: Nous avons identifié un problème touchant le traitement des stocks dans Flexera One IT Asset Management suite au déploiement de la version 2026 R1.1 dans nos environnements APAC et Europe. Par conséquent, un sous-ensemble de clients peut connaître des performances dégradées lorsqu'ils accèdent à certaines zones de l'interface utilisateur et qu'ils exécutent des tâches liées au système. Priorité : P2 Activité de restauration: Nos équipes techniques ont identifié le problème comme un défaut logiciel introduit avec la version 2026 R1.1. Des mesures d'atténuation ont été mises en place pour réduire l'impact des clients, et les équipes s'emploient activement à rétablir pleinement le rendement des services. Nous continuerons de fournir des mises à jour au fur et à mesure des progrès réalisés.

2. 17 juillet 2026 à 15:58 UTCidentified

   Nous continuons de progresser dans le traitement des problèmes de performance touchant un sous-ensemble de clients dans les environnements de production APAC et Europe. Les correctifs identifiés ont maintenant été déployés et nous surveillons activement l'environnement à mesure que les activités de traitement des clients se poursuivent. Nos équipes valident l'efficacité de ces changements et évaluent la performance globale de la plateforme. Nous fournirons des mises à jour supplémentaires à mesure que de plus amples renseignements seront disponibles.

3. 18 juillet 2026 à 08:10 UTCmonitoring

   Nos équipes continuent de valider les hotfixs récemment déployés, et les premiers résultats semblent positifs. Nous surveillons de près les activités de traitement concernées pour confirmer l'efficacité de la solution et assurer la stabilité de la plate-forme. La validation est en cours et nous continuerons de surveiller le rendement avant de confirmer la résolution complète. Nous fournirons une autre mise à jour à mesure que de plus amples renseignements seront disponibles.

4. 18 juillet 2026 à 19:29 UTCresolved

   Après le déploiement des correctifs identifiés, les activités de traitement précédemment touchées se terminent maintenant avec succès, et nous ne voyons plus la récurrence des problèmes observés après la publication récente. Selon les résultats observés après le déploiement des correctifs, cet incident est maintenant résolu. Nous publierons dans les prochains jours une ACR complète qui comprendra un résumé détaillé de la question, des causes profondes et des mesures préventives mises en oeuvre pour aider à prévenir les récidives.

5. 30 juillet 2026 à 17:47 UTCpostmortem

   **Description:** Flexera One – Gestion d'actifs informatiques – APAC et UE – Lenteur et performance dégradée **Calendrier:** 13 juillet 2026, 13h00 PDT – 18 juillet 2026, 7h10 PDT **Résumé de l'incident** Le 13 juillet 2026, vers 13h00 PDT, un problème a commencé à toucher les clients de Flexera One IT Asset Management dans les environnements de production APAC et Europe après le déploiement de la version 2026 R1.1. Au cours de la période visée, certains clients ont connu une lenteur intermittente de l'application, un retard dans le traitement, un rapprochement des défaillances et une dégradation des performances lorsqu'ils ont accédé à certains secteurs de l'application ou qu'ils ont effectué des activités liées à l'inventaire. À mesure que les rapports des clients augmentent, les équipes techniques commencent à étudier les tendances communes à tous les symptômes signalés pour déterminer la cause sous-jacente. L'enquête a identifié un défaut introduit dans le cadre de la publication Flexera One IT Asset Management 2026 R1.1. Dans certaines conditions, le défaut a entraîné une activité de traitement des bases de données beaucoup plus importante durant les opérations liées aux stocks. Au fur et à mesure du traitement des données d'inventaire, l'augmentation de la charge de travail a contribué aux retards de traitement, aux délais d'exécution et à la dégradation des performances de certains clients. Les équipes techniques ont mis au point et déployé des correctifs pour régler le problème dans les environnements de production touchés. Après le déploiement, les équipes ont effectué des activités de validation et surveillé les flux de travail de traitement touchés pour confirmer la récupération. Le 18 juillet 2026, vers 7 h 10 HAP, la validation a confirmé la réussite du traitement des charges de travail précédemment touchées et l'absence des profils de défaillance associés au problème. L'incident a été considéré résolu et les équipes techniques ont continué de surveiller pour confirmer la stabilité du service. ** Cause de la mort** L'incident a été causé par un défaut introduit dans la version de Flexera One IT Asset Management 2026 R1.1 concernant les opérations de traitement des stocks. Dans certaines conditions, le défaut a causé beaucoup plus d'activités de traitement des bases de données que prévu lors des opérations de traitement liées aux stocks. Cette charge de travail accrue a entraîné une augmentation de la consommation de ressources, des délais de traitement et des délais d'attente. Ces conditions ont contribué à la lenteur intermittente de l'application, au retard du traitement, au rapprochement des défaillances et à la dégradation des performances affectant certaines fonctionnalités de gestion des actifs informatiques. **Mesures correctives** 1. Initiation de l'enquête sur les incidents: Les équipes techniques ont commencé à enquêter sur les rapports de lenteur de l'application, les retards de traitement et les problèmes de fiabilité touchant les environnements de production APAC et Europe. 2. Évaluation d'impact effectuée: Les équipes ont examiné les symptômes signalés par les clients, les données sur le rendement du système et le comportement de traitement afin de déterminer la portée et la nature du problème. 3. Cause identifiée : L'enquête a permis de déterminer qu'un défaut introduit dans le rejet R1.1 en 2026 générait une activité de transformation excessive pendant les opérations liées à l'inventaire. 4. Hotfixes développés et déployés: Des équipes techniques ont développé et déployé des hotfixes pour corriger le comportement de traitement affecté dans les environnements de production APAC et Europe. 5. Validation de la récupération: Les équipes ont validé l'efficacité des correctifs à chaud par la surveillance et l'exécution réussie des activités de traitement précédemment touchées. 6. Surveillance après le rétablissement: Une surveillance supplémentaire a confirmé que les défaillances et la dégradation des performances précédemment observées n ' avaient plus lieu et que la stabilité du service avait été rétablie. ** Mesures préventives à venir** D'après l'enquête, les activités de suivi suivantes ont été identifiées : • Améliorations de la logique de traitement : les équipes techniques ont apporté des corrections à la logique de traitement affectée afin d'éliminer le comportement inefficace qui a contribué à accroître la consommation de ressources et la dégradation des performances.

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

1. 14 juillet 2026 à 09:13 UTCresolved

   Description de l'incident:Nos équipes ont identifié un problème affectant Cognos Analytics dans l'environnement de production de l'UE. Pendant la fenêtre d'impact, les clients touchés peuvent avoir été incapables d'accéder ou de charger Cognos Analytics. L'enquête en cours a confirmé que l'impact était limité à la région de production de l'UE. Priorité:P2 Activité de restauration: Nos équipes techniques ont déterminé que la question était liée à une récente mise à niveau de Cognos Analytics , qui a été achevée dans le cadre des activités de l'UE Production IT Asset Management. L'équipe a identifié un problème de configuration introduit lors de la mise à niveau, a mis en œuvre les corrections de configuration nécessaires et a rétabli la fonctionnalité de service normale. L'environnement reste stable sous surveillance. D'autres détails, y compris la cause profonde et les mesures préventives, seront communiqués dans un rapport post mortem.

2. 26 juillet 2026 à 07:06 UTCpostmortem

   **Description:** Flexera One - IT Asset Management - EU - problème d'accès analytique à Congnos **Calendrier:** 13 juillet 2026, 12:51 PDT au 14 juillet 2026, 1:52 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le lundi 13 juillet, 2026, à 12:51 PDT, Suite à la mise à niveau Cognos Analytics 12.1.2 mise en œuvre dans le cadre de la version Flexera One IT Asset Management dans l'environnement de production Europe \(EU\), nos équipes ont identifié un problème qui a empêché les clients d'accéder à Cognos Analytics. Par conséquent, les utilisateurs touchés n'ont pas pu lancer l'application avec succès une fois les activités de maintenance prévues terminées. Les équipes techniques ont immédiatement ouvert une enquête et confirmé que la question était isolée de l'environnement de production de l'UE, sans impact observé dans aucune autre région de production. Une analyse plus approfondie a permis de déterminer que la mise à niveau elle-même avait été menée à bien; toutefois, une partie des activités de configuration requises après la mise à niveau n'avait pas été entièrement appliquée, empêchant Cognos Analytics de commencer correctement. Les autres tâches de configuration ont été rapidement terminées, rétablissant la fonctionnalité normale de Cognos Analytics. Après une validation complète de l'accès des clients et une période de surveillance accrue, le service a été confirmé fonctionner normalement et l'incident a été déclaré résolu. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) * Configuration post-upgrade incomplète : Bien que la mise à niveau Cognos Analytics 12.1.2 ait été effectuée avec succès, les tâches de configuration post-upgrade requises n'ont pas été entièrement terminées avant que l'environnement ne soit remis en service. * Initialisation du service Défaut : La configuration incomplète a empêché Cognos Analytics d'initialiser correctement, ce qui a empêché les clients d'accéder à l'application. * Impact régional: la question était limitée à l'environnement de production de l'UE. Aucun impact n'a été relevé en Amérique du Nord, en APAC ou dans d'autres régions de production. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) Pour restaurer le service, les équipes techniques : * Achèvement des activités de configuration après la mise à niveau qui n ' avaient pas été pleinement appliquées pendant le déploiement. * Redémarrage et validation des services Cognos Analytics pour confirmer l'initialisation réussie de l'application. * Effectuer des essais fonctionnels et valider l'accès des clients pour vérifier que les capacités de rapport fonctionnaient comme prévu. * Placé l'environnement sous surveillance renforcée après récupération pour assurer la stabilité du service. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) * Validation post-upgrade améliorée : Renforcer les procédures de validation du déploiement pour vérifier que toutes les activités de configuration post-upgrade requises ont été menées à bien avec succès avant de terminer les activités de maintenance. * Amélioration de la surveillance et de l'alerte : améliorer la surveillance et l'alerte Cognos Analytics pour permettre une détection plus précoce de la dégradation du service après des mises à niveau. * Liste de contrôle de déploiement Améliorations : Mettre à jour les listes de déploiement et les listes de contrôle opérationnelles pour y inclure une vérification supplémentaire de l'achèvement de la configuration après la mise à niveau avant de retourner l'environnement au service de production. * Examen de l'état de préparation opérationnelle : Examiner les procédures d'exécution de la mise à niveau pour s'assurer que toutes les tâches obligatoires après le déploiement sont terminées et validées avant la fermeture des fenêtres d'entretien.

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

1. 12 juillet 2026 à 23:51 UTCinvestigating

   Description de l'incident: Nous rencontrons un problème touchant les clients de Flexera One IT Asset Management (ITAM) dans la région APAC. Les clients peuvent remarquer que certains éléments de navigation et de menu dans l'interface ITAM ne sont pas visibles, ce qui réduit l'accès à certaines fonctionnalités. Priorité : P2 Activité de restauration : Nos équipes techniques étudient activement cette question et s'emploient à restaurer la fonctionnalité complète. Nous continuerons de fournir des mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 13 juillet 2026 à 00:28 UTCidentified

   Notre enquête a mis en évidence une utilisation accrue des ressources qui affecte la fonctionnalité associée au problème signalé. Des mesures d'atténuation sont en cours, y compris l'accroissement de la capacité du système à appuyer les efforts de rétablissement. Nous surveillons activement le comportement de l'environnement et de la plateforme de validation au fur et à mesure que ces changements sont mis en œuvre. Des travaux sont en cours pour restaurer la fonctionnalité complète des clients touchés, et nous partagerons des mises à jour supplémentaires au fur et à mesure des progrès réalisés.

3. 13 juillet 2026 à 01:52 UTCidentified

   Notre enquête a permis d'identifier un problème potentiel de configuration associé à la fonctionnalité touchée. Dans le cadre des efforts d'atténuation en cours, les changements de configuration ont été repris et les augmentations de capacité déjà amorcées sont maintenant terminées. Nous surveillons activement l'environnement et valideons le comportement de la plate-forme à mesure que ces changements prennent effet. Les travaux se poursuivent pour rétablir la fonctionnalité complète des clients touchés, et nous fournirons d'autres mises à jour au fur et à mesure des progrès réalisés.

4. 13 juillet 2026 à 03:44 UTCresolved

   Après une surveillance prolongée, nous avons confirmé que le rendement du service est demeuré stable et fonctionne comme prévu. Cette question est maintenant résolue.

5. 12 août 2026 à 05:15 UTCpostmortem

   **Description:** Flexera One - Gestion des biens informatiques - APAC - Éléments de menu manquants **Calendrier:** 12 juillet 2026, 15:00 PDT - 12 juillet 2026, 19:16 PDT **Résumé de l'incident** Le dimanche 12 juillet 2026, à 15h00 PDT, les clients de l'environnement de production APAC ont commencé à signaler que plusieurs éléments du menu Gestion d'actifs informatiques \(ITAM\), y compris des fonctionnalités telles que Reports et All Applications, n'étaient plus visibles dans l'interface utilisateur Flexera One. Plusieurs clients ont été touchés, ce qui a eu une incidence sur leur capacité de naviguer et d'accéder aux parties de l'application ITAM. Les équipes techniques ont immédiatement commencé à enquêter sur le problème et ont identifié des erreurs liées à l'authentification affectant l'interface utilisateur ITAM. Au cours de l'enquête, les équipes ont examiné la santé de l'infrastructure, le comportement des applications et les changements récents de plateforme pour déterminer la source du problème. L'enquête a déterminé qu'un changement de configuration d'application associé à une nouvelle capacité d'authentification avait été appliqué incorrectement à l'environnement de production. Le problème est devenu évident lorsque les instances d'application ont été rafraîchies, ce qui a entraîné des défaillances liées à l'authentification qui ont empêché certains éléments de menu ITAM de charger correctement pour les utilisateurs touchés. Les équipes techniques ont retourné la configuration touchée, rafraîchi les instances d'application touchées et validé la récupération dans l'environnement. À la suite de ces mesures, la fonctionnalité du menu a été rétablie, les clients ont été rétablis et l'incident a été réglé le 12 juillet 2026 à 19 h 16 HAP après que la validation et la surveillance ont confirmé l'opération normale. ** Cause de la mort** L'enquête a déterminé qu'un changement de configuration de l'application associé à une nouvelle capacité d'authentification a été incorrectement appliqué à l'environnement de production. Lorsque les instances d'application ont par la suite été mises à jour, la configuration incorrecte a entraîné des erreurs liées à l'authentification dans l'interface utilisateur ITAM. Ces erreurs ont empêché certains composants de navigation de se charger correctement, ce qui a amené les utilisateurs touchés à découvrir des éléments de menu manquants jusqu'à ce que la configuration soit corrigée et que les instances concernées soient rafraîchies. **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : 1. Incident Investigation Initiated: Les équipes techniques ont commencé à enquêter après avoir reçu des rapports de plusieurs clients concernant des éléments de menu ITAM manquants. 2. Configuration de l'application examinée : Les modifications récentes de l'application et de la configuration ont été examinées pour déterminer la source des pannes de chargement de menus. 3. Configuration incorrecte identifiée: Les équipes techniques ont déterminé qu'un changement de configuration lié à l'authentification avait été incorrectement appliqué à l'environnement de production. 4. Configuration corrigée : La configuration affectée a été retirée des instances de production touchées. 5. Instances d'application Rafraîchies : Les instances d'application impactées ont été rafraîchies pour s'assurer que la configuration corrigée a été appliquée de façon uniforme dans l'environnement. 6. Validation de la récupération effectuée: Les équipes techniques ont validé la visibilité et la fonctionnalité du menu dans l'environnement touché et confirmé la récupération avec les clients touchés. ** Mesures préventives à venir** À la suite de l'incident, des mesures correctives ont été mises en place pour prévenir la réapparition du problème et améliorer la détection de conditions semblables à l'avenir. 1. Validation du contrôle de configuration: La configuration incorrecte liée à l'authentification a été retirée des environnements où elle n'était pas destinée à être déployée. Ce changement empêche l'introduction future du même problème de configuration dans les environnements touchés. 2. Améliorations de la surveillance des contrôles de santé : Le contrôle sanitaire existant a été mis à jour pour détecter le comportement d'application associé à cette condition de défaillance. La surveillance révisée vise à identifier plus efficacement des défaillances similaires liées au chargement de menus et à l'authentification des applications et à accélérer la détection si un problème similaire se présente à l'avenir.

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

1. 6 juillet 2026 à 14:19 UTCinvestigating

   Description de l'incident: Nous étudions actuellement les performances dégradées affectant Spot Ocean ECS pour les clients AWS. Les clients peuvent subir une lenteur ou des retards importants lorsqu'ils accèdent à la console ou utilisent certaines fonctionnalités du système Ocean ECS. Priorité : P2 Activité de restauration : Nos équipes techniques étudient et travaillent activement pour restaurer la fonctionnalité normale. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 6 juillet 2026 à 15:11 UTCmonitoring

   Notre enquête a permis de constater que la dégradation était liée à un événement de santé lié aux SSFE touchant la région de l'est-1. AWS a depuis signalé que le problème a été résolu, et nous voyons maintenant des signes de récupération de notre côté, y compris l'amélioration de la performance de la console Spot Ocean ECS et la réussite des workflows AWS connexes. L'environnement de production semble actuellement stable. Nos équipes continueront de surveiller pendant une courte période de validation pour s'assurer que le rendement demeure stable avant de marquer l'incident résolu.

3. 6 juillet 2026 à 16:57 UTCresolved

   Nous avons continué à surveiller l'environnement pendant une longue période et les services sont demeurés stables, sans que d'autres problèmes soient observés. Cet incident a été résolu.

4. 20 juillet 2026 à 07:00 UTCpostmortem

   **Description:** Océan de l'emplacement – AWS – Dégradation de la performance de la console de l'ECS océanique **Calendrier:** 6 juillet 2026, 05:45 PDT au 6 juillet 2026, 07:53 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le lundi 6 juillet 2026, à 05h45 PDT , nos équipes ont identifié une dégradation des performances affectant Spot Ocean ECS pour les clients AWS. Pendant la fenêtre d'impact, les clients ont éprouvé une latence accrue lorsqu'ils ont accès à la console Ocean ECS, et certaines opérations liées à AWS ont été retardées ou n'ont pas été menées à bien. Les équipes techniques ont immédiatement entrepris une enquête pour déterminer la source du problème. Comme une perturbation du service du SSFE se produisait simultanément dans la région du SSFE-nous-est-1, l'enquête a d'abord considéré l'événement externe du SSFE et le déploiement récent de la production comme des facteurs contributifs potentiels. Par une analyse détaillée, les équipes ont déterminé que la principale cause de l'impact client était l'instabilité introduite par le déploiement récent de Gateway. La dégradation de la performance de Gateway a affecté le traitement des demandes et la réactivité au sein du Spot Ocean ECS. Bien que l'interruption simultanée du service SSFE ait accru la complexité de l'enquête, il a été confirmé qu'elle n'était pas le principal facteur de l'impact sur le client. Pour restaurer le service, les équipes ont repoussé le déploiement vers la version stable précédente. Après le renversement, les performances de la plateforme sont revenues aux niveaux prévus et les flux de travail des clients ont repris leur fonctionnement normal. Une longue période de surveillance a confirmé la stabilité soutenue du service avant que l'événement ne soit officiellement résolu. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) L'incident a été causé par l'instabilité introduite dans un déploiement Gateway . Le déploiement a entraîné une dégradation des performances du service Gateway, ce qui a réduit sa capacité de traiter efficacement les demandes des clients. Cela a entraîné une augmentation des temps de réponse et des défaillances intermittentes pour les opérations de console Spot Ocean ECS et les workflows liés à AWS. Revenir à la précédente version stable Gateway a restauré les performances normales de la plateforme et résolu l'impact client. Facteurs contributifs * Une interruption simultanée du service SSFE dans la région de l'est-1 s'est produite pendant la même période. Bien que ce n'était pas la cause de l'incident, il a compliqué l'enquête initiale et retardé l'identification de la question de Gateway sous-jacente. * En raison de l'ampleur du déploiement de la production, le renversement de la passerelle a nécessité un temps supplémentaire, prolongeant ainsi le processus de récupération global. * Les opérations impliquant la création et la mise à jour de ressources ont eu plus d'impact que les activités en lecture seule en raison de la réactivité dégradée de la passerelle. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) * Les équipes techniques ont étudié la dégradation et ont identifié un récent déploiement de Gateway comme la principale source de la question. * Le déploiement de la passerelle touchée a été ramené à la dernière version stable connue, ce qui a permis de rétablir la stabilité du service. * Les performances de la plate-forme et les flux de travail orientés vers le client ont été validés après le renversement. * Les équipes techniques ont terminé une période de surveillance prolongée pour confirmer la stabilité des opérations de service avant la clôture de l'incident. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) * Amélioration des garanties de déploiement - Les équipes du génie renforceront les contrôles de déploiement et les processus de validation afin de réduire la probabilité de problèmes similaires liés au déploiement touchant les environnements de production. * Surveillance améliorée de la plate-forme - Une surveillance et une alerte supplémentaires seront mises en place pour permettre de détecter plus tôt les comportements anormaux de la passerelle, y compris la réactivité des services, l'utilisation des ressources et la stabilité des applications. * Amélioration des procédures de rétablissement - Les procédures de retour seront améliorées et validées régulièrement pour réduire le temps de rétablissement et améliorer l'efficacité opérationnelle pendant les incidents liés au déploiement. * Validation proactive des services de santé - Les contrôles synthétiques de santé seront élargis pour valider en permanence les flux de travail critiques des utilisateurs du SCE océanique, ce qui permettra d'identifier plus tôt la dégradation des performances du client. * Surveillance accrue de la dépendance - Les équipes d'ingénierie continueront d'améliorer la visibilité des événements de services en nuage externes et des dépendances des plates-formes afin de permettre une différenciation plus rapide entre les questions de plate-forme interne et les perturbations de services de tiers au cours des enquêtes futures.

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

1. 3 juillet 2026 à 19:07 UTCresolved

   Description de l'incident : Nous avons relevé un problème touchant un sous-ensemble de services Flexera One dans la région APAC, ce qui peut avoir entraîné des problèmes d'accès intermittents ou des défaillances pour certains utilisateurs. L'impact a été intermittent et d'autres régions n'ont pas été touchées. Le problème a été résolu et les services touchés fonctionnent normalement. Priorité : P2 Activité de restauration : Nos équipes techniques ont étudié la question et ont repris un changement récent pour rétablir le service. Nous avons confirmé que les services touchés fonctionnent normalement et qu'ils continuent de surveiller pour assurer la stabilité de la plateforme. Cet incident a été résolu.

2. 17 juillet 2026 à 06:11 UTCpostmortem

   **Description:** Flexera One – APAC – Questions d'accès intermittent **Calendrier:** 3 juillet 2026, 11h20 PDT – 3 juillet 2026, 11h50 PDT **Résumé de l'incident** Le 3 juillet 2026, vers 11h20, un problème a été identifié touchant un sous-ensemble de services Flexera One dans l'environnement de production de l'APAC. Pendant la fenêtre d'incident, certains clients ont peut-être eu des problèmes d'accès intermittents ou des défaillances lors de l'accès à certaines zones de la plate-forme Flexera One. L'impact a été de nature intermittente, car la capacité de service redondante est demeurée disponible et a continué de desservir la circulation pendant l'incident. Autres Flexera Une région, dont le Mouvement des pays non alignés et l ' Union européenne, n ' a pas été touchée. Les équipes techniques ont commencé à enquêter immédiatement et ont examiné les services touchés et les composantes de la plateforme de soutien dans l'environnement du PACA. L'enquête a permis de constater qu'un changement récent apporté à l'environnement de l'APAC contribuait aux pannes intermittentes de service observées. Dans le cadre de l'effort de rétablissement, le changement a été retourné et le comportement de service a été surveillé pour valider la récupération. Après le renversement, la stabilité du service a été rétablie et les clients ont pu accéder aux fonctionnalités affectées normalement. Vers 11h50, les services fonctionnaient comme prévu et l'incident était considéré résolu. (en milliers de dollars) ** Cause de la mort** L'incident a été causé par un changement de configuration à l'intérieur de l'environnement APAC qui a affecté involontairement la communication entre un sous-ensemble de services de plate-forme et un composant de plate-forme de backend. Au cours de l'enquête, les équipes techniques ont déterminé que le changement avait empêché certains services de plate-forme de communiquer correctement avec la composante touchée. Cela a entraîné des défaillances intermittentes affectant un sous-ensemble de services Flexera One dans la région APAC. Bien que le problème se soit posé, un ou plusieurs modules appuyant les services touchés sont demeurés disponibles et ont continué de desservir le trafic. Par conséquent, les clients ont éprouvé des problèmes d'accès intermittents plutôt qu'une panne complète de service. (en milliers de dollars) **Mesures correctives** Les mesures suivantes ont été prises pendant l'intervention : • Incident Investigation Initiated: Les équipes techniques ont commencé à enquêter sur des problèmes d'accès intermittents touchant un sous-ensemble de services Flexera One dans la région APAC. • Examen de la plate-forme achevé : Les équipes techniques ont examiné les services concernés et les composantes de la plate-forme d'appui dans l'environnement APAC afin de déterminer la source de la question. • Changement récent identifié: l'enquête a identifié un changement récemment mis en œuvre qui corrélé avec la dégradation observée du service. • Changement inversé: Le changement identifié a été retourné dans le cadre de l'effort d'atténuation pour rétablir un comportement de service normal. • Service Recovery Validé: Les équipes techniques ont surveillé le comportement de service après le retour et confirmé que la fonctionnalité affectée fonctionnait normalement. • Surveillance de la stabilité de la plate-forme : Une surveillance supplémentaire a été effectuée après les activités de restauration afin de vérifier la stabilité continue du service avant la fermeture de l'incident. (en milliers de dollars) ** Mesures préventives à venir** Cet incident a mis en lumière l'importance de valider les changements apportés à la plate-forme pour s'assurer que les impacts imprévus sont identifiés avant qu'ils n'affectent la disponibilité du service. Sur la base de l'enquête, les activités de suivi suivantes sont menées : • Améliorations de la validation de la configuration : Examiner et améliorer les processus de validation des changements de configuration de l'infrastructure et de la plate-forme pour aider à identifier les impacts imprévus avant que les changements ne soient mis en oeuvre dans les environnements de production. • Améliorations apportées à la vérification après le déploiement : Examiner les procédures de vérification après le déploiement afin de s'assurer que les services essentiels restent accessibles et fonctionnent comme prévu à la suite des changements de configuration.

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

1. 25 juin 2026 à 06:54 UTCresolved

   Description de l'incident : Nous avons identifié un problème touchant le traitement des stocks dans Flexera One IT Asset Management après la sortie de 2026 R1 dans les environnements APAC et Europe. Par conséquent, certains chargements d'inventaire n'ont pas été traités avec succès, ce qui a retardé l'affichage des données d'inventaire dans Flexera One IT Asset Management et n'a pas tenu compte de l'inventaire des clients le plus récent. Priorité : P2 Activité de restauration : Les équipes techniques ont identifié un problème lié à la capacité qui affecte le traitement des stocks et ont effectué des redémarrages de services ciblés dans les régions touchées afin de rétablir le traitement normal. Le service a été restauré le 24 juin 2026, 23h00 PDT, et les dossiers d'inventaire sont maintenant traités avec succès. Nos équipes continuent de surveiller la plateforme pour assurer une stabilité durable. Un rapport post mortem détaillant la cause fondamentale et les mesures préventives sera communiqué une fois l'enquête terminée.

2. 15 juillet 2026 à 06:18 UTCpostmortem

   **Description:** Flexera One- Gestion des actifs informatiques- APAC & EU - Inventaire NDI Défauts d'importation **Calendrier:** 18 juin 2026, 09:00 PDT au 25 juin 2026, 02:42 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le mercredi 24 juin, 2026, 23:35 PDT, après le déploiement de la Flexera One IT Asset Management 2026 R1 dans les environnements Australie et Europe Production, nos équipes ont identifié un problème affectant le traitement des fichiers d'inventaire NDI. En conséquence, un nombre important de dossiers d'inventaire ont échoué pendant le traitement et n'ont pas été reflétés dans les données d'inventaire des clients, ce qui a fait que l'information d'inventaire affichée dans Flexera One ITAM est devenue obsolète pour les clients touchés. Les équipes techniques ont immédiatement entrepris une enquête et déterminé que la question se posait dans le cadre du processus de traitement des stocks introduit avec la publication de 2026 R1. Les dossiers d'inventaire ont échoué à la suite d'échecs répétés du traitement, ce qui a empêché la mise à jour des stocks et contribué à augmenter la charge de traitement des services touchés. Pour rétablir le service, les équipes techniques ont mis en place des mesures correctives en rafraîchissant les services d'application touchés dans les environnements touchés. À la suite des activités de restauration, le traitement des stocks a repris avec succès et les nouveaux chargements ont été traités comme prévu. La surveillance continue a confirmé la stabilité du comportement de la plate-forme, et l'incident a été déclaré résolu après validation prolongée. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) Le problème a été causé par un défaut introduit avec la version de Flexera One IT Asset Management 2026 R1 qui a affecté le traitement des fichiers d'inventaire NDI. Dans des conditions spécifiques, les fichiers d'inventaire n'ont pas pu être traités avec succès en raison d'un problème dans le processus d'authentification et de traitement, ce qui a entraîné le rejet des fichiers avant leur traitement. Au fur et à mesure que les dossiers défectueux s'accumulaient, la capacité de traitement était de plus en plus consommée par des défaillances répétées, ce qui empêchait le traitement des stocks réussi et retardait les mises à jour des stocks pour les clients touchés. Facteurs contributifs * Les dossiers d'inventaire ont échoué dans le processus de traitement, ce qui a accru l'utilisation des ressources pour les services d'inventaire touchés. * L'augmentation de la charge de traitement a réduit la capacité disponible pour les nouvelles demandes de traitement des stocks. * Le problème a affecté les environnements de production du lancement de 2026 R1; North America Production n'a pas été touchée parce que le rejet n'avait pas encore été déployé. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) * Les équipes techniques ont identifié le déroulement du traitement des stocks et ont mis en place des mesures correctives pour rétablir le service. * Les services d'application ont été mis à jour dans les environnements de production touchés, ce qui a permis de rétablir le traitement normal des stocks. * Le traitement des nouveaux fichiers d'inventaire a repris avec succès après la restauration du service. * L'environnement fait l'objet d'une surveillance accrue pour valider le rendement du traitement et confirmer une reprise soutenue. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) * Validation améliorée des versions - Les procédures de validation des versions seront améliorées afin d'inclure d'autres tests de bout en bout des processus de traitement des stocks à la suite des principales versions des plates-formes. * Surveillance améliorée du traitement - La surveillance et l'alerte seront examinées et élargies pour permettre de détecter plus tôt les défaillances anormales du traitement des stocks et l'accumulation excessive de fichiers dans les files d'attente. * Résilience opérationnelle - Des mesures de protection supplémentaires seront mises en oeuvre dans le cadre du processus de traitement des stocks afin d'améliorer la récupération des échecs de traitement et de réduire au minimum l'impact sur les clients si des conditions similaires se produisent à l'avenir. * Code Améliorations de la qualité et de l'examen \(Complété\) - Dans le cadre de l'examen postérieur à l'incident, le code touché a été corrigé pour s'assurer que les défaillances de communication sont traitées de façon appropriée et qu'elles n'ont pas d'incidences plus larges sur le traitement. De plus, le processus d'élaboration et d'examen a été renforcé pour s'assurer que les conclusions de l'examen sont évaluées et traitées de façon appropriée avant que les changements futurs ne soient approuvés pour publication.

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

1. 24 juin 2026 à 08:00 UTCinvestigating

   Description de l'incident: Nous avons identifié un problème affectant l'accès à Flexera One dans la région de l'UE. Les clients peuvent recevoir des erreurs lorsqu'ils tentent de se connecter à Flexera One. Priorité: P1 Activité de restauration : Nos équipes techniques étudient activement la question et travaillent à la mise en œuvre de mesures correctives pour restaurer la fonctionnalité normale de connexion. Les efforts d'enquête et de stabilisation se poursuivent. Nous continuerons de suivre de près la situation et de fournir d'autres mises à jour au fur et à mesure que les progrès se poursuivront.

2. 24 juin 2026 à 09:00 UTCresolved

   Le problème a été résolu et la fonctionnalité de connexion a été rétablie pour les clients touchés. Les équipes techniques ont déterminé la cause du problème et mis en oeuvre des mesures correctives pour rétablir l'exploitation normale du service. L'environnement demeure stable et la surveillance continue a confirmé le succès de l'authentification et de l'accès à la plateforme. Un rapport post mortem contenant des détails supplémentaires sera communiqué une fois l'enquête terminée.

3. 7 juillet 2026 à 08:28 UTCpostmortem

   **Description:** Flexera One – UE – Perturbation de l'accès aux connexions **Calendrier:** 24 juin 2026, 12 h 41 PDT au 24 juin 2026, 02 h 04 PDT (en milliers de dollars) **Résumé de l'incident** (en milliers de dollars) Le mercredi 24 juin 2026, à 12h41 PDT, nos équipes ont détecté un problème affectant les clients de la région de l'UE. Les utilisateurs touchés ont subi des défaillances d'authentification lorsqu'ils ont tenté de se connecter à Flexera One en utilisant Single Sign-On \(SSO\), entraînant des erreurs de serveur et empêchant l'accès à la plate-forme. Dès la détection, les équipes techniques ont immédiatement ouvert une enquête et confirmé que la question était isolée du processus d'authentification. La validation de l'application et des services de plate-forme sous-jacents a montré que toutes les infrastructures de base restaient saines et opérationnelles. Une analyse plus approfondie a permis de déterminer qu'un compte de service utilisé pour communiquer avec le fournisseur d'identité n'était plus disponible, ce qui a entraîné l'échec des demandes d'authentification. Le compte de service a été rapidement restauré, qui a rétabli le traitement normal de l'authentification et l'accès complet des clients. Après la restauration, l'environnement a été étroitement surveillé et la fonctionnalité de connexion a été validée de manière exhaustive pour assurer la stabilité du service. Aucun impact supplémentaire sur le client n'a été observé et l'incident a ensuite été déclaré résolu. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) La question a été causée par la suspension involontaire d'un compte de service qui supporte l'authentification entre Flexera One et le fournisseur d'identité. En conséquence, les demandes d'authentification n'ont pas pu être traitées avec succès, empêchant les clients concernés de la région de production de l'UE d'accéder à la plate-forme par le biais d'un signal unique \(SSO\). Facteurs contributifs * Un compte de service essentiel au flux de travail d'authentification a été suspendu par inadvertance pendant une activité de nettoyage de routine. * La suspension a empêché que les demandes d'authentification soient validées avec succès, entraînant des défaillances de connexion pour les clients touchés. * La question a été isolée du service d'authentification et n'a pas affecté la disponibilité de l'infrastructure sous-jacente de l'application ou de la plateforme. (en milliers de dollars) **Mesures correctives** (en milliers de dollars) * Le compte de service touché a été restauré, rétablissant l'authentification avec le fournisseur d'identité. * La fonctionnalité de connexion a été validée après restauration. * Les équipes d'ingénierie ont continué de surveiller pour confirmer la stabilité de la plate-forme et l'authentification réussie des clients. (en milliers de dollars) ** Mesures préventives à venir** (en milliers de dollars) * Gouvernance des comptes de services - Les processus régissant les comptes de services essentiels seront renforcés afin de réduire le risque de changements involontaires touchant les services de production. * Surveillance améliorée - La surveillance et l'alerte seront améliorées pour permettre une détection plus précoce des défaillances d'authentification affectant les processus de connexion des clients. * Améliorations du processus opérationnel - Nos équipes ont documenté cette leçon et mettront en oeuvre des améliorations du processus pour réduire la probabilité d'incidents semblables.

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