Flexera Outage History

Started Jun 02, 2026, 02:46 PM UTC· resolved Jun 02, 2026, 04:18 PM UTC

1. investigating Jun 02, 2026, 02:46 PM UTC

   Incident Description: We are currently investigating reports of Snow Atlas being inaccessible in the Australia region. The issue began following a scheduled maintenance window that extended beyond the planned downtime. Customers in the Australia region may be unable to access Snow Atlas at this time. Priority: P1 Restoration Activity: Our technical team is actively working to restore access and remediate the issue. We are continuing to monitor progress closely and will provide further updates as remediation efforts continue.

2. investigating Jun 02, 2026, 03:20 PM UTC

   We are continuing to investigate the issue affecting Snow Atlas in the Australia region following the scheduled maintenance window that extended beyond the planned downtime. Initial reports indicated that Snow Atlas was unavailable; however, based on the latest update, customers can now access the Snow Atlas application in the Australia region and view existing data. At this time, customers may be unable to ingest new data or export data while remediation efforts continue. Ingestion and export requests are currently queuing and are expected to be processed once data ingestion is re-enabled. Our technical team is continuing work to restore full functionality, and we will provide further updates as progress is made.

3. resolved Jun 02, 2026, 04:18 PM UTC

   Snow Atlas functionality in the Australia region has been restored. Customers can now access the Snow Atlas application, and data ingestion and export functionality are available again. The issue occurred after a scheduled maintenance window extended beyond the planned downtime. During the maintenance activity, some required deployment and configuration steps took longer than expected, which delayed the restoration of full service. We will continue to monitor the service to ensure continued stability. A full post-mortem report containing a detailed incident summary, root cause, and future preventative measures will be shared in the coming days.

4. postmortem Jun 17, 2026, 06:22 AM UTC

   **Description:** Snow Atlas - Australia - Service Unavailable **Timeframe:** June 02, 2026, 5:30 AM PDT to June 02, 2026, 9:18 AM PDT ‌ **Incident Summary** ‌ On Tuesday, June 02, 2026, 5:30 AM PDT, A service disruption affected Snow Atlas customers in the Australia region following a scheduled maintenance activity. As part of a planned infrastructure maintenance activity, our teams performed a migration between Australia South East and Australia East. The maintenance was expected to be completed within the scheduled window; however, the activity extended beyond the planned duration due to unexpected delays encountered during execution. Throughout the issue, customers retained access to the Snow Atlas application and were able to view and browse existing data. The impact was limited to data ingestion and data export functionality. New ingestion requests and export requests were queued while maintenance activities remained in progress. During the maintenance execution, technical teams encountered delays related to deployment synchronization activities and infrastructure management tooling, which extended the overall duration of the migration. Once the migration was completed and services were re-enabled, queued ingestion and export requests resumed processing normally by 9:18 AM PDT. ‌ **Root Cause** ‌ The issue was caused by a scheduled infrastructure migration that exceeded its planned maintenance window. The migration required multiple coordinated deployment, configuration, and application management activities, each dependent on successful completion of the previous step. During execution, several deployment and synchronization operations took significantly longer than anticipated based on testing and pre-maintenance validation. These delays extended the maintenance activity beyond the expected timeframe, resulting in a longer-than-planned interruption to data ingestion and export services. Contributing Factors * The migration involved multiple interdependent deployment and configuration changes that required sequential execution. * Deployment synchronization activities experienced intermittent delays and required additional time to complete. * Certain deployment operations required manual intervention when synchronization did not complete as expected. * The duration of these activities was longer than observed during pre-production testing, resulting in an inaccurate estimate of the total maintenance execution time. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Technical teams completed the migration between Australia South East and Australia East. * Deployment and synchronization issues encountered during the migration were investigated and resolved. * Data ingestion services were re-enabled following successful completion of the migration activities. * Queued ingestion and export requests were allowed to process normally once services were restored. * The environment was closely monitored following restoration to verify platform stability and successful processing of queued requests. ‌ **Future Preventative Measures** * Improved Maintenance Planning - Future migration activities will be further segmented where possible to reduce the number of changes performed within a single maintenance window and improve execution predictability. * Enhanced Maintenance Duration Estimation - Maintenance planning processes will be updated to better account for deployment synchronization times, infrastructure dependencies, and potential manual intervention requirements when estimating maintenance windows. * Lessons Learned Review - The maintenance execution process and associated dependencies will be reviewed to identify additional opportunities to streamline migration activities, reduce operational complexity, and minimize the risk of maintenance overruns in future events.

Read the full incident report →

Started Jun 02, 2026, 02:29 PM UTC· resolved Jun 16, 2026, 09:33 AM UTC

1. investigating Jun 02, 2026, 02:29 PM UTC

   Incident Description: We are investigating an issue affecting inventory processing in Flexera One IT Visibility. Customers may experience longer-than-expected inventory processing times, and some inventory imports may display a timeout status while processing continues. Priority: P2 Restoration Activity: Our technical team is actively investigating the issue and reviewing current processing activity to confirm scope and progress. We are monitoring the situation closely and will provide updates as more information becomes available.

2. investigating Jun 02, 2026, 06:10 PM UTC

   The team has identified examples where inventory uploads and collection activity completed successfully, but some results are taking longer than expected to finish processing and may continue to display a timeout status. Further review is ongoing to better understand the current processing state and overall scope. We are continuing to monitor progress and will provide another update as more information becomes available.

3. investigating Jun 03, 2026, 07:45 AM UTC

   Our teams continue to investigate the issue and review the current processing activity across the platform. While some operations are completing successfully, we are still assessing the extent of the impact and validating overall system behavior. Investigation and monitoring efforts remain ongoing as we work to better understand the underlying cause and identify any additional corrective actions that may be required. We will continue to provide updates as more information becomes available.

4. monitoring Jun 03, 2026, 08:50 AM UTC

   Services are operating currently. Our teams are monitoring backlog processing and collecting data to track progress and validate that queue volumes are decreasing as expected. We will continue to provide updates as more information becomes available.

5. identified Jun 03, 2026, 06:11 PM UTC

   The technical team has confirmed that the EU region is operating normally at this time, and processing activity appears stable. We will continue monitoring the EU environment to ensure it remains stable. Investigation and recovery efforts are continuing for North America, where some inventory imports may still display a timeout status while processing activity continues. The team is actively reviewing the remaining timed-out imports and tracking processing progress to confirm continued recovery. We will provide another update as more information becomes available.

6. identified Jun 04, 2026, 07:44 AM UTC

   Recovery and monitoring efforts remain ongoing in North America. While processing activity continues, some inventory imports may still show a timeout status. Our teams are actively reviewing the remaining affected imports and monitoring processing trends to validate continued recovery and system stability. We will provide further updates as additional information becomes available.

7. identified Jun 04, 2026, 06:47 PM UTC

   Recovery efforts remain ongoing in North America. Our technical team continues to review remaining inventory processing delays while monitoring processing activity and recovery progress. In parallel, we are continuing targeted work to improve the reliability and recoverability of IT Visibility inventory updates. We will provide further updates as recovery progresses and additional information becomes available.

8. identified Jun 05, 2026, 06:15 AM UTC

   Our technical teams continue to work on recovery efforts and monitor system performance. As part of the ongoing investigation, a corrective fix has been deployed to address a condition that may have contributed to processing delays and increased system load. Early monitoring is underway to validate the effectiveness of this change. While recovery activities continue, processing of the existing backlog is ongoing and may take additional time as the system works through queued activity. Teams are closely monitoring recovery progress and overall platform stability. We will continue to provide updates as more information becomes available.

9. identified Jun 05, 2026, 05:31 PM UTC

   Recovery efforts remain ongoing in North America. Our technical teams continue to monitor the corrective fix that was deployed to address a condition that may have contributed to processing delays and additional system load. Recovery progress continues to be impacted by underlying service instability. To support recovery, traffic has been adjusted while the affected service continues to stabilize. Processing of the existing backlog is ongoing, and some inventory imports may continue to take longer than expected while queued activity is processed. We are continuing to monitor recovery progress and overall platform stability, and will provide another update as more information becomes available.

10. identified Jun 05, 2026, 11:50 PM UTC

    The technical team has confirmed that the underlying service issue has stabilized, and the system has been scaled up to support recovery. A corrective fix has also been deployed for an issue that may have contributed to longer-than-expected processing times and timeout statuses. We are continuing to monitor inventory processing progress over the weekend to confirm continued recovery and stability. We will provide another update as monitoring continues.

11. monitoring Jun 06, 2026, 07:58 AM UTC

    Our teams continue to monitor recovery progress, and the service remains stable following the corrective actions implemented previously. We will continue to monitor processing and overall platform health over the weekend to confirm full recovery and will provide further updates as they become available.

12. monitoring Jun 06, 2026, 07:38 PM UTC

    Recovery progress continues to improve. The technical team’s latest review shows the number of inventory imports displaying timeout status has decreased compared to the previous review. The team will continue monitoring processing progress over the weekend to confirm continued recovery and stability. We will provide another update as monitoring continues.

13. monitoring Jun 07, 2026, 01:14 PM UTC

    Recovery efforts continue to show positive progress. Based on the latest review by the technical team, the number of inventory imports reporting timeout status has continued to decline and the backlog is steadily being reduced. The team will continue to closely monitor processing activity and platform stability to ensure recovery progresses as expected. We will provide further updates as additional information becomes available.

14. monitoring Jun 08, 2026, 12:39 PM UTC

    Recovery efforts continue to progress as expected. The latest review from the technical team shows the processing activity steadily reducing the remaining backlog. The environment remains stable, and teams are continuing to monitor processing throughput and platform health to confirm sustained recovery. Monitoring will remain in place until inventory processing has fully returned to expected levels. We will provide further updates as additional information becomes available.

15. identified Jun 08, 2026, 03:49 PM UTC

    Recovery efforts remain ongoing. The latest review shows that the number of inventory imports displaying timeout status has decreased overall compared to earlier recovery checks, although progress has been uneven while remaining queued activity is processed. The technical team has deployed an additional fix to improve processing behavior during recovery and is continuing to monitor its effectiveness. Teams are also continuing recovery actions to help remaining queued inventory processing move through the system. We will continue monitoring processing progress and platform stability, and will provide further updates as recovery continues.

16. identified Jun 09, 2026, 10:48 AM UTC

    Our teams continue to monitor recovery progress related to inventory processing delays and timeout status behavior. The recovery efforts continue to advance, with the number of remaining timed-out imports significantly reduced. Teams are reviewing the remaining impacted imports individually to ensure processing completes successfully. We are continuing to apply mitigation measures as needed, investigate the underlying factors contributing to the remaining delayed imports, and maintain enhanced monitoring to confirm continued recovery and full restoration of normal processing behavior. We will provide further updates as additional information becomes available.

17. monitoring Jun 10, 2026, 06:23 AM UTC

    The recovery efforts continue to progress, with only a very small number of imports remaining under investigation. The platform remains stable, and the vast majority of imports are processing successfully within expected timeframes. Teams are implementing additional improvements to further optimize processing capacity while continuing to monitor recovery progress and validate sustained platform stability. Enhanced monitoring remains in place as we work toward confirming full recovery and incident closure.

18. monitoring Jun 11, 2026, 09:07 AM UTC

    Further remediation actions have been implemented to speed up the process, and imports are no longer blocked for the organizations affected by the identified issue. Imports have successfully completed for some of the impacted organizations, while processing continues for the remaining organization and is expected to complete later today. The platform remains stable, with incoming imports processing within expected timeframes. The team has identified the probable root cause of the remaining issue and is actively working on a permanent fix. The current target is to complete deployment of the permanent fix next week, pending validation and release readiness.

19. monitoring Jun 12, 2026, 04:24 PM UTC

    Recovery has progressed significantly, and the platform remains stable. A workaround has been implemented for the imports affected by the remaining issue. Most of those imports have now completed successfully, and the remaining processing is being closely monitored. We will continue monitoring processing progress and provide further updates as available.

20. monitoring Jun 13, 2026, 04:09 PM UTC

    Recovery efforts continue to make strong progress, and the platform remains stable. The small number of remaining imports continue to process as expected and are being closely monitored by our teams. We will continue to track processing activity and recovery progress and will provide further updates as additional information becomes available.

21. monitoring Jun 15, 2026, 06:11 AM UTC

    Recovery efforts continue to progress, with only a very small number of imports remaining under investigation. The platform remains stable, and incoming imports are processing within expected timeframes. Our teams are actively reviewing the remaining exceptions to determine their causes and ensure successful completion. We will continue to closely monitor processing activity and platform performance and will provide additional updates as more information becomes available.

22. resolved Jun 16, 2026, 09:33 AM UTC

    The platform remains stable, and incoming imports are processing within expected timeframes. Any remaining import-related issues are being investigated separately as isolated cases . Based on the successful recovery and sustained platform stability, this incident has now been declared resolved. A post-mortem report containing additional details, including the root cause, remediation activities, and preventative measures, will be shared once the investigation is complete.

23. postmortem Aug 11, 2026, 01:06 AM UTC

    **Description:** Flexera One - IT Visibility - NA - Inventory Processing Delays and Timeout Status **Timeframe:** June 2, 2026, 7:29 AM PDT - June 15, 2026, 7:58 AM PDT **Incident Summary** On June 2, 2026, at approximately 7:29 AM PDT, we received customer reports of IT Visibility inventory imports displaying timeout status in the North America production environment. The ITV platform remained accessible during the incident. The primary customer impact was delayed inventory processing and delayed availability of updated inventory data for some customers. In some cases, imports displayed timeout status while processing was still pending or delayed. This status did not always indicate that processing had failed, as some processing activity could continue in the background and complete later. Technical teams investigated reported customer examples, reviewed organization and data source-level processing activity, and monitored backlog and processing progress over time. During the investigation, teams identified multiple contributing factors affecting timely inventory processing and recovery. These included processing inefficiencies that could add unnecessary load, conditions where processing progress could be delayed or regress during recovery, and temporary database instability that affected backlog reduction. Corrective actions were applied to improve processing behavior, stabilize recovery, and unblock affected processing activity. Technical teams continued monitoring timed-out imports, customer-reported examples, and new processing activity to confirm recovery. By June 15, 2026, at approximately 7:58 AM PDT, the broader incident impact had cleared. Remaining isolated items were isolated from the broader incident impact and continued to be tracked separately through follow-up actions. **Root Cause** The incident was caused by multiple contributing factors affecting the timely processing and availability of updated IT Visibility inventory data. Some inventory imports experienced delayed completion due to processing backlog and inefficiencies within the inventory processing flow. Identified defects contributed to unnecessary processing load and, in some cases, caused recovery progress to regress when services were restarted. Technical teams also identified conditions where queued processing activity was not always progressing as expected without recovery actions. In addition, temporary database instability impacted overall service recovery and slowed backlog reduction while the system was catching up. As a result, some imports displayed timeout status when processing took longer than expected. In some cases, the timeout status did not mean processing had stopped or failed, as processing could continue in the background and complete later. **Remediation Actions** The following actions were taken during the incident response: 1. **Incident Response Initiated:** Technical teams began investigating after multiple customer reports were received regarding inventory imports displaying timeout status. 2. **Customer Reports Reviewed:** Reported customer examples and related support cases were reviewed to validate the scope, affected organizations, data sources, and current processing behavior. 3. **Regional Scope Validated:** Technical teams reviewed timeout activity across regions. APAC did not show timeout activity, EU impact was limited and later narrowed, and the primary ongoing impact remained in North America. 4. **Processing Activity and Backlog Reviewed:** Teams reviewed inventory processing activity, backlog queues, organization-level processing state, and data source-level status to determine where imports were delayed and whether processing was still progressing. 5. **Database Recovery Supported:** Technical teams worked through database instability affecting recovery, including cluster recovery and scaling activity, to restore stability and improve backlog reduction. 6. **Processing Fixes Applied:** Corrective fixes were deployed for identified processing defects that could contribute to timeout behavior, unnecessary processing load, and recovery progress moving backwards during service restarts. 7. **Queued Processing Recovery Performed:** Teams applied recovery actions and workarounds to help queued processing activity move forward while the remaining processing issue was investigated and addressed. 8. **Affected Imports Unblocked:** Technical teams implemented a workaround to unblock affected imports for the remaining impacted organizations and continued monitoring those imports through completion. 9. **Customer Examples Validated:** Customer-reported examples were reviewed throughout recovery to confirm whether affected imports and updated inventory data were progressing as expected. 10. **Post-Recovery Monitoring Performed:** Teams continued monitoring platform activity, timed-out imports, and new processing behavior until the broader incident impact had cleared. Remaining isolated items were isolated from the broader incident impact and continued to be tracked separately through follow-up actions. **Future Preventative Measures** Following this incident, technical teams implemented improvements to strengthen the reliability, recoverability, monitoring, and operational visibility of IT Visibility inventory processing. The implemented improvements included: 1. **Inventory Processing Reliability and Recoverability:** Improvements were made to reduce conditions that could contribute to delayed processing, unnecessary processing load, or recovery delays when queued inventory activity needed to catch up. 2. **Monitoring and Observability:** Additional monitoring and observability improvements were implemented to provide better visibility into processing health, throughput, latency, failure patterns, retry behavior, and backlog accumulation across production environments. 3. **Recovery Handling:** Recovery processes were improved to help teams identify delayed or stuck processing activity earlier and take corrective action more consistently when processing did not progress as expected. 4. **Operational Readiness:** Internal investigation and validation processes were improved to help teams assess affected organizations, data sources, and processing state more efficiently during similar events. Teams also reviewed import status behavior to provide clearer status information when processing takes longer than expected but may still continue in the background. Since these corrective measures were implemented, we have not observed a recurrence of the same broad incident pattern.

Read the full incident report →

Started Jun 02, 2026, 07:41 AM UTC· resolved Jun 02, 2026, 09:55 PM UTC

1. investigating Jun 02, 2026, 07:41 AM UTC

   Incident Description: We are currently investigating an issue affecting a subset of our customers in the APAC production environment who may encounter Red bar errors when attempting to reconfigure or redirect a Beacon . Priority: P2 Restoration Activity: Our technical and support teams havebeen engaged and they have identified that the issue is affecting multiple APAC production tenants. Initial investigations have ruled out several potential causes, and teams are continuing to analyze service dependencies and platform behavior to determine the root cause.

2. identified Jun 02, 2026, 10:21 AM UTC

   Our technical teams have identified a potential root cause for the issue and are actively working to implement and validate a fix. Investigation and remediation efforts remain ongoing, and teams are closely monitoring the environment throughout the implementation process. Further updates will be provided as they become available.

3. identified Jun 02, 2026, 06:06 PM UTC

   Technical teams have identified that the issue is likely related to a service compatibility issue affecting Beacon-related workflows in the APAC region. As part of the remediation effort, the team is validating a service update in lower environments before making any production change. The team is also continuing to review the contributing factors that led to the compatibility issue. We will provide another update as validation progresses.

4. resolved Jun 02, 2026, 09:55 PM UTC

   The issue affecting Beacon-related workflows in the APAC region has been resolved. Technical teams completed a service update, and validation has confirmed that the affected workflow is now accessible. We will continue to monitor the service to ensure continued stability.

5. postmortem Jun 17, 2026, 05:21 AM UTC

   **Description:** Flexera One – IT Asset Management and IT Visibility – APAC – Beacon Configuration and Reconfiguration Errors **Timeframe:** June 1, 2026, 7:41 PM PDT – June 2, 2026, 12:58 PM PDT **Incident Summary** On Monday, June 1, 2026, at approximately 7:41 PM PDT, an issue was identified affecting Beacon configuration and reconfiguration workflows in the APAC Production environment for Flexera One IT Asset Management and IT Visibility. During the affected period, customers attempting to access affected Beacon-related pages may have encountered a red bar error or server-side application error. Technical teams investigated the impacted workflows and backend service dependencies. The investigation confirmed that affected requests were returning server-side errors and that the issue was associated with the backend service supporting Beacon-related workflows. The issue was resolved by updating the affected Beacon API service in APAC Production. Following the update, the affected Beacon pages were confirmed accessible again. By Tuesday, June 2, 2026, at approximately 12:58 PM PDT, service was confirmed restored and the incident was considered resolved. **Root Cause** The incident was caused by a compatibility issue between the deployed Beacon API service version in APAC Production and recent IT Asset Management database changes. A required related Beacon API service update was not completed in APAC Production as part of the related release activity, which caused some Beacon configuration and reconfiguration workflows to return backend errors. These backend errors were surfaced in the UI as red bar errors when customers attempted to access affected Beacon-related pages. **Remediation Actions** The following actions were taken during the incident response: * **Impact Assessment:** Technical teams confirmed the issue was affecting Beacon configuration and reconfiguration workflows in APAC Production. * **Backend Error Isolation:** Investigation confirmed that affected requests were returning server-side errors from backend service dependencies. * **Service Compatibility Review:** Technical teams identified a compatibility issue between the deployed Beacon API service version and recent IT Asset Management database changes. * **Corrective Service Update:** The Beacon API service was updated in APAC Production to restore the affected workflows. * **Service Restoration Validation:** Following the update, technical teams validated that the affected Beacon pages were accessible and functioning as expected. **Future Preventative Measures** The following follow-up actions were identified: * **Strengthened Deployment Procedures:** We are strengthening deployment dependency checks and cross-team release coordination to ensure required service updates are clearly identified, tracked, and completed when related database or platform changes are released. * **Regional Version Alignment:** Related Beacon API service updates were completed across additional regions, including EU and NAM, to maintain version consistency and reduce the risk of similar compatibility issues occurring elsewhere. * **Expanded Post-Release Validation:** We are expanding post-release validation for critical Beacon configuration and reconfiguration workflows, especially when backend service or database changes are involved.

Read the full incident report →

Started May 29, 2026, 03:07 AM UTC· resolved May 29, 2026, 10:23 AM UTC

1. monitoring May 29, 2026, 03:07 AM UTC

   Incident Description: We are currently experiencing an issue affecting a subset of Snow Atlas customers in the APAC region. Affected users may encounter HTTP 500 errors when accessing the application. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and have identified a potential root cause. As an immediate mitigation, service restarts were performed on the affected components, which restored functionality for impacted customers. Teams are continuing their investigation to implement a permanent resolution and are closely monitoring the environment to ensure ongoing stability. Further updates will be provided as more information becomes available.

2. resolved May 29, 2026, 10:23 AM UTC

   Our teams continue to monitor the environment closely. No ongoing customer-facing impact had been reported, and systems remain stable with the current workaround in place. Root cause investigation efforts are still ongoing, and technical teams continue to validate a permanent fix to prevent recurrence. Further updates will be shared via a post-mortem report.

3. postmortem Jun 16, 2026, 08:41 AM UTC

   **Description:** Snow Atlas – APAC – Login Failures and HTTP 500 Errors **Timeframe:** May 28, 2026, 20:57 PDT to May 29, 2026, 03:32 PDT ‌ **Incident Summary** On Thursday, May 28, 2026, at 20:57 PDT, an incident was identified impacting a subset of Snow Atlas customers in the APAC production environment. Affected users were unable to access the platform or experienced degraded application functionality. This included HTTP 500 and 404 errors, as well as instances where pages loaded incompletely with no data before ultimately returning service unavailability messages. Technical teams engaged immediately and identified degraded performance within a core routing component responsible for handling traffic. As the issue progressed, backend services were unable to communicate reliably, leading to increased request failures and overall application instability for impacted tenants. Initial mitigation actions, including targeted service restarts, successfully restored access for affected customers. Teams continued to investigate the underlying cause while maintaining enhanced monitoring to validate platform stability. A subsequent controlled restart and recovery of the impacted routing services fully resolved the contention conditions. Following these actions, no further customer impact was observed. The platform remained stable throughout the monitoring period, and the incident was formally resolved after normal service operations were confirmed. ‌ **Root Cause** The incident was triggered by an automated infrastructure upgrade initiated by the cloud service provider. This upgrade resulted in a sequential restart of infrastructure nodes supporting the Snow Atlas platform, causing a large number of application services to restart within a compressed timeframe. During the recovery phase, a critical routing component responsible for service discovery and request routing became saturated due to the high volume of service registration activity. Consequently, routing information was intermittently unavailable to dependent services, leading to application errors, request failures, and overall service instability for a subset of APAC customers. Contributing Factors: * The provider-initiated infrastructure upgrade was unplanned from an application perspective and triggered a large-scale, simultaneous service restart across the environment. * The routing service had limited redundancy, increasing the potential for service disruption under certain conditions. * During recovery, the temporary unavailability of the routing service prevented dependent services from resolving required routes, resulting in HTTP 404 and HTTP 500 errors across multiple application functions. * Elevated recovery activity, combined with the lack of redundancy, amplified both the impact and duration of the incident. ‌ **Remediation Actions** The following remediation steps were implemented to restore service functionality: * Technical teams identified the affected routing component and performed targeted recovery actions to restore service. * Service restarts were completed to re-establish routing functionality and stabilize affected platform services. * A controlled restart procedure was executed to ensure clean recovery of the impacted components. * Enhanced monitoring was maintained throughout the recovery process to validate platform stability and detect any recurrence. * Root cause analysis was completed and corrective actions were implemented to address the underlying infrastructure and resiliency gaps. ‌ **Future Preventative Measures** * Controlled Infrastructure Maintenance - Automatic upgrades have been disabled for the affected environment. Future infrastructure upgrades will be performed through planned maintenance activities with appropriate scheduling, oversight, and validation. * Increased Service Redundancy - The routing service has been scaled up to run multiple replicas across separate infrastructure nodes. * Improved Platform Resiliency - Platform resiliency controls have been reviewed and enhanced to better handle large-scale service restart events and reduce the risk of service discovery or routing bottlenecks during recovery operations. * Enhanced Monitoring and Early Detection - Additional monitoring and alerting have been implemented to provide earlier visibility into service degradation and infrastructure events that could impact platform availability

Read the full incident report →

Started May 27, 2026, 11:04 AM UTC· resolved May 27, 2026, 01:33 PM UTC

1. identified May 27, 2026, 11:04 AM UTC

   Incident Description: We are investigating an issue affecting Flexera One IT Asset Management customers in the EU & APAC regions where, following a recent production release, reconcile jobs have been failing for multiple customers. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and have identified the primary cause. Subsequent reconcile runs for customers who encountered errors are expected to complete successfully. In parallel, teams are deploying a hotfix to prevent the issue from impacting customers who have not yet completed their first reconcile following the recent release.

2. monitoring May 27, 2026, 11:18 AM UTC

   The hotfix has been deployed, and our teams are currently monitoring the services to ensure resolution.

3. resolved May 27, 2026, 01:33 PM UTC

   Following the hotfix deployment, no additional customer reconcile failures have been observed. After an extended monitoring period and validation of platform behavior, the issue is now being declared as resolved.

4. postmortem Jun 10, 2026, 06:09 AM UTC

   **Description:** Flexera One- IT Asset management - EU & APAC - PROD Reconcile failures **Timeframe:** May 26, 2026, 12:29 PM PDT to May 27, 2026, 06:32 AM PDT ‌ **Incident Summary** ‌ On Wednesday, May 26, 2026, at 12:29 PM PDT, an issue was identified by our teams affecting Flexera One IT Asset Management customers in the EU and APAC production environments caused reconcile jobs to fail following a recent production release. Following a recent production release, a subset of Flexera One IT Asset Management customers in the EU and APAC production environments experienced failures during reconcile processing. The issue primarily affected the first reconcile run performed after the release. Customers encountering the issue received reconcile failures, resulting in delays to processing and an increase in support inquiries. Upon investigation, technical teams identified the likely source of the failures and confirmed that tenants which had already experienced an initial reconcile failure were expected to successfully complete subsequent reconcile runs. To prevent additional customers from being affected, a hotfix was developed, validated, and deployed to production. Following deployment of the hotfix, no additional reconcile failures related to this issue were observed. The platform remained under enhanced monitoring while teams validated system behavior and confirmed that reconcile processing was operating as expected. After an extended observation period with no further occurrences, the incident was declared resolved on May 27, 2026, at 06:32 AM PDT. ‌ **Root Cause** ‌ The issue was caused by a data handling inconsistency introduced during a system update. Under specific conditions, this inconsistency resulted in unexpected behavior during the initial reconcile processing performed after the release, causing the reconcile job to fail. Contributing Factors: * The issue only manifested during the first reconcile execution following the production release, making it difficult to identify during pre-release validation activities. * The affected processing path encountered conditions that were not fully represented in update validation scenarios. * Existing monitoring detected the reconcile failures but did not provide early indicators of the underlying processing condition before customer impact occurred. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Technical teams investigated and identified the source of the reconcile failures. * Validation was performed to confirm that customers who had already encountered the issue could successfully complete subsequent reconcile runs. * A production hotfix was developed and deployed to prevent additional customers from experiencing the failure condition. * Enhanced monitoring was implemented during the recovery period to validate platform stability and reconcile processing behavior. * The incident remained under observation until teams confirmed no further customer impact was occurring. ‌ **Future Preventative Measures** ‌ * Enhanced Update Validation - Validation procedures for future system updates have been strengthened to improve coverage of data processing scenarios and compatibility checks that may occur during initial post-release operations. * Improved Monitoring and Detection - Additional monitoring and alerting opportunities have been identified and will be implemented to provide earlier visibility into reconcile processing anomalies and similar failure patterns. * Release Process Improvements - Lessons learned from this event have been incorporated into release planning and review processes to further reduce the risk of similar post-release processing issues and improve early detection should comparable symptoms arise in the future.

Read the full incident report →

Started May 26, 2026, 09:49 PM UTC· resolved May 27, 2026, 07:33 AM UTC

1. investigating May 26, 2026, 09:49 PM UTC

   Incident Description: We are investigating an issue affecting Flexera One IT Asset Management in the NAM region. Customers may experience intermittent Beacon-related issues, including timeouts, inventory upload delays, and some Beacon download failures. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and working to identify the appropriate remediation steps. We are monitoring the situation closely and will provide updates as more information becomes available.

2. investigating May 27, 2026, 01:46 AM UTC

   Investigation is ongoing, and technical teams are continuing to review the timeout behavior and related errors to confirm the root cause and identify the appropriate remediation steps. We will provide another update as more information becomes available.

3. investigating May 27, 2026, 06:23 AM UTC

   Our technical teams continue to actively investigate and troubleshoot the issue to determine the underlying cause of the observed behavior. Investigation efforts remain ongoing, with teams reviewing multiple potential contributing factors and analyzing system activity. At this time, the root cause has not yet been conclusively identified, and work is continuing to isolate and resolve the issue. Further updates will be shared as additional information becomes available.

4. resolved May 27, 2026, 07:33 AM UTC

   Our investigation and mitigation efforts have been completed, and the issue has now been resolved. Services are operating as expected, and impacted functionality has been restored. Our technical teams will continue to closely monitor the platform to ensure ongoing stability and validate continued healthy system behavior.

5. postmortem Jun 11, 2026, 06:44 AM UTC

   **Description:** Flexera One IT Asset Management – NAM – Beacon Upload and Download Issues **Timeframe:** May 22, 2026, 11:00 PM PDT – May 26, 2026, 11:41 PM PDT **Incident Summary** On May 22, 2026, at approximately 11:00 PM PDT, an issue began affecting some Beacon activity for Flexera One IT Asset Management customers in the North America production environment. During the affected period, some customers experienced intermittent issues with inventory uploads and Beacon downloads. Reported symptoms included upload timeouts, inventory upload delays, increasing Beacon backlogs, and some download failures. Successful uploads and downloads continued to be observed during the incident, so the issue did not affect all Beacon activity. Technical teams investigated the reported behavior by reviewing customer-reported failures, the Beacon request path, timeout patterns, backlog growth, and related backend processing errors. The investigation identified that some requests were not completing within the expected timeframe, which contributed to the intermittent behavior observed by affected customers. The issue showed signs of backlog growth before the recent disaster recovery testing activity, with the impact increasing more significantly afterward. Based on the investigation, the disaster recovery activity contributed to the increased visibility and severity of the issue. As part of the recovery effort, technical teams identified a connection handling issue in a backend service supporting Beacon processing. The affected service and related authentication components were restarted to restore normal processing behavior. Following these corrective actions, Beacon processing recovered, impacted backlogs began clearing, and affected upload and download functionality returned to expected operation. By May 26, 2026, at approximately 11:41 PM PDT, the issue had been resolved. Technical teams continued monitoring after recovery to confirm continued stability. **Root Cause** The incident was caused by a connection handling issue in a backend service supporting Beacon processing. This contributed to intermittent upload timeouts, inventory upload delays, Beacon backlog growth, and some Beacon download failures for affected customers. **Remediation Actions** The following actions were taken during the incident response: 1. **Incident Response Initiated:** Technical teams began investigating customer reports of Beacon upload and download issues in the North America production environment. 2. **Impact Assessed:** Teams reviewed customer-reported symptoms and confirmed the issue was intermittent, with successful Beacon activity still being observed. 3. **Technical Investigation Performed:** Teams reviewed the affected Beacon request path, timeout behavior, backlog growth, and related backend errors to isolate the cause. 4. **Corrective Action Applied:** The affected backend service and related authentication components were restarted to restore normal processing behavior. 5. **Recovery Validated:** Teams confirmed that Beacon upload and download functionality had recovered and that impacted backlogs were clearing. 6. **Post-Recovery Monitoring Continued:** Teams continued monitoring after restoration to confirm continued stability. **Future Preventative Measures** This incident highlighted the importance of continued resilience for services supporting Beacon upload and download workflows, particularly when processing delays or backlog growth occur. Based on the investigation, the following follow-up activities have been identified: 1. **Connection Handling Review:** Review connection handling behavior for the backend service supporting Beacon processing to reduce the likelihood of similar issues recurring. 2. **Processing Resilience Review:** Evaluate opportunities to improve resilience when Beacon-related requests take longer than expected to complete. 3. **Beacon Workflow Validation Review:** Review validation steps for Beacon upload and download workflows following major operational activities, including disaster recovery testing.

Read the full incident report →

Started May 15, 2026, 05:11 PM UTC· resolved May 26, 2026, 04:39 AM UTC

1. investigating May 15, 2026, 05:11 PM UTC

   Incident Description: We are investigating reports of delayed updates for IT Visibility inventory data in the North America region. Some customers may observe recent inventory import activity showing a timeout status or delays in updated data becoming available within the application. Priority: P2 Restoration Activity: Our technical teams are actively reviewing the reported behavior to confirm the current scope of impact and validate customer-facing data availability. We are continuing to monitor the situation closely and will provide further updates as the investigation progresses.

2. investigating May 15, 2026, 06:44 PM UTC

   Our technical teams are actively reviewing the import processing workflow to identify where the reported timeout behavior is occurring and determine the appropriate remediation path. We are continuing to monitor the environment and will provide another update as the investigation progresses.

3. identified May 15, 2026, 10:13 PM UTC

   We have identified a potential underlying issue that may cause some IT Visibility inventory imports to show a timeout status. A fix has been put in place, and our technical teams are reprocessing affected inventory data. We are continuing to monitor progress and validate recovery. Further updates will be provided as reprocessing continues.

4. monitoring May 16, 2026, 07:32 AM UTC

   All uploads from the past days have now been processed successfully. Our teams will continue to closely monitor upcoming uploads over the weekend to ensure processing completes within expected timeframes and services remain stable.

5. monitoring May 17, 2026, 01:36 AM UTC

   We are continuing to monitor IT Visibility inventory data processing. During validation, additional processing errors were identified that are delaying completion for some inventory updates. Recovery efforts are continuing, and we are validating the remaining affected processing activity to confirm inventory updates complete successfully. We will continue to provide updates as recovery and validation continue.

6. monitoring May 17, 2026, 09:19 AM UTC

   Processing across all organizations has returned to normal, and the backlog has been fully cleared. New imports are now completing successfully, and the platform is operating within expected levels. Some customers may continue to see certain historical imports displayed as timed out in the UI. This is expected behavior for imports that exceeded the UI timeout threshold during the recovery period and does not necessarily indicate an active processing issue. Our teams continue to closely monitor the environment to ensure ongoing platform stability and successful processing of new imports.

7. monitoring May 18, 2026, 10:23 AM UTC

   Our teams continue to closely monitor the environment to ensure ongoing platform stability and the successful processing of new imports. A small subset of customers may continue to experience delays in the processing of new imports. Our technical teams are actively investigating the underlying cause of the slowness and are working to implement a resolution as quickly as possible.

8. monitoring May 18, 2026, 08:20 PM UTC

   Processing behavior has improved, and our teams continue to monitor the environment and validate recent import activity. Some previously affected imports are now processing successfully, and technical teams continue to review remaining slow-processing behavior to ensure new imports complete as expected. We will provide another update as validation continues.

9. monitoring May 19, 2026, 04:05 PM UTC

   Processing behavior continues to improve, and previously delayed inventory updates are continuing to progress. Our technical teams have made additional changes to improve processing performance and visibility. We are continuing to monitor progress, validate recent activity, and ensure inventory updates continue moving toward current processing. Further updates will be provided as validation continues.

10. monitoring May 20, 2026, 05:53 PM UTC

    We are continuing to investigate delayed IT Visibility inventory data updates. Our technical teams are reviewing the data ingestion process for affected inventory sources, as some updates are not being consistently received or reflected in the application. We are actively assessing the scope of impact and will provide further updates as more information becomes available.

11. monitoring May 21, 2026, 09:44 AM UTC

    Our technical teams continue to investigate reports of intermittent issues affecting certain uploads and ingestion activity. Current findings suggest this behavior may be related to a separate issue, though investigation and validation are still ongoing to determine the overall scope of impact. We will provide further updates as more information becomes available.

12. identified May 21, 2026, 10:37 PM UTC

    Our technical teams have made changes to the data ingestion flow, and initial validation shows recent inventory updates are moving through the expected processing path. We are continuing to validate recent activity and monitor for any remaining delays as processing continues. Further updates will be provided as validation continues.

13. identified May 22, 2026, 10:03 AM UTC

    Our technical teams continue to monitor the environment and validate recent inventory processing activity following the changes made to the data ingestion flow. At this time, we are awaiting further updates from the technical teams as investigation and validation efforts continue. Further updates will be shared as more information becomes available.

14. identified May 23, 2026, 10:21 AM UTC

    Our technical teams continue to closely monitor the environment and validate recent inventory processing activity following the changes implemented within the data ingestion flow. Investigation and validation efforts remain ongoing, and we are currently awaiting additional updates from the technical teams. Further updates will be provided as more information becomes available.

15. identified May 25, 2026, 12:00 PM UTC

    Our technical teams continue to actively investigate the issue while closely monitoring the environment and validating recent system activity following the implemented changes. Investigation and validation efforts remain ongoing, and we are currently awaiting additional findings and updates from the technical teams. Further updates will be shared as more information becomes available.

16. resolved May 26, 2026, 04:39 AM UTC

    Our investigation has been completed, and the issue has now been declared resolved based on current system behavior and validation results. Platform activity and processing have returned to expected levels, and our teams have confirmed stability across the broader environment. Based on current observations and available data, a small number of customers continue to experience isolated processing slowness. These cases appear to be limited in scope and are being tracked separately by the relevant technical teams, who are actively working toward resolution. At this time, no broader impact has been identified, and monitoring activities will continue to ensure ongoing platform stability.

17. postmortem Jun 10, 2026, 06:25 AM UTC

    **Description:** Flexera One - IT Visibility - US - Delayed Inventory Data Updates **Timeframe:** May 15, 2026, 8:40 AM PDT - May 25, 2026, 9:08 PM PDT **Incident Summary** On May 15, 2026, at approximately 8:40 AM PDT, we received customer reports of delayed IT Visibility inventory data updates in the North America production environment. The reports were received after a previous backlog-related incident had been closed. Some customers continued to observe inventory imports displaying a timeout status, while others reported delays in updated inventory data becoming available within the application. Technical teams investigated the reported behavior to determine whether the issue was related to residual processing activity from the previous incident, a recurrence of earlier processing delays, or a separate import status or processing concern. During the investigation, technical teams identified processing-related conditions that contributed to delayed completion for some inventory imports. This included processing slowness and errors in supporting services that could prevent some inventory processing activity from completing within expected timeframes. Corrective actions were applied to improve processing behavior, and affected processing activity was reviewed and reprocessed where needed. Technical teams continued validating reported customer examples and monitoring new inventory processing activity to confirm recovery. By May 28, 2026, at approximately 9:08 PM PDT, broader platform activity and processing had returned to expected levels, and the incident was considered resolved. **Root Cause** The incident was caused by multiple contributing factors affecting the timely processing and availability of updated IT Visibility inventory data. Some inventory imports experienced delayed completion due to processing slowness and errors in supporting services. As a result, updated inventory data was delayed in becoming available within IT Visibility for some customers. In addition, some imports displayed a timeout status when processing took longer than expected. In some cases, this timeout status did not indicate that processing had stopped, as processing could continue in the background and complete later. **Remediation Actions** The following actions were taken during the incident response: 1. **Incident Response Initiated:** Technical teams began investigating after customer reports were received regarding timeout status behavior and delayed inventory data updates. 2. **Customer Reports Reviewed:** Reported customer examples and related support cases were reviewed to validate the scope and current behavior. 3. **Processing Activity Validated:** Technical teams reviewed inventory processing activity to determine whether timeout statuses reflected active processing delays or status behavior after processing had continued in the background. 4. **Processing Fix Applied:** A corrective fix was implemented for an identified issue that could contribute to timeout behavior, and affected processing activity was reprocessed. 5. **Supporting Service Errors Investigated:** Technical teams identified errors in supporting services that were contributing to delayed processing completion and engaged the appropriate teams for review and recovery. 6. **Processing Recovery Monitored:** Teams monitored affected processing activity and confirmed that delayed processing continued improving as recovery progressed. 7. **Customer Examples Validated:** Technical teams continued validating reported customer examples to confirm whether updated inventory data was progressing as expected. 8. **Post-Recovery Monitoring Performed:** Teams continued monitoring platform activity and inventory processing behavior before declaring the incident resolved. **Future Preventative Measures** This incident highlighted opportunities to improve visibility, monitoring, and recovery handling for IT Visibility inventory processing. The following follow-up areas are being reviewed: 1. **Inventory Processing Reliability:** Technical teams are reviewing improvements to strengthen inventory processing reliability and reduce the likelihood of similar delays. 2. **Monitoring and Observability:** Additional monitoring improvements are being evaluated to provide earlier visibility into processing delays, timeout patterns, backlog, and lack of processing progress. 3. **Import Status Clarity:** Teams are reviewing import status behavior to help reduce confusion when processing takes longer than expected but may still continue in the background. 4. **Operational Readiness:** Teams are reviewing operational improvements to support faster investigation, clearer internal visibility, and more consistent recovery handling for similar issues in the future.

Read the full incident report →

Started May 13, 2026, 02:49 PM UTC· resolved May 13, 2026, 05:02 PM UTC

1. investigating May 13, 2026, 02:49 PM UTC

   Incident Description: We are currently investigating degraded performance affecting Spot Elastigroup for AWS customers. Impacted customers may experience slower page load times and may be unable to create new Elastigroups. Priority: P2 Restoration Activity: Our technical teams are actively investigating and working to restore normal functionality. Current findings indicate the impact is limited to AWS customers. Validation is ongoing to confirm the full scope of impact.

2. identified May 13, 2026, 03:45 PM UTC

   We have identified that the issue may be related to a recent change affecting Spot Elastigroup functionality for AWS customers. Our technical teams are actively reverting the change as part of the restoration effort. Initial validation indicates that Elastigroup creation is now working again. We are continuing validation to confirm full recovery, including page load performance and Elastigroup creation behavior.

3. monitoring May 13, 2026, 04:46 PM UTC

   Our technical teams have completed initial restoration actions, and validation confirms that Elastigroup creation is now working successfully. We are continuing to monitor page load performance and overall functionality before confirming full resolution.

4. resolved May 13, 2026, 05:02 PM UTC

   Our technical teams have confirmed that all affected functionality has been fully restored. Validation has completed successfully, including Elastigroup creation and page load performance. We are marking this incident as resolved and will continue standard monitoring.

5. postmortem May 26, 2026, 05:53 PM UTC

   **Description:** Spot Elastigroup – AWS – Page Load Delays and Creation Issues **Timeframe:** May 13, 2026, 7:29 AM PDT to May 13, 2026, 9:38 AM PDT ‌ **Incident Summary** ‌ On Wednesday, our teams identified an issue affecting AWS Elastigroup functionality that impacted Spot Elastigroup for AWS customers, resulting in delays when loading the Elastigroup page and preventing some customers from creating new Elastigroups. The impact was limited to AWS Elastigroup functionality, and validation confirmed that other services were not affected. Technical teams immediately initiated an investigation, reviewing recent platform changes and service behavior. During the investigation, they observed instability in services that correlated with the customer-facing symptoms. In response, teams executed mitigation actions, including reverting a recently introduced change while concurrently validating system behavior and overall service health. Following the rollback, validation confirmed that Elastigroup creation functionality had been successfully restored. Additional performance validation and monitoring confirmed that service behavior had returned to expected levels, with no further customer impact observed. Full functionality was restored by 9:38 AM PDT. ‌ **Root Cause** ‌ The issue was caused by a recently introduced change that resulted in instability within the AWS Elastigroup processing path. This behavior affected service interactions required for Elastigroup page loading and new Elastigroup creation requests, leading to increased latency and request failures for impacted customers. Contributing Factors: * The change unexpectedly affected a broad AWS workload scope, increasing the overall impact radius. * Existing monitoring did not provide early detection for repeated pod restart behavior. * Existing alerting mechanisms did not immediately identify the developing service degradation. ‌ **Remediation Actions** ‌ The following remediation actions were taken to restore service: * Investigated customer-reported Elastigroup page loading delays and creation failures. * Reviewed system behavior and service restart activity impacting the AWS processing path. * Reverted the recently introduced change. * Performed validation of Elastigroup creation workflows through automated testing. * Conducted additional performance validation and environment monitoring to confirm stability. ‌ **Future Preventative Measures** ‌ 1. Improved Deployment Safeguards - Strengthen deployment controls through stricter practices and introduce automatic rollback mechanisms when latency or error thresholds are exceeded. 2. Defined Rollback Strategy – Review and standardize rollback playbook with clearly defined triggers, including error-rate and latency thresholds, to enable faster mitigation during service degradation events. 3. Enhanced Service Health Monitoring - Implement additional alerting and monitoring for continuous pod restart activity to improve early detection and reduce response times for emerging issues.

Read the full incident report →

Started May 11, 2026, 03:31 AM UTC· resolved May 15, 2026, 04:42 AM UTC

1. investigating May 11, 2026, 03:31 AM UTC

   Incident Description: We are investigating an issue impacting IT Visibility (ITV) services in the US Production environment. Affected customers may experience delays in normalized inventory updates appearing in ITV . Priority: P2 Restoration Activity: Our technical teams have identified that a backend service is experiencing elevated request throttling from an upstream cloud provider dependency, resulting in delayed inventory processing. Teams are actively investigating the issue and working to restore normal processing. We are monitoring the environment closely and will continue to provide updates as progress is made toward full restoration.

2. monitoring May 11, 2026, 05:06 AM UTC

   Our technical teams have successfully designed and implemented a fix. Services are now operating normally, and backlog processing is underway for the data accumulated during the incident.

3. monitoring May 11, 2026, 11:16 AM UTC

   Our technical teams continue to work through the backlog recovery process. Recovery activities are being carried out cautiously to avoid overwhelming downstream services and to ensure platform stability throughout the restoration process.

4. monitoring May 11, 2026, 04:58 PM UTC

   Backlog processing continues to make steady progress following the previously deployed fix. The platform remains stable, and recovery activities are being carefully managed to ensure delayed inventory data is processed safely without impacting downstream services. Customers may continue to experience delays in updated inventory data appearing during this recovery period. We will continue to monitor progress and provide further updates as appropriate.

5. monitoring May 12, 2026, 02:39 PM UTC

   Backlog processing remains in progress, and the platform continues to operate in a stable state. Recovery activities are being carefully managed to ensure delayed inventory data is processed safely while maintaining overall service stability. We will continue to monitor progress and provide additional updates as recovery continues.

6. monitoring May 13, 2026, 12:45 AM UTC

   Backlog processing continues, and the platform remains stable. The system is keeping up with incoming data while previously delayed inventory data is being processed in a controlled manner to ensure overall service stability. We will continue to monitor progress and provide additional updates as recovery continues.

7. monitoring May 13, 2026, 10:21 AM UTC

   Our technical teams continue to closely monitor recovery progress. The system is steadily processing the existing backlog in a controlled manner, with priority placed on maintaining platform stability. We will continue to provide updates as recovery progresses or if there are any material changes.

8. monitoring May 13, 2026, 04:07 PM UTC

   Most data is now being processed successfully, and the platform continues to operate in a stable state while keeping up with incoming data. A small amount of remaining backlog is still being worked through, with recovery activities managed carefully to maintain overall service stability. We will continue to monitor progress and provide additional updates as recovery completes.

9. monitoring May 14, 2026, 06:54 AM UTC

   Processing continues following an overnight service restart that required a portion of data to be replayed. Most organizations are now processing within approximately one hour of real time, and the remaining backlog continues to reduce steadily. Our teams are actively monitoring the environment to ensure full recovery and continued platform stability.

10. monitoring May 15, 2026, 01:30 AM UTC

    Most data processing has completed, and the platform continues to operate in a stable state while keeping up with incoming data. Our teams are performing final validations to confirm everything is functioning as expected. We will provide a final update once these validations are complete.

11. resolved May 15, 2026, 04:42 AM UTC

    All backlog processing has been completed and services remain stable. This issue has now been resolved. Our teams will continue to monitor the platform to ensure ongoing stability. Further details will be shared in a post mortem report.

12. postmortem May 29, 2026, 10:46 AM UTC

    **Description:** Flexera One- IT Visibility- US Prod - Degraded performance **Timeframe:** May 10, 2026, 8:12 PM PDT to May 14, 2026, 07:25 PM PDT ‌ **Incident Summary** ‌ On Sunday, May 10 , 2026, at 8:12 PM PDT , our teams detected an issue impacting IT Visibility \(ITV\) services in the US region where the affected customers experienced delays in normalized inventory processing and delivery to ITV UIs and APIs. The issue originated within the normalization persistence layer, where the service encountered repeated failures while initializing streaming clients used for communication. During initialization, the service generated a large number of API requests in a short period of time, which exceeded account throttling limits. As a result, the service repeatedly restarted and was unable to consistently process and persist normalized inventory data. Our technical teams identified the contributing factors, implemented mitigation measures, and deployed code improvements designed to reduce API request spikes and improve service resiliency during startup and recovery conditions. Following deployment of the fixes, services stabilized and backlog processing was initiated in a controlled manner to avoid downstream system impact. Recovery progressed steadily, and all backlog processing was successfully completed by May 14, 2026, at 07:25 PM PDT. ‌ **Root Cause** ‌ * The incident was caused by excessive API requests generated during streaming client initialization within the normalization writer service. The request volume exceeded throttling limits, preventing successful initialization and causing the service to repeatedly restart. Contributing Factors: * The production US environment had significantly scaled up, increasing the number of streaming clients initialized during service startup. * Separate streaming clients were created per organization across multiple collections, resulting in unexpectedly high API calls during each pod restart. * Failure handling logic caused the service to terminate immediately instead of retrying gracefully, amplifying restart frequency and additional request spikes. ‌ **Remediation Actions** ‌ The following remediation activities were completed to restore service stability: * Implemented staggered streaming client initialization to reduce API request spikes during service startup. * Added retry logic with exponential backoff around streaming client creation and authentication requests. * Replaced failure handling with graceful recovery and retry mechanisms. * Stabilized normalization services and resumed backlog processing in a controlled manner. * Closely monitored recovery activities to ensure downstream platform stability during backlog replay. ‌ **Future Preventative Measures** * Introduce rate limiting controls for external dependency initialization workflows. * Enhance resiliency standards for service startup and dependency authentication handling. * Improve observability and alerting around throttling conditions. * Review scalability assumptions and startup behavior for high-scale growth scenarios. * Conduct additional resiliency testing focused on restart and dependency throttling conditions.

Read the full incident report →

Started May 08, 2026, 10:44 PM UTC· resolved May 09, 2026, 09:47 AM UTC

1. investigating May 08, 2026, 10:44 PM UTC

   Incident Description: We are investigating a service degradation affecting Flexera One customers in the NAM region. Customers may experience intermittent errors, delayed page loading, or pages remaining in a loading state when accessing certain areas of the application, including Cloud Cost Optimization functionality and Administration > Shared Settings. Some Cloud Cost Optimization customers may also experience delays in cost data processing. Priority: P2 Restoration Activity: Our technical teams are actively investigating and validating the affected areas. We are also monitoring upstream service provider disruptions that may be contributing to the issue. We will continue to monitor service behavior and work toward restoration. We will provide another update as soon as additional information is available.

2. monitoring May 09, 2026, 08:29 AM UTC

   Our technical teams are actively investigating and validating the affected areas while continuing to monitor overall service behavior. Initial findings suggest the issue may have been influenced by a service provider disruption, which has now been resolved. We are continuing to assess any residual impact and closely monitoring the platform to ensure stability. Further updates will be provided as more information becomes available.

3. resolved May 09, 2026, 09:47 AM UTC

   Our technical teams have completed validation of the affected areas and confirmed that services have been fully restored. The platform is now operating normally, and we are continuing to monitor to ensure sustained stability. This issue is considered resolved, and further details will be shared in a post-mortem report.

4. postmortem May 26, 2026, 05:38 AM UTC

   **Description:** Flexera One – Cloud Cost Optimization – NAM – Intermittent Service Degradation and Cost Data Processing Delays **Timeframe:** May 7, 2026, 11:49 PM PDT – May 8, 2026, 8:04 PM PDT **Incident Summary** On May 7, 2026, at approximately 11:49 PM PDT, an issue was identified affecting Flexera One Cloud Cost Optimization customers in the North America region. During the affected period, some customers may have experienced intermittent errors when accessing Cloud Cost Optimization functionality through the Flexera One user interface. Some customers may also have experienced delays in cost data processing. The issue was identified through internal technical observations, including increased Cloud Cost Optimization cost API request failures and data processing delays, rather than through widespread customer reports. The incident was initially investigated as a broader Flexera One service degradation because intermittent loading behavior was being reviewed across multiple areas of the platform during the same period. As a precaution, additional components were included in the initial customer communications while technical teams validated the affected areas and determined whether the reported behaviors were related to the same underlying service provider disruption. Further investigation confirmed that the service provider disruption was associated with the Cloud Cost Optimization impact described in this report. Other service behavior reviewed during the investigation was determined to be separate from the service provider disruption and was handled through separate investigation and tracking. Technical teams continued monitoring Cloud Cost Optimization service behavior while the upstream disruption was being addressed. After the service provider disruption was resolved, technical teams validated Cloud Cost Optimization functionality and confirmed that services had recovered. By May 8, 2026, at approximately 8:04 PM PDT, the incident was considered resolved. **Root Cause** The incident was caused by a disruption affecting an upstream service provider. As a result, Cloud Cost Optimization experienced intermittent cost API request failures and data processing delays in the North America region. **Remediation Actions** The following actions were taken during the incident response: 1. **Incident Investigation Initiated:** Technical teams began investigating intermittent errors and cost data processing delays affecting Cloud Cost Optimization customers in the North America region. 2. **Internal Observations Reviewed:** Technical teams reviewed internal observations, including increased Cloud Cost Optimization cost API request failures and data processing delays. 3. **Initial Scope Reviewed:** Because intermittent loading behavior was being reviewed across multiple areas of Flexera One during the same period, the incident was initially assessed as a broader platform service degradation. 4. **Customer Communications Posted:** Additional components were included in the initial customer communications as a precaution while technical teams validated the confirmed scope of impact. 5. **Service Provider Disruption Identified:** Technical teams determined that the confirmed Cloud Cost Optimization impact was associated with an upstream service provider disruption. 6. **Impact Assessment Performed:** Technical teams assessed Cloud Cost Optimization API request behavior, Flexera One user interface behavior, and cost data processing delays. 7. **Additional Service Behavior Reviewed:** Additional service behavior reported during the same period was reviewed to determine whether it was related to the same service provider disruption. This behavior was determined to be separate from the service provider disruption and was handled through separate investigation and tracking. 8. **Monitoring Continued:** Technical teams continued monitoring Cloud Cost Optimization service behavior while the upstream service provider disruption was being addressed. 9. **Recovery Validated:** After the upstream service provider disruption was resolved, technical teams validated Cloud Cost Optimization functionality and confirmed recovery before resolving the incident. **Future Preventative Measures** This incident highlighted the importance of continued validation when multiple service behaviors are reported during a broader upstream service provider disruption. Based on the investigation, the following follow-up activity has been identified: 1. **Incident Triage and Component Validation Review:** We will review how related service reports are assessed during broad upstream service provider disruptions to ensure affected components are validated and updated as additional information becomes available. This includes continuing to refine triage practices so customer communications remain aligned with the confirmed scope of impact.

Read the full incident report →

Started May 08, 2026, 03:00 AM UTC· resolved May 09, 2026, 05:23 AM UTC

1. identified May 08, 2026, 03:00 AM UTC

   Incident Description: We are currently investigating multiple issues impacting SPOT services. Customers may experience database connectivity issues and reduced request handling capacity. Initial findings indicate that the issue is related to an ongoing disruption within our cloud service provider, specifically in the us-east-1 region. As a result, customers may face difficulties launching instances, resulting in degraded service performance. Priority: P2 Restoration Activity: Our technical teams are actively engaged and are working with the service provider to monitor the ongoing regional issue. We are assessing the impact on dependent services, including database connectivity and request processing, while identifying potential mitigation options. Further updates will be provided as more information becomes available and as service stability improves.

2. monitoring May 08, 2026, 06:11 AM UTC

   Our teams have implemented mitigation measures to address the impact from the external service disruption, and services have now been restored. We are actively monitoring the platform to ensure continued stability and will provide further updates as more information becomes available.

3. monitoring May 08, 2026, 08:25 AM UTC

   Some customers may experience residual issues following the recent fix. Our technical teams are actively working to address these and ensure full service stability. We will provide further updates as more information becomes available.

4. monitoring May 08, 2026, 07:39 PM UTC

   Our technical teams have taken measures to address the earlier service impact, and Spot services have remained stable for the last several hours. We have not observed any recurrence of customer-facing impact, and instance provisioning behavior continues to operate as expected. We are continuing to monitor the environment and the service provider’s updates closely. The incident will remain in monitoring for the next few hours, with closure to follow once this additional monitoring period is complete.

5. resolved May 09, 2026, 05:23 AM UTC

   Following an extended period of monitoring, our teams have confirmed that services have remained stable. The external service provider has also confirmed full resolution of their outage. This incident is now resolved, and a detailed post-mortem report will be shared with additional insights.

6. postmortem May 13, 2026, 10:22 AM UTC

   **Description:** Flexera- Spot- US east- 1a- Database connection and low request issues **Timeframe:** May 7, 2026, 4:25 PM PST to May 8, 2026, 7:04 PM PST ‌ **Incident Summary** ‌ On May 7, 2026, Flexera identified a service degradation impacting Spot services in the US East 1a region. During the impact duration, customers experienced difficulties launching instances. In addition, some backend services experienced reduced request handling capacity and intermittent database connectivity issues, resulting in degraded provisioning behavior and delayed scaling operations. Initial investigation determined that the issue coincided with a broader disruption affecting an external cloud infrastructure provider. The external disruption introduced elevated latency and intermittent service instability across dependent infrastructure components, which contributed to degraded provisioning and backend service performance within the Spot platform. During the investigation, engineering teams also identified a database issue caused by the service provider outage that posed a potential performance risk under degraded infrastructure conditions. The issue was mitigated early in the response process, and system stability improved following remediation actions. Throughout the incident, technical teams continuously monitored service health, validated provisioning behavior, and assessed mitigation options to minimize customer impact while the external provider disruption remained active. Over several hours following mitigation, Spot services remained stable with no recurrence of customer-facing issues observed. After an extended monitoring period confirmed continued stability, the incident was considered resolved following confirmation that the underlying external provider disruption had been fully remediated on May 8, 2026, at 7:04 PM PST. ‌ **Root Cause** ‌ The issue was primarily caused by a disruption affecting an external cloud infrastructure provider supporting services in the US East 1a region. The disruption resulted in increased latency, intermittent connectivity issues, and degraded infrastructure performance, which impacted Spot instance provisioning operations and related backend services. Contributing Factors: * Elevated latency and intermittent failures across dependent infrastructure services increased provisioning delays and request instability. * A database performance issue, triggered by the underlying service provider disruption, introduced additional load under degraded infrastructure conditions and increased the risk of intermittent service instability. * The prolonged nature of the external provider disruption extended the duration of customer impact and required continuous monitoring and mitigation activities. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Investigated and monitored infrastructure and provisioning service behavior across impacted Spot components. * Identified and mitigated a database performance degradation contributing to elevated performance risk. * Validated provisioning stability and backend service recovery following mitigation efforts. * Performed extended monitoring to ensure sustained service stability and confirm the absence of recurring customer impact. ‌ **Future Preventative Measures** ‌ * Alerting Reliability Improvements: Improve alert delivery validation and monitoring to ensure critical database alerts are consistently propagated across all operational notification channels, including collaboration and incident management platforms. * Regional Resilience Evaluation: Evaluate additional regional resilience and failover capabilities to reduce the impact scope of regional infrastructure disruptions. Any future implementation will be subject to cost-impact analysis and internal approval processes. * Third-Party Provider Escalation Process: Enhance operational procedures for third-party infrastructure incidents by establishing earlier escalation and engagement processes with external cloud service providers during active service disruptions.

Read the full incident report →

Started May 07, 2026, 04:48 PM UTC· resolved May 07, 2026, 07:38 PM UTC

1. investigating May 07, 2026, 04:49 PM UTC

   Incident Description: We are currently investigating an issue affecting Beacon connectivity in the Flexera One IT Asset Management application in the North America region. Customers using Beacon may experience connectivity errors when attempting to upload inventory data or download Beacon-related updates. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and working to restore normal Beacon upload and download functionality. We will provide updates as more information becomes available.

2. identified May 07, 2026, 06:07 PM UTC

   Our technical teams have identified the issue as a routing/configuration problem affecting Beacon communication following recent maintenance activity in the North America environment. This is preventing Beacon from successfully completing upload and download requests. Teams are working on the required configuration update to restore Beacon connectivity. We will provide another update as restoration work continues.

3. resolved May 07, 2026, 07:38 PM UTC

   Technical teams completed the required updates to restore communication through the affected service path in the North America environment. Upload and download requests are now completing successfully, and functionality has been validated. We will continue monitoring to ensure the service remains operational. This incident has been resolved.

4. postmortem May 21, 2026, 06:52 AM UTC

   **Description:** Flexera One – IT Asset Management – North America – Beacon Connectivity Issues **Timeframe:** Wednesday, May 6, 2026, 9:33 PM PDT – Thursday, May 7, 2026, 11:35 AM PDT ## Incident Summary On Wednesday, May 6, 2026, at approximately 9:33 PM PDT, a scheduled backend infrastructure change was performed in the North America production environment. Following this change, an issue was introduced that affected Beacon connectivity for Flexera One IT Asset Management customers in the North America region. During the affected period, customers experienced failures when attempting to upload or download data through Beacon. The issue affected Beacon API and configuration service connectivity, preventing successful uploads and downloads across the US production environment. The following morning, technical teams began investigating the issue after customer reports were received. During the investigation, it was identified that a configuration introduced during the infrastructure change was directing Beacon traffic to an incorrect backend path, preventing successful connectivity. Once the configuration was corrected, Beacon uploads and downloads began processing successfully. Multiple customers confirmed successful Beacon connectivity following the fix. By Thursday, May 7, 2026, at approximately 11:35 AM PDT, service was confirmed restored and the incident was considered resolved. Affected Beacon uploads would have automatically retried following service restoration. Technical teams continued monitoring following restoration to ensure recovery progressed as expected. ## Root Cause The incident was caused by a backend infrastructure change that introduced a configuration mismatch in the North America production environment. As a result, Beacon connectivity requests were directed to an incorrect backend path, causing all Beacon uploads and downloads to fail during the affected period. Once the configuration was corrected to point to the appropriate path, connectivity was restored. ## Remediation Actions The following actions were taken during the incident response: 1. **Configuration Corrected:** The affected configuration was updated to restore Beacon connectivity to the correct backend path. 2. **Beacon Connectivity Validated:** Technical teams confirmed that Beacon uploads and downloads were processing successfully following the correction. 3. **Customer Confirmation Received:** Multiple customers confirmed successful Beacon connectivity. 4. **Post-Restoration Monitoring Performed:** Recovery activity was monitored after restoration to ensure services continued operating as expected. ## Future Preventative Measures The following follow-up actions were identified during the incident: 1. **Cross-Team Change Coordination:** We are reviewing coordination procedures between teams involved in backend infrastructure changes to ensure that dependent services are validated before and after changes are applied. 2. **Remaining Region Updates:** Configuration updates for other regions are being coordinated as part of upcoming scheduled releases to ensure consistency and prevent similar occurrences.

Read the full incident report →

Started Apr 29, 2026, 06:33 PM UTC· resolved Apr 29, 2026, 06:33 PM UTC

1. resolved Apr 29, 2026, 06:33 PM UTC

   Incident Description: We experienced an issue affecting Flexera One SaaS Manage in the NAM region. During the impact window, affected customers may have been unable to access the application. Priority: P1 Restoration Activity: Our technical teams identified the issue and completed the required restoration activities. Access has been restored, and we will continue to monitor the environment to ensure continued stability. A formal retrospective will be conducted to review the root cause, actions taken during the incident, and any long-term preventative measures. A postmortem report summarizing those findings will be shared following the retrospective.

2. postmortem May 13, 2026, 03:53 AM UTC

   **Description:** Flexera One SaaS Manager – NAM – Application Access Disruption **Timeframe:** April 29, 2026, 3:00 AM PDT – April 29, 2026, 7:30 AM PDT ## Incident Summary On April 29, 2026, at approximately 3:00 AM PDT, an issue was identified affecting access to Flexera One SaaS Manager in the North America production environment. During this period, affected customers were unable to access SaaS Manager. The issue impacted most customer tenants in the NAM region and was related to an internal SaaS Manager configuration update process that did not complete as expected for affected organizations. Technical teams investigated the issue and identified that a high volume of internal SaaS Manager configuration updates had been triggered for customer organizations within a short period of time. These updates did not complete within the expected timeframe, causing affected organizations to remain in an updating state and preventing access to SaaS Manager. As part of the recovery effort, technical teams increased processing capacity for the affected update process and worked through the pending configuration updates. Once the pending updates were completed, affected organizations were no longer in an updating state and access to SaaS Manager was restored. By April 29, 2026, at approximately 7:30 AM PDT, access had been restored for affected customers. Following validation that SaaS Manager access had returned to expected operation, the incident was considered resolved. ## Root Cause The incident was caused by a high volume of internal SaaS Manager configuration updates for customer organizations that did not complete within the expected timeframe. While these updates remained pending, affected customer organizations were left in an updating state, which prevented access to SaaS Manager during the incident window. ## Remediation Actions The following actions were taken during the incident response: 1. **Incident Investigation Initiated:** Technical teams began investigating reports of SaaS Manager access issues affecting customers in the North America region. 2. **Impact Scope Reviewed:** The issue was confirmed to affect most customer tenants in the NAM region. 3. **Configuration Update Processing Reviewed:** Technical teams identified that a high volume of internal SaaS Manager configuration updates had been triggered and were not completing within the expected timeframe. 4. **Processing Capacity Increased:** Technical teams increased processing capacity for the affected update process to help complete the pending configuration updates. 5. **Pending Updates Completed:** The pending configuration updates were processed for affected organizations. 6. **Access Restoration Completed:** Once the pending updates were completed, affected organizations were no longer in an updating state and access to SaaS Manager was restored. 7. **Service Recovery Validated:** Technical teams confirmed that access to SaaS Manager had returned to expected operation for affected organizations. ## Future Preventative Measures This incident highlighted the importance of improving resilience, capacity handling, and monitoring for high-volume internal configuration update activity that can affect customer access. Based on the investigation, the following follow-up activities are being reviewed: 1. **Capacity Handling Review:** Review processing behavior for high-volume configuration update activity to reduce the likelihood of pending updates affecting customer access. 2. **Update Process Resilience:** Evaluate improvements to how SaaS Manager configuration updates are processed so that customer access is not unnecessarily affected if update activity takes longer than expected. 3. **Monitoring and Alerting Improvements:** Review monitoring opportunities to identify large volumes of pending or delayed configuration updates earlier.

Read the full incident report →

Started Apr 28, 2026, 03:31 PM UTC· resolved Apr 28, 2026, 05:50 PM UTC

1. investigating Apr 28, 2026, 03:31 PM UTC

   Incident Description: We are currently investigating an issue affecting reconciliation processing for Flexera One IT Asset Management in the NA region. While the application remains accessible, affected customers may experience delays in reconciliation completion and related processing activities. Priority: P2 Restoration Activity: Our technical teams are actively engaged and are investigating the cause of the reconciliation processing delays. We are reviewing the affected processing components and working to restore normal processing. Further updates will be provided as more information becomes available.

2. resolved Apr 28, 2026, 05:50 PM UTC

   Our technical teams identified that the reconciliation processing delays were caused by a deployment that occurred while reconciliation tasks were already running. This caused some affected reconciliation jobs to enter a repeated retry state instead of completing as expected, which delayed processing for impacted customers. The issue has been addressed, and newly started reconciliation jobs are completing successfully. Jobs that were stopped as part of recovery will run again based on their normal schedule. We will continue monitoring processing health and are tracking longer-term improvements to reduce the risk of a similar issue occurring again.

3. postmortem May 12, 2026, 05:42 AM UTC

   **Description:** Flexera One – IT Asset Management – NA – Reconciliation Processing Delays **Timeframe:** April 28, 2026, 6:10 AM PDT – April 28, 2026, 10:45 AM PDT **Incident Summary** On April 28, 2026, at approximately 6:10 AM PDT, an issue was identified affecting reconciliation processing within the Flexera One IT Asset Management service in the North America production environment. During this period, the application remained accessible. However, affected customers may have experienced delays in reconciliation completion and related writer job processing. Investigation identified that some writer jobs were blocked while processing reconciliation results, with repeated failures observed during result streaming. Technical teams began investigating immediately and reviewed logs associated with the affected processing flow. The investigation identified repeated attempts to retrieve reconciliation results after streaming errors occurred, resulting in a large volume of repeated errors. Several writer jobs were also observed running longer than expected. As part of the recovery effort, a service restart or redeploy was attempted but did not resolve the issue. Technical teams then identified that a recent service release occurred around the time processing load began increasing. The service was reverted to a previous version as part of the mitigation effort, and further deployment activity was held while the issue was reviewed. Additional recovery actions were taken for writer jobs that were already stuck in an unrecoverable state. These jobs were cleared where needed, while newly started writer jobs were monitored to confirm that they were processing successfully. By April 28, 2026, at approximately 10:45 AM PDT, current writer job processing was confirmed to be completing successfully, and the incident was considered resolved. Any longer-running jobs not related to the affected processing stage continued to be monitored separately. **Root Cause** The incident was caused by writer jobs entering a blocked state while processing reconciliation in the North America production environment. This resulted in repeated failures during result streaming and delayed completion of reconciliation-related writer job processing for affected customers. The issue occurred around the time of a service release, and technical teams identified that a deployment during active reconciliation processing may cause certain writer jobs to enter an unrecoverable error state. When this occurred, retry behavior from the IT Asset Management processing flow continued until the affected jobs timed out or were manually cleared. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Investigation Initiated: Technical teams began investigating delays affecting reconciliation completion and related writer job processing in the North America region. 2. Log Review Completed: Logs were reviewed and showed repeated failures during reconciliation result streaming, including repeated attempts to retrieve results after errors occurred. 3. Blocked Writer Jobs Identified: Technical teams identified that some writer jobs were blocked during reconciliation result processing and had been running longer than expected. 4. Service Restart/Redeploy Attempted: A restart or redeploy of the affected service was attempted but did not resolve the issue, as affected writer jobs had already entered a blocked processing state. 5. Recent Service Release Reverted: A recent service release that occurred around the time processing load increased was reverted to a previous version as part of the mitigation effort. 6. Further Deployment Activity Held: Additional deployment activity was paused while technical teams reviewed the behavior and assessed the safest recovery approach. 7. Stuck Writer Jobs Cleared: Writer jobs that were confirmed to be stuck in an unrecoverable error state were cleared where needed. 8. Processing Recovery Validated: Newly started and current writer jobs were monitored and confirmed to be completing successfully before the incident was resolved. **Future Preventative Measures** This incident highlighted the importance of improving resilience in reconciliation processing when service changes occur during active writer job processing. Based on the investigation, the following follow-up activities are being pursued: 1. Deployment Strategy Review: Review deployment approaches for the affected service to reduce the likelihood of disrupting active reconciliation processing. 2. Retry Behavior Improvements: Review retry behavior for reconciliation-related writer jobs to reduce repeated processing attempts when a job reaches an unrecoverable error condition. 3. Failure Handling Improvements: Evaluate code-side improvements to better detect specific failure patterns and allow affected processing to fail or recover more cleanly.

Read the full incident report →

Started Apr 21, 2026, 09:01 AM UTC· resolved Apr 21, 2026, 09:23 AM UTC

1. investigating Apr 21, 2026, 09:01 AM UTC

   Incident Description: We are currently experiencing an issue affecting SAM Core on Snow Software in the Australia region. Affected users may encounter errors or experience difficulties when attempting to load certain pages within the application. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue. Initial analysis indicates a potential problem within the messaging system that may be contributing to the observed behavior. Further updates will be provided as more information becomes available.

2. resolved Apr 21, 2026, 09:23 AM UTC

   Our teams identified the issue as being caused by a recent deployment. The change has been rolled back, and services have been successfully restored to normal operation.

3. postmortem May 05, 2026, 06:29 AM UTC

   **Description:** Snow Software - Australia - SAM Core \(Snow Atlas\) Errors **Timeframe:** April 21, 2026, 1:35 AM PST to April 21, 2026, 2:05 AM PST ‌ **Incident Summary** ‌ On Tuesday, April 21, 2026, 1:35 AM PST ,customers in the Australia region began experiencing HTTP 500 errors when accessing specific SAM Core functionality, particularly within the Application and License detail views. Although the Snow Atlas portal itself remained accessible, certain features failed to load, disrupting normal user operations. Initial investigation indicated a potential issue in the messaging system, supported by logs from the API service that reported a routing error. As a mitigation step, the route application in the Australia region was restarted at 1:38 AM PST, which led to a temporary improvement in system behaviour. The issue, however, reoccurred shortly thereafter, confirming that the restart did not resolve the underlying problem. Subsequent investigation linked the incident to a recent change associated with regional migration activities between Australia Southeast and Australia East. The team determined this change was a likely contributing factor and initiated a rollback of the prior day’s deployment. Following the rollback, system stability improved, and by 2:05 AM PST, validation with multiple previously impacted customers confirmed that the affected pages were once again functioning as expected. Full service was restored, and the incident was considered resolved. ‌ **Root Cause** ‌ The issue was caused by an unintended side effect of recent changes introduced during the Australia Southeast to Australia East migration, which resulted in a routing failure within the application layer. Contributing Factors: * A recent deployment related to migration cleanup activities introduced instability in routing behavior. * A fatal routing error in the API service disrupted request handling. * Potential interaction with the messaging system contributed to service degradation \(under investigation\). * The issue was not immediately reproducible during initial validation after the change, delaying detection. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Restarted the routing service to attempt initial recovery. * Conducted detailed log analysis to identify routing failures. * Rolled back the prior day’s deployment associated with migration changes. * Validated service recovery with affected customers. ‌ **Future Preventative Measures** ‌ * Enhance validation and monitoring for regional migration-related changes. * Implement additional safeguards and automated checks for routing and messaging dependencies. * Introduce stricter post-deployment verification processes to detect delayed failures. * Conduct a detailed post-mortem to identify any additional contributing conditions and ensure long-term stability.

Read the full incident report →

Started Apr 14, 2026, 12:15 PM UTC· resolved Apr 14, 2026, 12:15 PM UTC

1. resolved Apr 14, 2026, 12:15 PM UTC

   Incident Description: Our teams previously identified an issue impacting the IT Asset Management service in the NAM region, affecting a subset of customers. The issue began on April 12 and was fully resolved on April 13 at 2:21 AM PDT. While the platform remained accessible throughout, some customers experienced intermittent failures when their beacons attempted to communicate with the Flexera One platform. During this time, certain requests returned internal server errors. As a result, impacted customers may have encountered delays or failures in data retrieval processes that rely on beacon connectivity. Priority: P3 Restoration Activity: Our teams identified the underlying cause of the intermittent internal server errors as a resource constraint on a server. Corrective actions were implemented to restore system stability and ensure adequate capacity. Following these actions, beacon communications returned to normal operation. The platform continues to be closely monitored to confirm sustained stability, and additional safeguards are being evaluated to reduce the recurence of similar issues in the future.

2. postmortem May 12, 2026, 09:16 AM UTC

   **Description:** Flexera One - IT Asset Management - NAM - Intermittent 500 error **Timeframe:** April 13, 2026, 1:46 AM PST to Apr 13, 2026, 2:27 AM PST ‌ **Incident Summary** ‌ On Monday, April 13, 2026, at 1:46 AM PST , our teams identified an issue affecting beacon communications for a subset of customers in the NAM region. During the incident window, customers may have experienced intermittent failures when communicating with the Flexera One platform through beacon services, including inventory uploads, downloads, and data import operations. Affected requests returned HTTP 500 \(Internal Server Error\) responses. Our teams also identified that some customers might have experienced the issue intermittently upto a few days before issue detection. The issue was traced to disk space exhaustion on shared storage utilized by the beacon processing infrastructure. Once the available disk capacity was exhausted, the affected services were unable to successfully process beacon-related requests, resulting in intermittent failures. Our technical teams quickly identified the storage exhaustion condition and restored service by expanding disk capacity on the affected infrastructure. Following remediation, beacon communications returned to normal operation and the environment was closely monitored to ensure continued stability. ‌ **Root Cause** ‌ The incident was caused by disk space exhaustion on shared storage used by the beacon processing component. Once the storage became full, beacon processing requests began failing and returning HTTP 500 responses. Contributing Factors * Existing cleanup mechanisms did not fully remove all temporary or residual data generated during processing activities. * Under certain application failure or unexpected processing scenarios, files were retained longer than intended, contributing to accelerated disk utilization growth. * Storage utilization alerts did not trigger as expected due to a recent update introduced on the alerting mechanism. **Remediation Actions** ‌ The following remediation actions were completed during the incident response: * Expanded disk capacity on the affected shared storage infrastructure. * Removed the problematic configuration on the alert notification mechanism to restore alert delivery functionality. * Validated restoration of beacon communications and successful processing of requests. * Monitored the environment following recovery to confirm service stability. ‌ **Future Preventative Measures** ‌ * To reduce the likelihood of recurrence, the following preventative measures are being implemented: * Enhance cleanup and retention mechanisms to ensure all relevant temporary and residual processing files are automatically removed. * Improve storage utilization monitoring and alerting coverage across shared processing infrastructure. * Validate alert delivery configurations after infrastructure changes.

Read the full incident report →

Started Apr 08, 2026, 11:07 AM UTC· resolved Apr 08, 2026, 02:11 PM UTC

1. investigating Apr 08, 2026, 11:07 AM UTC

   Incident Description: We are investigating an issue impacting inventory data uploads for IT Asset Management (ITAM) in the EU region. Affected customers may experience upload failures and related error messages. Priority: P2 Restoration Activity: Our technical teams are actively investigating the cause and working to restore normal upload processing. We are monitoring the environment closely and will continue to share updates as progress is made toward full restoration.

2. resolved Apr 08, 2026, 02:11 PM UTC

   We have identified the issue affecting inventory uploads in the EU region. The disruption was caused by a service responsible for handling communication between components becoming unavailable following an unexpected system event. The service has since been successfully restored, and inventory uploads are now processing as expected. There has been no data loss, as affected uploads will automatically retry and complete. Our teams are actively monitoring the system to ensure stability as processing returns to normal and are investigating the underlying cause of the event. Additional safeguards are also being implemented to help prevent recurrence.

3. postmortem Apr 22, 2026, 03:43 AM UTC

   **Description:** Flexera One – IT Asset Management – EU – Inventory Upload Failures **Timeframe:** April 7, 2026, 10:53 AM PDT – April 8, 2026, 7:45 AM PDT **Incident Summary** On April 7, 2026, at approximately 10:53 AM PDT, an issue began affecting inventory data uploads for Flexera One IT Asset Management in the EU production environment. During this period, customers in the EU region experienced failures when attempting to upload inventory data, which also resulted in delays in downstream data processing. Technical teams began investigating the issue after reports were received of upload failures affecting the EU region. During the investigation, it was confirmed that the upload endpoint was reachable and responding, while customer upload attempts were still failing. Further analysis continued to identify the source of the disruption and determine why uploads were not being processed successfully. The issue was subsequently identified as a required service in the EU production environment being unexpectedly stopped. As a result, upload requests were not processed successfully during the affected period, which caused authentication failures and prevented data from being received for processing. Once the service was restarted, uploads began processing successfully again and recovery activity was monitored. By April 8, 2026, at approximately 7:45 AM PDT, successful uploads had resumed and the incident was considered resolved. It was confirmed during the incident that there was no data loss, as affected uploads would automatically re-upload after service restoration. Technical teams continued monitoring following restoration to ensure recovery progressed as expected. **Root Cause** The incident was caused by a required service in the EU production environment being unexpectedly stopped. This interruption prevented inventory upload requests from being processed successfully, resulting in authentication failures and no data being received for processing during the affected period. Further analysis is underway to determine the cause of the unexpected service interruption. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Investigation Initiated: Technical teams began investigating reports of inventory upload failures affecting the EU region. 2. Endpoint Behavior Reviewed: Technical teams confirmed that the upload endpoint was reachable and responding while further analysis continued to isolate the source of the failure. 3. Cause Identified: Investigation determined that a required service in the EU production environment had been unexpectedly stopped. 4. Service Restarted: The affected service was restarted in the EU production environment. 5. Upload Recovery Validated: Technical teams confirmed that uploads were processing successfully again following service restoration. 6. Post-Restoration Monitoring Performed: Recovery activity and backlog behavior were monitored after restoration. **Future Preventative Measures** The following follow-up actions were identified during the incident: 1. Automatic Service Restart Measures: We are implementing measures to help ensure the affected service starts automatically in the event of a similar occurrence.

Read the full incident report →

Started Apr 02, 2026, 08:50 PM UTC· resolved Apr 07, 2026, 09:36 PM UTC

1. investigating Apr 02, 2026, 08:50 PM UTC

   Incident Description: We have identified an issue affecting CloudCheckr inventory and cost collection across all regions. As a result, some customers may experience delays in inventory and cost data collection. Priority: P2 Restoration Activity: The disruption has been linked to service issues affecting our service provider. Our technical teams are monitoring the situation closely, assessing any downstream impact, and will provide further updates as more information becomes available.

2. identified Apr 03, 2026, 12:12 AM UTC

   Our technical teams continue to monitor the issue affecting CloudCheckr inventory and cost collection across all regions and are assessing the potential for broader impact over the next couple of days as billing-related processing activity increases. We will continue to provide updates as more information becomes available.

3. identified Apr 06, 2026, 06:04 PM UTC

   Our technical teams continue to work on the issue affecting CloudCheckr inventory and cost collection across all regions. A product-side mitigation is now being deployed across CloudCheckr regions to help address the ongoing impact on collection workflows when communication with the affected external region fails. Testing is being finalized, and deployments are in progress across CloudCheckr regions. We will continue to provide updates as more information becomes available.

4. monitoring Apr 07, 2026, 05:42 AM UTC

   Fix deployment has been successfully completed across all regions, and our teams are actively monitoring the services to ensure continued stability and expected performance.

5. resolved Apr 07, 2026, 09:36 PM UTC

   Following the fix deployment across all CloudCheckr regions, the environment has remained stable and technical team validation has confirmed recovery. This incident is now considered resolved.

6. postmortem Apr 22, 2026, 03:42 AM UTC

   **Description:** CloudCheckr – All Regions – Inventory and Cost Collection Delays **Timeframe:** April 1, 2025, 1:00 PM PDT – April 7, 2025, 7:21 AM PDT **Incident Summary** On April 1, 2025, at approximately 1:00 PM PDT, an issue was identified affecting inventory and cost collection within CloudCheckr across all regions. During this period, some customers experienced delays in inventory and cost data collection. During the investigation, technical teams confirmed impact across US, EU, AU, GOV, and HSE regions. The issue was linked to service disruptions affecting an external cloud service provider in Middle East regions. As the incident progressed, technical teams confirmed that the issue was causing failures in discovery workflows and was also impacting billing and invoicing. For customers Technical teams monitored the environment closely while developing and validating a mitigation. A product-side mitigation was then deployed across all CloudCheckr regions to bypass the affected Middle East region on a per-customer basis when communication with that region failed. Following completion of the deployments, technical teams continued monitoring and validating service behavior across regions. By April 7, 2025, at approximately 7:21 AM PDT, recovery had been confirmed, with no remaining concerns at that time regarding data processing, billing, or invoicing, and the incident was considered resolved. **Root Cause** The incident was caused by service disruptions affecting an external cloud service provider in Middle East regions. As a result, CloudCheckr collection workflows encountered timeouts when processing customers with usage in the affected regions, which led to delays in inventory and cost data collection and also impacted billing and invoicing. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Investigation Initiated: Technical teams began investigating delays affecting inventory and cost collection across CloudCheckr regions. 2. External Service Disruption Identified: The issue was linked to service disruptions affecting an external cloud service provider in Middle East regions. 3. Impact Assessment Performed: Technical teams assessed the effect on collection workflows, including discovery, billing, and invoicing. 4. Monitoring Continued: Teams continued to monitor service behavior and customer impact while evaluating mitigation options. 5. Product-Side Mitigation Deployed: A mitigation was deployed across CloudCheckr regions to bypass the affected Middle East region on a per-customer basis when communication with that region failed. 6. Recovery Validated: Following deployment, technical teams monitored the environment and confirmed recovery across all regions before resolving the incident. **Future Preventative Measures** • Resilient Regional Collection Handling: We will further strengthen its collection logic to reduce dependency on a single affected region during external service disruptions. This includes improving how collection workflows detect repeated regional communication failures and continue processing in a way that helps minimize delays to inventory, cost, billing, and invoicing activities across other unaffected regions.

Read the full incident report →

Started Mar 31, 2026, 10:12 PM UTC· resolved Apr 04, 2026, 06:13 AM UTC

1. identified Mar 31, 2026, 10:12 PM UTC

   Incident Description: We are currently investigating an issue affecting third-party inventory imports in Flexera One IT Visibility across all regions. As a result, some customers may experience delays in inventory processing and timeouts during imports. Priority: P2 Restoration Activity: Our technical teams have identified the issue and are actively implementing mitigation steps to restore normal processing. Recovery actions are underway across the affected processing path. As processing resumes, some customers may continue to experience residual delays and timeouts while backlog processing is worked through.

2. identified Mar 31, 2026, 10:39 PM UTC

   Our technical teams have identified the root cause and implemented a hotfix to restore normal data notification flow across the affected regions. Recovery activity is now focused on replaying missed notifications generated during the affected period. As this work continues, some customers may still experience residual delays and timeouts while backlog processing completes.

3. identified Apr 01, 2026, 06:58 AM UTC

   Backlog processing continues to progress at a steady rate following the hotfix implementation. Our teams are actively monitoring the recovery to ensure complete resolution and system stability.

4. identified Apr 01, 2026, 04:15 PM UTC

   Our technical teams continue recovery efforts following the hotfix, and newly submitted inventory packages are progressing through processing as expected. Recovery work is currently focused on addressing missed messages from the affected period and validating the backfill approach for those items. As this work continues, some customers may still experience delays in processing.

5. identified Apr 02, 2026, 04:30 PM UTC

   Our technical teams have completed generation of the retroactive messages needed for recovery and are now validating the replay approach before reingestion begins. This work is being carried out carefully to minimize excessive downstream strain during recovery. Newly submitted inventory packages continue to process as expected, while recovery for missed messages remains in progress.

6. identified Apr 03, 2026, 12:34 PM UTC

   Our technical teams are continuing to validate the replay approach required for reingestion of previously missed messages. Newly submitted inventory packages are processing as expected, and recovery efforts for missed messages remain actively in progress.

7. identified Apr 03, 2026, 06:08 PM UTC

   Our technical teams have completed further validation and confirmed that newly submitted data is now flowing as expected for the affected processing path. Based on this validation, retroactive replay of previously missed messages is not required. Recovery efforts are now focused on confirming full restoration of the remaining impact, and some customers may continue to experience temporary delays until that validation is complete.

8. resolved Apr 04, 2026, 06:13 AM UTC

   Our teams have completed the validation for all remaining organizations and confirmed that services have returned to normal. The incident has been closed, and additional details will be shared in a post-mortem report.

9. postmortem Apr 20, 2026, 05:27 AM UTC

   **Description:** Flexera One – IT Visibility – All Regions – Third-Party Inventory Import Processing Disruption **Timeframe:** March 31, 2026, 3:00 PM PDT to April 3, 2026, 11:12 PM PDT ‌ **Incident Summary** ‌ On Wednesday, March 31, 2026, at 3:00 PM PDT, an issue was identified affecting third-party \(external\) inventory imports within Flexera One IT Visibility across all regions. During the impact window, customers using these external inventory connections experienced delays in inventory processing and timeouts during import operations. The issue was observed across all regions \(NAM, EU, and APAC\), while other inventory ingestion methods remained fully operational. Multiple customer cases were reported, and technical teams initiated an investigation promptly. The issue was traced to disruptions in the inventory processing pipeline, where uploaded data was not advancing through the workflow as expected. After the issue was identified, a hotfix was deployed, restoring normal data flow for newly incoming inventory. While new data began processing successfully, some customers continued to experience delays as previously missed processing events were analyzed and system backlogs were cleared. Subsequent validation confirmed that newer inventory data superseded earlier missed data, removing the need for full reprocessing. Services were fully validated and confirmed to be operating as expected prior to incident closure on 3 Apr 2026, at 11:12 PM PDT. ‌ **Root Cause** ‌ The issue was caused by a missing configuration setting introduced during a recent release, which impacted inventory processing across all regions. This configuration gap resulted in certain processing events not being triggered, preventing uploaded inventory data from progressing through the expected pipeline. Contributing Factors: * Configuration Gap in Release: A required environment setting was not present in production following deployment. * Processing Pipeline Interruption: Missing triggers prevented inventory data from progressing to downstream systems. * Regional Impact Variations: While the issue affected all regions, some regions experienced additional symptoms such as delayed processing queues. * Detection Delay: The issue primarily affected asynchronous processing, which delayed immediate visibility. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Deployed a hotfix to restore the missing configuration across all regions. * Restored normal processing of inventory data for all newly submitted uploads. * Investigated and validated the status of previously impacted data. * Confirmed that newer data submissions correctly updated downstream systems. * Monitored system performance to ensure stability and full recovery. ‌ **Future Preventative Measures** ‌ * Implement Enhanced Release Validation Controls: Ensure all required environment configurations are validated and present prior to production deployment. * Strengthen End-to-End Pipeline Monitoring: Introduce comprehensive monitoring across asynchronous processing flows to detect failures or delays in real time. * Enforce Configuration Consistency Across Regions: Establish safeguards to prevent configuration drift and ensure uniform deployments across all environments. * Processing Gap Detection Alerts: Review and upgrade alerting mechanisms to identify missing or delayed processing events within the ingestion pipeline. * Optimize Recovery and Backlog Handling Procedures: Improve recovery strategies to efficiently handle missed processing events and reduce impact from backlog accumulation.

Read the full incident report →

Started Mar 31, 2026, 08:08 PM UTC· resolved Mar 31, 2026, 09:38 PM UTC

1. investigating Mar 31, 2026, 08:08 PM UTC

   Incident Description: We are investigating an issue affecting Data Explorer within Flexera One IT Visibility in the NA region. Customers may encounter errors when using Data Explorer, and requests may fail to return results as expected. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and working to restore normal functionality. We are closely monitoring progress and will provide further updates as they become available.

2. identified Mar 31, 2026, 08:53 PM UTC

   Our technical teams have identified a potential cause and are actively implementing mitigation steps to restore Data Explorer functionality in the NA region. Current investigation indicates the failure is related to a service-side issue affecting request processing, and rollback actions are currently in progress. We are monitoring the outcome of these changes closely and will provide a further update as soon as more information becomes available.

3. resolved Mar 31, 2026, 09:38 PM UTC

   Rollback actions have been completed successfully, and Data Explorer functionality has been restored in the NA region. Our investigation determined the issue was related to a service-side deployment/configuration problem affecting request processing. Service has been validated following mitigation, and requests are now completing as expected. We will complete a full root cause analysis with the teams involved and provide a post-mortem report outlining the underlying cause and preventive measures identified.

4. postmortem Apr 20, 2026, 06:07 AM UTC

   **Description:** Flexera One – IT Visibility – NA – Data Explorer Request Failures **Timeframe:** March 31, 2026, 12:41 PM PDT to March 31, 2026, 1:56 PM PDT ‌ **Incident Summary** ‌ On Tuesday, March 31, 2026, at 12:41 PM PDT, our teams detected an issue affecting the Data Explorer feature within Flexera One IT Visibility in the NA region. Customers in this region encountered errors when using Data Explorer; requests failed to return results as expected and, in some cases, resulted in HTTP 500 errors, preventing successful query execution. The impact was isolated to Data Explorer functionality in the NA region. Other regions, including EU and APAC, were not affected, and the broader Flexera One platform remained fully accessible throughout the incident. Engineering teams began investigating immediately and determined that the issue originated in a backend service responsible for processing Data Explorer queries. Initial analysis suggested a potential problem with request handling. Subsequent validation confirmed that customer requests were valid and that the failure was occurring service-side within this backend component. The issue was resolved by reverting the affected configuration changes in the backend service, which restored service stability. Post-recovery validation confirmed that Data Explorer queries completed successfully and that normal functionality was fully restored for customers in the NA region. ‌ **Root Cause** ‌ During their investigations, our technical teams identified that the issue was caused by a partial or inconsistent deployment in the NA region. Configuration changes were applied without the corresponding service components being fully deployed. This mismatch caused runtime failures during query processing, resulting in HTTP 500 errors when Data Explorer queries were executed.The issue was not related to authentication or customer-submitted queries, despite initial error messages suggesting otherwise. Contributing Factors: * Partial Deployment State: Configuration updates were applied without matching service binaries. * Service Runtime Failures: The mismatch led to failures during query generation in the backend service. * Misleading Error Messages: UI errors suggested request issues, which delayed precise identification of the service-side cause. * Regional Isolation: The issue was limited to NA due to differences in deployment state across regions. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Reverted the affected configuration changes in the NA environment. * Restored alignment between deployed configuration and service components. * Validated successful execution of Data Explorer queries across affected organizations. * Monitored system performance to confirm stability post-recovery. ‌ **Future Preventative Measures** ‌ * Review Post-Deployment Consistency Checks: Ensure configuration and service components are aligned across all regions after deployment. * Enhance Error Handling and Messaging: Improve system behavior so backend failures are accurately reflected in user-facing error messages. * Strengthen Regional Deployment Monitoring: Expand monitoring coverage for critical services to detect issues earlier. * Improve Rollback Validation Processes: Establish more robust validation steps to ensure faster and more reliable recovery following rollback actions.

Read the full incident report →

Started Mar 31, 2026, 03:04 PM UTC· resolved Mar 31, 2026, 08:44 PM UTC

1. investigating Mar 31, 2026, 03:04 PM UTC

   Incident Description: We are investigating an issue affecting Flexera One IT Visibility in the EU region. Customers may experience errors when accessing the Evidence UI and may also encounter failures with ZIP exports and Query exports. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and working to restore full functionality as quickly as possible.

2. identified Mar 31, 2026, 04:02 PM UTC

   Our technical teams have identified a recent change as a likely contributor to the issue and are actively working to restore affected functionality in the EU region. As part of mitigation, teams are preparing an alternate recovery path while continuing efforts to resolve the issue as quickly as possible. We will share further updates as soon as more information becomes available.

3. identified Mar 31, 2026, 04:55 PM UTC

   Our technical teams have completed mitigation and moved traffic to the restored service path. Early indications show the issue has been resolved, though some customers may continue to experience temporary impact while network updates propagate. We are continuing to validate recovery and will provide a further update once full restoration has been confirmed.

4. monitoring Mar 31, 2026, 05:29 PM UTC

   Our technical teams have completed mitigation steps, and current indicators point to recovery of affected services in the EU region. Some customers may continue to experience temporary impact for a limited period while network updates complete in their environment. If the issue persists, restarting the affected machine may help. We are continuing to monitor restoration closely.

5. resolved Mar 31, 2026, 08:44 PM UTC

   Mitigation steps were completed successfully, and full recovery has been confirmed. Affected services in the EU region are now operating normally. We will conduct a full root cause analysis and provide a post-mortem report highlighting the underlying cause and the preventative measures identified as part of our follow-up to this incident.

6. postmortem Apr 16, 2026, 06:30 AM UTC

   **Description:** Flexera One – IT Visibility – EU – Errors Affecting Evidence UI and Export Functions **Timeframe:** March 31, 2026, 7:48 AM PDT to March 31, 2026, 1:20 PM PDT **Incident Summary** On Tuesday, March 31, 2026, 7:48 AM PDT, an issue was identified affecting IT Visibility \(ITV\) functionality in the EU region. Customers experienced errors when accessing the Evidence UI, as well as failures when performing ZIP exports and Query exports. Requests returned HTTP 503 errors, resulting in incomplete or unsuccessful operations. During the impact window, customers in the EU region experienced failures across key ITV workflows, including accessing the Evidence UI and performing ZIP and Query exports. While the Flexera One platform remained accessible, these specific functionalities did not operate as expected. The issue was detected through monitoring alerts and internal investigation. Engineering teams from multiple groups engaged immediately and worked in parallel to identify the cause and restore service. Initial mitigation efforts, including rollback of recent changes, did not fully resolve the issue. As part of recovery, a new infrastructure cluster was provisioned and traffic was redirected to it. Following this action, services began recovering, and full functionality was restored after DNS propagation completed. Some customers may have experienced brief residual impact due to caching before full recovery was realized. ‌ **Root Cause** The issue was caused by a deployment-related configuration inconsistency affecting secure communication settings in the EU region. During a recent infrastructure deployment, a critical configuration responsible for secure service communication was unintentionally recreated. This led to intermittent failures in request routing, resulting in HTTP 503 errors for affected ITV functionalities. Although the deployment initially appeared successful, the issue manifested under specific conditions and impacted multiple organizations within the EU region. Contributing Factors: * Configuration difference: Differences between deployed configurations in regions led to inconsistent behavior, with EU being uniquely impacted. * Deployment Side Effects: Infrastructure changes unintentionally modified critical communication settings. * Limited Functional Monitoring: Existing monitoring focused on service health, delaying detection of user-facing issues. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Rolled back the impacted deployment changes in the EU region. * Provisioned a new infrastructure cluster and redirected traffic to stabilize services. * Verified recovery of affected UI, ZIP exports, and Query export functionality. * Monitored system behavior and confirmed stability configuration update propagation. ‌ **Future Preventative Measures** ‌ * Stronger Deployment Consistency Controls: Ensuring configuration changes are applied consistently across all regions to prevent drift. * Enhanced Post-Deployment Validation: Review and implement functional \(end-to-end\) validation tests to verify key workflows after deployments. * Improved Monitoring and Alerting: Expanding monitoring to detect user-impacting failures \(such as API and export failures\). * Deployment Safeguards and Review: Strengthening change review processes to identify and prevent unintended configuration changes during deployments.

Read the full incident report →

Started Mar 27, 2026, 09:14 PM UTC· resolved Mar 27, 2026, 09:14 PM UTC

1. resolved Mar 27, 2026, 09:14 PM UTC

   Incident Description: An issue was identified that affected access to the Managed SaaS Applications page within the Flexera One SaaS Manager application. Customers encountered errors when attempting to load this page, impacting visibility into managed SaaS applications. Priority: P2 Impact Start Time: March 27, 2026, 12:37 PM PDT Impact End Time: March 27, 2026, 1:59 PM PDT Impact Duration: 1 hour 22 minutes Restoration Activity: The issue was traced to a subset of services supporting this functionality entering an error state. Corrective actions were taken, including restarting affected services and validating recovery across impacted regions. Full functionality has been restored, and the service continues to be monitored closely.

2. postmortem Apr 16, 2026, 06:21 AM UTC

   **Description:** Flexera One – SaaS Manager – NAM/APAC – Unable to Load Managed SaaS Applications **Timeframe:** March 27, 2026, 12:37 PM PDT to March 27, 2026, 1:59 PM PDT ‌ **Incident Summary** ‌ On Friday, 27th Mar 2026 at 12:37 PM PDT, an issue was identified that affected access to the Managed SaaS Applications page within the Flexera One SaaS Manager application. Customers encountered errors when attempting to load this page, resulting in a temporary loss of visibility into managed SaaS applications. During the impact window, customers in the NAM and APAC regions experienced errors when accessing the Managed SaaS Applications page. Users may have seen the error message: “An unexpected error occurred while loading managed applications.” The issue was limited to this specific functionality, and the rest of the Flexera One platform remained accessible and operational. No impact was observed in the EU region, and no customer cases were reported during the incident. Service was restored by restarting the affected component, which stabilized the impacted functionality, and normal operation resumed within the stated timeframe. ‌ **Root Cause** ‌ * The issue occurred due to a temporary disruption in communication with a supporting internal service required for application functionality. During this time, certain application components became unstable and were unable to process requests correctly, resulting in errors when loading the affected page. * The impacted service dependency was briefly unavailable but recovered after a restart, which restored normal operations. No code changes or permanent fixes were required. Contributing Factors: * Temporary unavailability of a supporting service dependency. * Limited resilience of affected components to short-lived connectivity interruptions. * Monitoring gaps, where alerts were triggered in one environment but not consistently across all affected components. * Minimal error logging, with only health check failures observed, which reduced early visibility into the issue. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Restored normal operation by restarting the affected supporting service. * Stabilized application components and verified successful page functionality. * Confirmed service health across impacted regions following recovery. ‌ **Future Preventative Measures** ‌ * Improved Service Resilience: Enhancing application behavior to better tolerate brief interruptions in dependent services without impacting user experience. * Enhanced Monitoring Coverage: Expanding monitoring to ensure consistent alerting across all environments and components. * Alerting Improvements: Reviewing and refining alert mechanisms to ensure issues are detected promptly and reliably across all clusters.

Read the full incident report →

Started Mar 24, 2026, 06:12 PM UTC· resolved Mar 24, 2026, 07:30 PM UTC

1. investigating Mar 24, 2026, 06:12 PM UTC

   Incident Description: We are investigating an issue affecting IT Visibility in the APAC region. Customers may experience intermittent failures when performing actions such as running queries or exporting/downloading data, with requests returning 503 errors. The Flexera One UI remains accessible; however, some features may not function as expected due to these service disruptions. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and working to identify the underlying cause. Further updates will be provided as more information becomes available.

2. monitoring Mar 24, 2026, 07:21 PM UTC

   We have implemented a mitigation and are observing signs of recovery in the APAC region. Initial validation indicates that previously impacted operations, including queries and data exports/downloads, are now completing successfully. Our teams are continuing to monitor the environment and perform validation to ensure full restoration of service.

3. resolved Mar 24, 2026, 07:30 PM UTC

   The issue affecting IT Visibility in the APAC region has been resolved. Customers should no longer experience errors when running queries or exporting/downloading data. The disruption was caused by an unintended configuration change introduced during a recent update, which impacted request routing for certain services. Our teams identified the issue and implemented corrective actions to restore normal service behavior. All services have been validated and are operating normally. We will continue to monitor the environment to ensure sustained performance.

4. postmortem Apr 10, 2026, 12:23 PM UTC

   **Description:** Flexera One - IT Visibility - APAC - Intermittent Errors During Queries and Data Exports **Timeframe:** 24 March, 2026, 11:12 AM PDT to 24 March, 2026, 12:30 PM PDT ‌ **Incident Summary** On March 24, 2026, our monitoring systems and internal alerts identified intermittent failures impacting IT Visibility services in the APAC region. The impacted customers experienced errors when executing queries and exporting or downloading data, with some requests returning HTTP 503 responses. While the Flexera One service remained accessible, select functionalities relying on backend services were intermittently unavailable. Initial investigation indicated that requests were intermittently failing before reaching backend services, pointing to an issue within the request routing. The behavior was observed across multiple endpoints and request types, confirming that the issue was not isolated to a specific feature. Our technical teams identified that a recent configuration change had unintentionally impacted request routing behavior in the APAC region. Although similar changes had been deployed in other regions without impact, this change resulted in inconsistent routing behavior in APAC. To mitigate the issue, the team provisioned new infrastructure with a corrected configuration and redirected traffic accordingly. Following this action, API responses returned to normal, and system health checks stabilized. All services were validated, and functionality was fully restored by 12:30 PM PDT. Continuous monitoring confirmed sustained recovery. ‌ **Root Cause** The issue was caused by an unintended configuration change within the gateway layer that affected request routing behavior for IT Visibility services in the APAC region. Contributing Factors: * The change was introduced as part of a routine configuration update and was not expected to impact production behavior. * Variations in how the configuration was applied across environments led to inconsistent outcomes. * Pre-deployment validation did not fully capture this behavior in the APAC environment. * The nature of the change made its production impact not immediately apparent during review. ‌ **Remediation Actions** ‌ The following actions were taken by our technical teams to restore the service: * Reverted the impacted configuration to a known stable state. * Provisioned a new gateway cluster with the corrected configuration. * Redirected traffic to the updated cluster to restore normal request routing. * Validated API responses and service health across all affected endpoints. * Continued monitoring to ensure sustained stability and normal operation. ‌ **Future Preventative Measures** ‌ * Controlled Deployment Governance for Gateway Changes - Introduce stricter controls to ensure that changes are clearly gated and promoted correctly. * Enhanced Change Review, Testing & PR Standards – Review and implement a standardized PR template requiring clear documentation of change intent, expected impact, associated tracking, and validation steps. * Environment Consistency & Validation Improvements - Strengthen validation processes to ensure consistent behavior across regions and environments before production rollout.

Read the full incident report →

Started Mar 20, 2026, 03:34 AM UTC· resolved Mar 20, 2026, 08:18 AM UTC

1. identified Mar 20, 2026, 03:34 AM UTC

   Incident Description: We are currently investigating an issue affecting data update operations in the North America (NAM) production environment. While the ITV platform remains accessible, customers may experience delays in workflows that rely on data updates. Priority: P2 Restoration Activity: Our technical teams have identified an issue within the database cluster and are actively working with the service provider to restore stable operations. Write activity has been temporarily paused as a precaution while recovery actions are in progress. We continue to monitor the situation closely and will provide further updates as progress is made.

2. identified Mar 20, 2026, 05:37 AM UTC

   Our technical teams are actively working to restore full stability of the affected database cluster. Write activity remains paused to ensure data consistency and prevent further impact while recovery actions are in progress. We continue to monitor the environment closely and will provide further updates as progress is made.

3. resolved Mar 20, 2026, 08:18 AM UTC

   Our technical teams have restored stability of the affected database cluster and resumed write operations. Services are operating normally, and we will continue to monitor the environment closely.

4. postmortem Apr 06, 2026, 04:24 AM UTC

   **Description:** Flexera One – IT Visibility – NAM – Data Update Delays **Timeframe:** March 19, 2026, 7:35 PM PDT – March 20, 2026, 1:13 AM PDT **Incident Summary** On March 19, 2026, at approximately 7:35 PM PDT, technical teams identified an issue affecting data update activity in the North America \(NAM\) production environment for Flexera One IT Visibility. During the incident window, write operations were paused while technical teams assessed service stability and recovery progress. As a result, customers may have experienced delays in workflows that depend on data updates. As the incident progressed, technical teams confirmed that one of the production data clusters in the NAM environment had become unstable. Recovery began during the incident, and a primary was re-established within the affected cluster. However, write operations remained unstable for a period, so write activity continued to remain paused while the environment recovered further. Once the affected cluster stabilized and recovery was completed, write activity was resumed and the platform began catching up on delayed data updates. By March 20, 2026, at approximately 1:13 AM PDT, write operations had resumed, delayed updates had caught up, and the incident was considered resolved. **Root Cause** The incident was caused by instability affecting one of the production data clusters in the NAM environment, which disrupted normal write activity. Although recovery started during the incident and a primary was re-established, write operations remained unstable until the affected cluster recovered fully. To protect the environment during recovery, write activity remained paused until service stability was restored. This resulted in delays to customer data updates during the incident window. **Remediation Actions** The following actions were taken during the incident response: * Issue Identification and Response: Technical teams identified the issue affecting data update activity in the NAM production environment and began recovery efforts. * Protective Write Pause: Write operations were paused as a precaution while service stability and recovery progress were assessed. * Recovery Monitoring: Technical teams continued recovery efforts after a primary was re-established, while monitoring the environment until it was stable enough to resume write activity. Controlled Write Restoration: Write activity was resumed once the affected cluster had recovered and stable processing could safely continue. * Catch-Up Validation: Technical teams monitored the environment as delayed updates were processed and confirmed that the platform had caught up before closing the incident. **Future Preventative Measures** Based on this incident, the following follow-up actions are being taken: * Cluster Recovery Review: We are continuing to work with the technical teams to review what occurred with the affected production cluster and identify improvements that may help reduce the likelihood of similar disruption in the future. * Recovery Process Improvements: We are reviewing the recovery approach used during this incident to help strengthen stabilization and restoration activities in similar scenarios. * Service Provider Engagement: We are continuing to engage our external service provider to support follow-up review and help ensure long-term stability of the affected environment.

Read the full incident report →

Started Mar 19, 2026, 02:20 AM UTC· resolved Mar 20, 2026, 12:13 AM UTC

1. identified Mar 19, 2026, 02:20 AM UTC

   Incident Description: Our teams have identified and are actively investigating an issue impacting inventory processing in the EU production environment. While ITV platform remain accessible, some customers may experience delays in processing newly uploaded inventory, and status pages may intermittently show timeouts during the normalization stage. Priority: P2 Restoration Activity: Our teams have identified resource constraints within the database cluster and are currently upgrading the capacity to improve throughput. Our teams continue to monitor the environment closely while these mitigation actions are in progress.

2. monitoring Mar 19, 2026, 05:31 AM UTC

   The infrastructure upgrade to improve inventory normalization performance is currently in progress. At this time, the system is able to handle incoming data at the expected rate; however, the existing backlog is still being processed. We continue to closely monitor progress as the upgrade completes and additional improvements take effect.

3. monitoring Mar 19, 2026, 06:24 AM UTC

   Progress continues on the infrastructure improvements to restore normal processing performance. The primary cluster upgrade is now majorly complete and is beginning to gradually reduce the existing backlog. Our teams have taken additional actions to further accelerate backlog clearance and improve overall processing times. We will continue to provide updates as performance continues to improve.

4. monitoring Mar 19, 2026, 03:44 PM UTC

   Progress continues on infrastructure improvements to restore normal processing performance. The primary cluster upgrade has now been completed, and backlog reduction is ongoing. Additional capacity has been brought online, and workload is being redistributed to further accelerate backlog clearance. We will continue to monitor progress closely and provide further updates as processing performance improves.

5. resolved Mar 20, 2026, 12:13 AM UTC

   The backlog affecting inventory processing in the EU production environment has been fully cleared. Processing has returned to expected levels, and all services are functioning as expected.

6. postmortem Apr 03, 2026, 05:24 AM UTC

   **Description:** Flexera One – IT Visibility – EU – Inventory Processing Delay **Timeframe:** March 18, 2026, 5:58 PM PDT – March 19, 2026, 4:27 PM PDT **Incident Summary** On March 18, 2026, at approximately 5:58 PM PDT, technical teams identified a backlog affecting inventory normalization in the EU production environment for Flexera One IT Visibility. During this period, ITV UIs and APIs remained accessible and operational. However, some customers experienced delays in the processing of newly uploaded inventory, and status pages could intermittently display timeouts during the Normalize stage. Technical teams confirmed that the issue was limited to the EU region and that a majority of customers were expected to be impacted to some extent. Technical teams began recovery activities by increasing resources on the existing cluster to improve normalization throughput. As the upgrade progressed, services were able to keep up with the incoming data rate, but the backlog was not yet decreasing. Additional actions were then taken to accelerate recovery, including bringing a second cluster online and migrating high-traffic organizations to that environment to distribute load more effectively. These actions improved processing throughput and allowed the backlog to begin reducing until it was fully cleared. By March 19, 2026, at approximately 4:27 PM PDT, inventory normalization processing had returned to expected levels in the EU region, and the incident was considered resolved. Cleanup activities continued separately after service restoration. **Root Cause** The incident was caused by inventory normalization processing in the EU production environment falling behind the incoming workload, which resulted in a backlog. As a result, some newly uploaded inventory took longer than expected to process, and customers could intermittently see timeouts during the normalization stage while the backlog was being cleared. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Detection and Response Initiated: Technical teams were notified of the normalization backlog and began investigating the issue affecting inventory processing in the EU region. 2. Impact Isolation: It was confirmed that the issue was limited to the EU region and that ITV UIs and APIs remained accessible while normalization processing was delayed. 3. Cluster Resource Upgrade: Resources on the existing cluster were increased to improve normalization throughput. 4. Additional Cluster Provisioned: A second cluster was brought online to help distribute processing load. 5. Workload Redistribution: High-traffic organizations were migrated to the second cluster to accelerate backlog reduction. 6. Service Restoration Verification: Processing throughput was monitored and validated until the backlog was fully cleared and normalization returned to expected levels. **Future Preventative Measures** This incident highlighted the importance of maintaining sufficient throughput and monitoring within the inventory normalization process. Based on this experience, the following measures are being applied: 1. Capacity and Throughput Review: We are reviewing approaches to better support normalization demand and reduce the likelihood of similar backlogs. 2. Workload Distribution Readiness: We are strengthening readiness to distribute workload more effectively when processing demand increases. 3. Monitoring and Early Detection: We are reviewing monitoring and alerting approaches to help identify backlog growth sooner and support earlier remediation.

Read the full incident report →