Flexera Outage History

Started Aug 18, 2026, 09:32 AM UTC· resolved Aug 18, 2026, 12:13 PM UTC

1. investigating Aug 18, 2026, 09:32 AM UTC

   Incident Description: We are currently investigating an issue affecting access to Flexera One IT Asset Management (ITAM) in the APAC region. The impacted customers may experience difficulties accessing the platform or may encounter errors after authentication. Priority: P1 Restoration Activity: Our technical have been engaged and are actively investigating the issue to identify the underlying cause and restore normal service as quickly as possible.

2. identified Aug 18, 2026, 10:18 AM UTC

   Our investigation has identified a configuration issue as the likely cause of the impact. Teams are actively working to implement and validate corrective measures to restore normal service operation. Further updates will be provided as the investigation progresses.

3. identified Aug 18, 2026, 10:43 AM UTC

   As the investigation has progressed, our teams have identified indications that the issue is not isolated to IT Asset Management and may have broader impact across the Flexera One platform in APAC. Remediation efforts are underway against the identified cause, and teams are focused on restoring full service stability. Additional updates will be provided as more information becomes available.

4. identified Aug 18, 2026, 10:50 AM UTC

   We are continuing to work on a fix for this issue.

5. monitoring Aug 18, 2026, 11:47 AM UTC

   A fix has been implemented, and access to the Flexera One platform has been restored. Our teams are conducting additional validation activities and continue to closely monitor service health and performance to confirm stability and ensure all services remain fully operational.

6. resolved Aug 18, 2026, 12:13 PM UTC

   Following extended monitoring and verification activities, our teams have confirmed that services remain stable and no further impact has been observed. The incident has been resolved, and all affected services are fully operational.

7. postmortem Aug 31, 2026, 11:34 AM UTC

   **Description:** Flexera One - IT Asset management - APAC - Access disruption **Timeframe:** August 18, 2026, 2:10 AM PDT to August 18, 2026, 4:26:03 AM PDT ‌ **Incident Summary** ‌ On Tuesday, August 18, 2026, at 2:10 AM PDT , Flexera identified an issue affecting the Flexera One APAC Production environment that prevented customers from accessing Flexera One services. During the impact window, customers experienced login failures, session refresh failures, and issues retrieving user-related application data, resulting in widespread service access unavailability across the platform. Initial investigation indicated that the impact was limited to IT Asset Management. Further analysis determined that the issue involved a shared platform service supporting authentication and authorization across Flexera One, resulting in a broader impact across the APAC environment. Our technical teams identified an incorrect infrastructure scheduling configuration that prevented a critical platform service from operating as intended. The configuration was corrected, restoring the affected services. Following remediation, health checks returned successfully, application login and navigation functionality recovered, and teams completed post-restoration validation. The environment was subsequently confirmed healthy and placed under continued monitoring to ensure ongoing stability. ‌ **Root Cause** ‌ The incident was caused by an incorrect infrastructure scheduling configuration within a critical shared identity and access service. The configuration prevented the service from being scheduled onto the intended infrastructure, resulting in service unavailability and failures affecting authentication and authorization requests. ‌ **Remediation Actions** ‌ Our teams performed the below actions to restore the services to normalcy: * Configuration Correction: Corrected the infrastructure scheduling configuration affecting the impacted platform service. * Service Restoration: Restored the affected platform services and confirmed successful health checks. * Post-Restoration Validation: Performed automated health checks and platform validation to confirm application login, navigation, and related functionality had recovered. * Continued Monitoring: The environment was monitored following restoration to confirm ongoing platform stability. ‌ **Future Preventative Measures** ‌ * Pre-Deployment Validation: Implement additional validation checks for infrastructure scheduling and placement configurations. * Deployment Safeguards and Resiliency Controls: Review and strengthen deployment safeguards, configuration governance, and resiliency controls to prevent configuration mismatches from impacting service availability. * Expanded Post-Change Verification: Review and enhance the post-deployment and post-maintenance validation processes to ensure critical platform services are functioning correctly following infrastructure changes.

Read the full incident report →

Started Aug 11, 2026, 05:26 PM UTC· resolved Aug 11, 2026, 08:26 PM UTC

1. investigating Aug 11, 2026, 05:26 PM UTC

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

2. identified Aug 11, 2026, 05:48 PM UTC

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

3. monitoring Aug 11, 2026, 06:08 PM UTC

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

4. resolved Aug 11, 2026, 08:26 PM UTC

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

5. postmortem Aug 14, 2026, 08:02 PM UTC

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

Read the full incident report →

Started Aug 07, 2026, 04:55 AM UTC· resolved Aug 14, 2026, 05:41 AM UTC

1. investigating Aug 07, 2026, 04:55 AM UTC

   Issue Description: Our teams have identified that some Flexera customers' email systems are rejecting emails sent containing notifications of updates on Flexera Support cases. Priority: P3 Restoration Activity: Technical teams are actively investigating the issue. In the meantime, please login to the Flexera Community and use the Support Case portal at https://community.flexera.com/s/case/Case/Default to review case status and check for any updates.

2. identified Aug 07, 2026, 12:28 PM UTC

   Our teams have identified the cause of the issue and are currently working to resolve it.

3. identified Aug 08, 2026, 10:48 AM UTC

   Our teams continue to work toward a resolution. During the ongoing investigation, we identified that in some instances emails from Flexera may be being blocked by SharePoint. Addressing this issue requires additional investigation and coordination with the relevant parties to ensure the appropriate corrective actions are taken. We will continue to provide updates as more information becomes available.

4. identified Aug 10, 2026, 10:10 AM UTC

   Our teams continue working toward a resolution. Additional investigation and coordination with the appropriate teams are underway to restore normal email flow. We will provide further updates as more information becomes available.

5. monitoring Aug 12, 2026, 01:50 PM UTC

   Our teams have implemented corrective measures and are observing positive results. Initial validation testing has been successful, indicating that the mitigation actions are effective. We will continue to closely monitor the service to ensure ongoing stability and will provide further updates as they become available.

6. resolved Aug 14, 2026, 05:41 AM UTC

   After extended monitoring, our teams have confirmed that all email updates are being delivered successfully. This incident has been declared as resolved.

7. postmortem Aug 21, 2026, 09:13 AM UTC

   **Description:** Flexera Support Cases – Delayed or Failed Email Notifications **Timeframe:** August 5, 2026, 12:00 AM PDT to August 13, 2026, 11:10 AM PDT ‌ **Incident Summary** ‌ On August 5, 2026, our teams identified an issue affecting email notifications for Flexera Support cases. During the incident, some customers did not receive email notifications when updates were made to their support cases, which may have delayed awareness of case activity and progress. Our technical teams investigated the issue and determined that an issue with the email delivery configuration was causing some outbound support case notifications to be rejected by recipient email systems. As an interim measure, customers were advised to access the Flexera Community Support Case portal directly to review their case status and updates. Our teams implemented a permanent change to the email delivery configuration and subsequently validated notification delivery. Following the remediation, email notifications were confirmed to be operating as expected, and the incident was resolved on August 13, 2026, at 11:10 AM PDT. ‌ **Root Cause** ‌ * Email Delivery Configuration: An issue with the configuration used to deliver customer-facing support case notifications caused some emails to be rejected by recipient email systems. * Notification Delivery: The affected configuration resulted in some customers not receiving email notifications when updates were made to their support cases. * Customer Impact: The issue affected email notifications only; customers could continue to access their support cases directly through the Flexera Community Support Case portal. ‌ **Remediation Actions** ‌ * Updated Email Delivery Configuration: The email delivery configuration was permanently updated to use the appropriate primary email delivery infrastructure. * Notification Validation: Teams validated outbound notification delivery following the configuration change. * Customer Workaround: During the incident, customers were advised to access the Flexera Community Support Case portal directly to review case status and updates. * Service Monitoring: Teams monitored email notification delivery following remediation to confirm continued stability. ‌ **Future Preventative Measures** * Maintain Approved Email Routing: Customer-facing support case notifications will continue to use the primary email delivery infrastructure established through the permanent remediation. * Email Delivery Monitoring: Enhance monitoring and alerting for outbound support case notification failures and rejected messages to provide earlier detection of potential delivery issues.

Read the full incident report →

Started Aug 05, 2026, 08:28 AM UTC· resolved Aug 05, 2026, 11:25 AM UTC

1. resolved Aug 05, 2026, 08:28 AM UTC

   Incident Description: Our teams identified a service disruption affecting a subset of Flexera One IT Asset Management (ITAM) customers in the APAC Production environment from 4 August 2026, 04:04 AM PDT to 04:25 AM PDT . During the affected period, a subset of our customers experienced intermittent slowness, service unresponsiveness, or data loading failures within the platform. Priority: P2 Restoration Activity: Our technical teams investigated the issue and determined that an unexpected database resource exhaustion condition occurred during the affected period. The condition subsequently self-corrected, allowing affected services to recover and return to normal operation. Post-incident validation confirmed that platform operations are performing as expected. We are conducting a detailed review of the incident and evaluating additional safeguards, capacity controls, and monitoring improvements to further reduce the likelihood of similar events in the future.

2. postmortem Aug 21, 2026, 09:03 AM UTC

   **Description:** Flexera One - IT Asset management - APAC - Data loading failures/slowness **Timeframe:** August 4, 2026, 4:04 AM PDT to August 4, 2026, 4:25 AM PDT ‌ **Incident Summary** ‌ On Tuesday, August 4, 2026, our teams identified an issue affecting a subset of customers in the APAC Production environment. During the incident, some customers experienced intermittent application slowness, temporary unresponsiveness, and failures when loading data within Flexera One IT Asset Management. Our technical teams investigated the issue and determined that an unexpected database resource exhaustion event affected the production environment. The condition resulted in temporary performance degradation for a subset of customer tenants. The database condition resolved automatically after approximately 20 minutes, and application performance returned to normal without requiring direct engineering intervention. Our teams continued to monitor the environment following recovery and confirmed that affected services were operating normally with no ongoing customer impact.. ‌ **Root Cause** ‌ * Unexpected Database Resource Exhaustion: A temporary increase in database resource consumption exhausted the available temporary database storage capacity used by the production database cluster. * High Resource-Consuming Queries: It was identified that specific unexpected query run manually by a user that consumed significant amounts of temporary database resources, resulting in a temporary resource exhaustion condition. * Application Performance Impact: The resource exhaustion affected database operations and resulted in intermittent application slowness, unresponsiveness, and data loading failures for a subset of customers. ‌ **Remediation Actions** ‌ * Automatic Service Recovery: The database resource condition cleared automatically, allowing application services to return to normal operation. * Service Monitoring: Teams monitored the environment following recovery and confirmed that services remained stable. * Incident Analysis: Engineering teams reviewed the database activity and resource utilization associated with the event to identify the contributing queries and understand the behaviour. ‌ **Future Preventative Measures** ‌ * Resource Governance: Evaluate additional SQL Server resource governance controls to reduce the potential impact of high-resource database queries. * Alert Response Improvements: Review alert handling procedures to improve detection, assessment, and response to similar database resource conditions. * Operational Improvements: The query has been reviewed by our technical teams and measure have been put in place to avoid a similar scenario in the future.

Read the full incident report →

Started Aug 03, 2026, 06:56 AM UTC· resolved Aug 04, 2026, 11:09 AM UTC

1. investigating Aug 03, 2026, 06:56 AM UTC

   Incident Description: We are currently investigating an issue affecting inventory package (*.zip) uploads in the Europe region for Flexera One IT Asset Management. Customers attempting to upload specific inventory packages may encounter errors, resulting in failed inventory uploads and delays in inventory data processing. 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 Aug 03, 2026, 08:10 AM UTC

   Our teams continue to actively investigate the issue and are conducting a detailed review of system logs and diagnostics to further identify and confirm the underlying root cause. We will provide additional updates as more information becomes available.

3. investigating Aug 03, 2026, 09:38 AM UTC

   During the ongoing investigation, our teams identified that the issue may also be impacting beacon communications with the Flexera One EU Production environment. As a result, additional operations that rely on beacon-to-platform communication may be affected. The team continues to investigate the underlying cause, assess the full scope of impact, and work towards implementing a resolution as quickly as possible.

4. monitoring Aug 03, 2026, 10:40 AM UTC

   Our teams have identified a recent configuration change as the likely cause of the issue. The configuration has since been rolled back, and we are observing service recovery across the affected components, with platform functionality gradually returning to expected levels. The teams remain actively engaged in monitoring the environment to validate full recovery, ensure platform stability, and quickly address any residual impacts.

5. monitoring Aug 03, 2026, 10:40 AM UTC

   We are continuing to monitor for any further issues.

6. monitoring Aug 03, 2026, 05:09 PM UTC

   Mitigation actions remain effective, and inventory processing is continuing successfully. We are actively monitoring recovery progress and working through the remaining backlog to ensure all processing is completed successfully. We will continue to provide updates as recovery efforts progress.

7. monitoring Aug 04, 2026, 07:02 AM UTC

   Service recovery remains on track, with mitigation measures continuing to be effective. Inventory processing is functioning successfully, and the backlog has been reduced significantly, bringing volumes closer to normal levels. Our teams continue to monitor the environment and process the remaining backlog to complete recovery. Further updates will be provided as appropriate.

8. resolved Aug 04, 2026, 11:09 AM UTC

   The environment has returned to normal operating levels. Inventory processing and beacon communications are stable, and backlog has returned to expected thresholds. The platform remains healthy, with continued monitoring confirming sustained stability. Additional details on the root cause, restorative actions, and long-term improvement initiatives will be shared in a post-mortem report following validation of the findings.

9. postmortem Aug 18, 2026, 06:29 AM UTC

   **Description:** Flexera One- IT Asset management - EU - Inventory upload errors **Timeframe:** July 30, 2026, 11:30 AM PDT to August 4, 2026, 4:09 AM PDT ‌ **Incident Summary** ‌ On Sunday, August 2, 2026, at 11:42 PM PDT, Flexera identified an issue affecting inventory package \(\*.zip\) uploads and select beacon communications within the Flexera One IT Asset Management EU Production environment. Affected customers experienced failed inventory package uploads, including HTTP 504 \(Gateway Timeout\) and HTTP 405 \(Method Not Allowed\) responses. The issue also disrupted select beacon-to-platform communications, causing delays or failures in inventory processing and inventory data ingestion. The investigation determined that earliest impact started at 11:30 AM PDT on July 30, 2026. Analysis identified a communication issue within a critical service routing path that prevented a subset of requests from successfully reaching downstream processing services. This resulted in repeated retries, delayed inventory processing, and backlog accumulation. To mitigate the issue and restore service, traffic was redirected to an alternate communication path. Following this change, beacon communications stabilized, inventory uploads resumed processing successfully, and the inventory backlog began to decrease. By 3:42 AM PDT on August 3, 2026, inventory uploads were completing successfully and no new errors were observed. The environment remained under extended monitoring while processing volumes returned to normal operating levels. At 4:09 AM PDT on August 4, 2026, Flexera confirmed that beacon communications, inventory processing, and associated platform services were operating normally, the backlog had returned to expected thresholds, and the incident was formally declared resolved. ‌ **Root Cause** ‌ A certificate update introduced on July 31, 2026 within a critical service communication path resulted in a configuration mismatch between communicating platform components. Following the certificate update, communication failures occurred within the path, resulting in handshake errors and service unavailability. As a result, requests from customer beacons to upload inventory package \(\*.zip\) files to the EU Production environment could not be processed successfully, causing upload failures and preventing inventory data from being received and processed. The same communication issue also affected a subset of other beacon-to-platform interactions. Service was restored by redirecting traffic to an alternate communication path that was not impacted by the certificate-related configuration issue, allowing inventory uploads and beacon communications to resume normal operation. Contributing Factors * Intermittent Request Failures: Failed connection establishment attempts caused a portion of requests to be unsuccessful before reaching downstream processing services. * Inventory Processing Delays: Communication failures prevented some inventory packages and associated imports from processing successfully, resulting in delayed inventory updates. * Retry-Driven Backlog Growth: Automated retry mechanisms enabled many transactions to eventually succeed but contributed to increased processing delays and backlog accumulation while the issue remained active. ‌ **Remediation Actions** ‌ To restore service, technical teams performed below actions: * Traffic Rerouting: Redirected traffic away from the affected service path to restore stable beacon communications and inventory package uploads. * Platform Monitoring: Performed continuous monitoring of beacon communications, inventory uploads, and processing activity to verify service recovery. * Backlog Recovery Management: Monitored inventory processing throughput and validated that processing backlogs steadily reduced and returned to expected operating thresholds. * Stability Validation: Conducted extended monitoring following restoration to confirm sustained platform stability and successful inventory processing. * Service Restoration Confirmation: At 4:09 AM PDT on August 4, 2026, confirmed that beacon communications, inventory processing, and associated services were operating normally. ‌ **Future Preventative Measures** ‌ * Service Communication Resilience: Review and enhance the affected communication path to improve reliability, resiliency, and recovery from future connectivity-related disruptions. * Strengthened Change Validation: Enhance validation and testing processes for infrastructure, configuration, certificate, and service-path changes to identify communication mismatches before deployment into production environments. * Improved Detection and Alerting: Enhance monitoring and alerting capabilities to provide earlier identification of sustained communication disruptions, elevated retry activity, abnormal error-rate patterns, and emerging processing backlogs. These improvements will enable faster detection, investigation, and remediation of issues before they develop into broader customer impact.

10. postmortem Aug 18, 2026, 12:41 PM UTC

    **Description:** Flexera One- IT Asset management - EU - Inventory upload errors **Timeframe:** July 31, 2026, 6:00 PM PDT to August 4, 2026, 4:09 AM PDT ‌ **Incident Summary** ‌ On Sunday, August 2, 2026, at 11:42 PM PDT, Flexera identified an issue affecting inventory package \(\*.zip\) uploads and select beacon communications within the Flexera One IT Asset Management EU Production environment. Affected customers experienced failed inventory package uploads, including HTTP 504 \(Gateway Timeout\) and HTTP 405 \(Method Not Allowed\) responses. The issue also disrupted select beacon-to-platform communications, causing delays or failures in inventory processing and inventory data ingestion. The investigation determined that earliest impact started at 6:00 PM PDT on July 31st , 2026. Analysis identified a communication issue within a critical service routing path that prevented a subset of requests from successfully reaching downstream processing services. This resulted in repeated retries, delayed inventory processing, and backlog accumulation. To mitigate the issue and restore service, traffic was redirected to an alternate communication path. Following this change, beacon communications stabilized, inventory uploads resumed processing successfully, and the inventory backlog began to decrease. By 3:42 AM PDT on August 3, 2026, inventory uploads were completing successfully and no new errors were observed. The environment remained under extended monitoring while processing volumes returned to normal operating levels. At 4:09 AM PDT on August 4, 2026, Flexera confirmed that beacon communications, inventory processing, and associated platform services were operating normally, the backlog had returned to expected thresholds, and the incident was formally declared resolved. ‌ **Root Cause** ‌ On 31 July 2026, a certificate update to a critical service communication path created a configuration mismatch between platform components. The issue surfaced later, when application components were restarted and began establishing new connections using the updated configuration. This caused handshake errors and communication failures, resulting in service unavailability. Consequently, requests from customer beacons to upload inventory package \(\*.zip\) files to the EU Production environment could not be processed, causing upload failures and preventing inventory data from being received and processed. A subset of other beacon-to-platform interactions was also affected, although customer impact was not observed immediately. Service was restored by redirecting traffic to an alternate communication path that was not affected by the certificate-related configuration issue. Inventory uploads and beacon communications then resumed normal operation. Contributing Factors * Intermittent Request Failures: Failed connection establishment attempts caused a portion of requests to be unsuccessful before reaching downstream processing services. * Inventory Processing Delays: Communication failures prevented some inventory packages and associated imports from processing successfully, resulting in delayed inventory updates. * Retry-Driven Backlog Growth: Automated retry mechanisms enabled many transactions to eventually succeed but contributed to increased processing delays and backlog accumulation while the issue remained active. ‌ **Remediation Actions** ‌ To restore service, technical teams performed below actions: * Traffic Re-routing: Redirected traffic away from the affected service path to restore stable beacon communications and inventory package uploads. * Platform Monitoring: Performed continuous monitoring of beacon communications, inventory uploads, and processing activity to verify service recovery. * Backlog Recovery Management: Monitored inventory processing throughput and validated that processing backlogs steadily reduced and returned to expected operating thresholds. * Stability Validation: Conducted extended monitoring following restoration to confirm sustained platform stability and successful inventory processing. * Service Restoration Confirmation: At 4:09 AM PDT on August 4, 2026, confirmed that beacon communications, inventory processing, and associated services were operating normally. ‌ **Future Preventative Measures** ‌ * Service Communication Resilience: Review and enhance the affected communication path to improve reliability, resiliency, and recovery from future connectivity-related disruptions. * Strengthened Change Validation: Enhance validation and testing processes for infrastructure, configuration, certificate, and service-path changes to identify communication mismatches before deployment into production environments. * Improved Detection and Alerting: Enhance monitoring and alerting capabilities to provide earlier identification of sustained communication disruptions, elevated retry activity, abnormal error-rate patterns, and emerging processing backlogs. These improvements will enable faster detection, investigation, and remediation of issues before they develop into broader customer impact.

Read the full incident report →

Started Jul 29, 2026, 04:36 AM UTC· resolved Jul 29, 2026, 09:52 AM UTC

1. investigating Jul 29, 2026, 04:36 AM UTC

   Incident Description: We are investigating an issue affecting the Software Vulnerability Research (SVR) service. Customers may be experiencing difficulties accessing or using SVR at this time. Priority: P1 Restoration Activity: Our teams are actively investigating the issue and working to restore service. Mitigation activities are currently underway as we work to bring the service back online. Further updates will be provided as more information becomes available.

2. investigating Jul 29, 2026, 06:02 AM UTC

   Recovery actions have been implemented; however, the service continues to experience instability under current workload conditions, resulting in ongoing service disruptions. Our teams are actively working to reduce the impact and restore service availability. Further updates will be provided as more information becomes available.

3. resolved Jul 29, 2026, 09:52 AM UTC

   Technical teams have restored service availability for Software Vulnerability Research (SVR). Recovery actions were implemented to address the service instability, and validation has confirmed that SVR functionality has been restored. We will continue to closely monitor the service to ensure ongoing stability. A post-mortem report containing additional details, including the root cause and preventative measures, will be published in the coming days.

4. postmortem Aug 11, 2026, 10:28 AM UTC

   **Description:** Software Vulnerability Research \(SVR\) - Service Disruption **Timeframe:** July 28, 2026, 2:00 PM PDT to July 29, 2026, 2:53 AM PDT ‌ **Incident Summary** On Tuesday, 28 July 2026, at 2:00 PM PDT, the Flexera Software Vulnerability Research\(SVR\) production environment experienced a service disruption that affected API availability and application functionality. The incident occurred when the primary database instance supporting the SVR platform became unavailable. Existing database connections were unexpectedly terminated, and application servers were unable to establish new connections. As a result, customers were unable to reliably access SVR services and APIs during the incident. During the investigation, our teams determined that the disruption was caused by an unplanned failover initiated by the cloud service provider. According to the provider’s event history, an infrastructure issue was detected on the primary database host, prompting the provider to automatically initiate the failover process. Our technical teams immediately engaged the cloud service provider to investigate the incident and restore service. Following recovery and validation activities, all production services were successfully restored and returned to normal operation by 2:53 AM PDT on 29 July 2026. ‌ **Root Cause** ‌ The incident was triggered by an unplanned failover of the production database, initiated by the cloud service provider in response to an infrastructure-level issue affecting the primary database host. During the failover, the primary database instance became temporarily unavailable. This caused active database connections to terminate abruptly, preventing application services from establishing new connections. As a result, API requests failed and service availability across the SVR platform was impacted. Flexera has formally requested a detailed Root Cause Analysis \(RCA\) from the cloud service provider to determine the precise infrastructure condition that triggered the failover and to identify opportunities to prevent recurrence. ‌ **Contributing Factors** ‌ During the investigation, the following factors were identified as potentially contributing to the overall impact of the incident: * A significantly elevated volume of client connection attempts was observed originating from customer environments during the incident period. * Connection volumes exceeded normal operating levels, increasing load on backend services while database services were recovering. * Elevated connection activity may have amplified the impact of the database failover and increased recovery complexity. * Existing application retry and connection behaviours generated additional connection demand during database recovery activities. ‌ **Remediation Actions** ‌ * Cloud provider engagement: Our teams immediately engaged the cloud service provider and worked directly with their on-call engineers throughout the recovery effort. * Database recovery: Executed a controlled database failover/reboot in coordination with the cloud service provider. * Restored connectivity: Re-established database availability and connectivity to the production environment. * Application recovery validation: Confirmed that application services successfully reconnected to backend database services. * Service validation: Verified recovery of APIs and critical SVR application functionality. * Post-recovery monitoring: Implemented enhanced monitoring of database health, application performance, and connection activity following restoration. ‌ **Future Preventative Measures** ‌ * Continue monitoring customer connection volumes and backend database connection utilisation. * Review and optimise database connection pooling, connection management, retry logic, and failover handling to improve resilience during future infrastructure events. * Complete the cloud service provider support engagement and review the provider's detailed Root Cause Analysis once available. * Conduct an internal post-incident review and implement additional preventive measures identified through the review process.

Read the full incident report →

Started Jul 28, 2026, 11:14 PM UTC· resolved Jul 29, 2026, 02:05 AM UTC

1. investigating Jul 28, 2026, 11:14 PM UTC

   Incident Description: We are investigating an intermittent issue affecting Flexera One services in the APAC region. Customers may experience intermittent access issues or errors while using Flexera One applications and services. The issue currently appears to be limited to the APAC region. Priority: P1 Restoration Activity: Our teams are actively investigating the issue. The scope and impact are being assessed across Flexera One services in the APAC region, and we are working to identify the underlying cause and restore service stability. Further updates will be provided as more information becomes available.

2. investigating Jul 29, 2026, 12:34 AM UTC

   Our technical teams are actively investigating the issue. The issue appears to be intermittent, with some requests succeeding while others continue to fail. We are reviewing affected services and their dependencies to determine the scope of impact, identify the underlying cause, and restore service stability.

3. resolved Jul 29, 2026, 02:05 AM UTC

   Technical teams have mitigated the issue affecting Flexera One services in the APAC region. Service functionality has been restored, and validation confirms that affected applications and services are operating as expected. During the investigation, teams identified intermittent service communication issues that resulted in access issues and errors for some customers. As part of the mitigation effort, technical teams restarted affected services, after which service functionality recovered and validation confirmed successful restoration of impacted services. We will continue to review the incident and monitor service health.

4. postmortem Aug 12, 2026, 05:33 PM UTC

   **Description:** Flexera One - APAC - Intermittent Service Disruption ## Timeframe **Timeframe:** July 28, 2026, 3:49 PM PDT - July 28, 2026, 5:40 PM PDT ## Incident Summary On Tuesday, July 28, 2026, at 3:49 PM PDT, customers using Flexera One services in the APAC region began experiencing intermittent service disruptions affecting multiple applications and platform capabilities. Customers may have encountered login issues, application errors, failed page loads, API errors, and intermittent access to certain Flexera One functionality. During the incident, multiple services experienced intermittent communication failures with shared platform services. As a result, customers experienced inconsistent application behavior, with some requests succeeding while others failed. Technical teams investigated the issue across affected applications and platform components to determine the scope and source of the failures. The investigation identified a connectivity issue affecting communication between application services and a shared platform dependency. Corrective configuration changes were implemented to restore service communication and stabilize affected functionality. Following implementation of the corrective changes, technical teams validated functionality across impacted applications and confirmed that services had returned to normal operation. Continued monitoring showed stable service behavior, and the incident was resolved at 5:40 PM PDT on July 28, 2026. ## Root Cause Investigation determined that the incident was caused by a connectivity issue introduced during a platform infrastructure migration. Following the migration, certain application services continued using legacy connection ports when communicating with shared platform services. When affected services restarted, they attempted to communicate using endpoint and port combinations that were no longer aligned with the updated platform configuration. This configuration mismatch resulted in intermittent communication failures between application services and shared platform components, causing customer-facing application errors and service disruptions across multiple Flexera One services in the APAC region. ## Remediation Actions The following actions were taken during the incident response: 1. **Incident Investigation Initiated:** Technical teams investigated reports of intermittent failures affecting multiple Flexera One services in the APAC region and assessed the scope of customer impact. 2. **Dependency Analysis Performed:** Technical teams reviewed communication paths between impacted applications and shared platform services to identify the source of the connectivity failures. 3. **Configuration Mismatch Identified:** Investigation determined that certain services were attempting to communicate through legacy ports that were not aligned with the updated platform configuration following the migration. 4. **Platform Configuration Updated:** The required ports were added to the updated platform configuration, restoring connectivity for the affected services. 5. **Service Recovery Validation:** Technical teams validated functionality across impacted applications and confirmed that service communication and customer-facing functionality had returned to normal operation. ## Future Preventative Measures The following improvements have been identified to further reduce the risk of similar incidents in the future: 1. **Migration Compatibility Validation:** Review and strengthen validation processes for infrastructure changes and platform migrations to help identify service configuration mismatches before deployment, reducing the risk of connectivity issues caused by legacy endpoint or port configurations.

Read the full incident report →

Started Jul 27, 2026, 12:11 AM UTC· resolved Jul 27, 2026, 02:00 AM UTC

1. investigating Jul 27, 2026, 12:11 AM UTC

   Incident Description: We are investigating an issue affecting Snow Atlas customers in the APAC region. Affected users may be unable to access the platform and may encounter 404 errors when attempting to log in. Current investigation indicates the issue is limited to the APAC region, with no impact confirmed in other regions at this time. Priority: P1 Restoration Activity: Our technical teams are actively investigating the issue to identify the underlying cause and restore service. We are monitoring the environment closely and implementing corrective actions as appropriate. Further updates will be provided as more information becomes available.

2. investigating Jul 27, 2026, 02:00 AM UTC

   Our teams have resolved the issue affecting Snow Atlas customers in the APAC region. The issue occurred when a platform service failed to start correctly, resulting in intermittent errors and access issues for some customers. Technical teams identified the underlying startup failure and restored service by restarting the affected platform components. Validation activities have confirmed successful access to the platform, and we are not observing any ongoing customer impact at this time. Our teams will continue to monitor the environment closely to ensure continued stability.

3. resolved Jul 27, 2026, 02:00 AM UTC

   This incident has been resolved.

4. postmortem Aug 07, 2026, 08:40 AM UTC

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

Read the full incident report →

Started Jul 22, 2026, 10:33 AM UTC· resolved Jul 23, 2026, 07:52 AM UTC

1. investigating Jul 22, 2026, 10:33 AM UTC

   Incident Description: We are investigating an issue affecting IT Visibility in the Europe region where multiple Power BI reports are failing to load . Customers in the affected region may be unable to view impacted reports within the application. Current investigation indicates the issue is limited to the Europe region, with no impact observed in other regions at this time. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue to identify the underlying cause and restore report functionality. We are continuing to assess the scope of impact, monitor service health, and implement corrective actions as appropriate. We will provide further updates as more information becomes available.

2. identified Jul 22, 2026, 11:53 AM UTC

   Our investigation has identified a potential configuration-related issue within the affected environment. As part of our validation efforts, corrective actions were applied to a subset of impacted organisations, and reports are now loading successfully. Our teams are currently focused on implementing a broader remediation across all affected organisations and are conducting a detailed review to understand why the configuration changes did not propagate as expected. We continue to validate the remediation and closely monitor service performance while working towards full resolution.

3. identified Jul 22, 2026, 01:43 PM UTC

   Corrective actions have now been applied to a larger number of affected organisations, and initial validation indicates that reports are loading successfully. We are currently validating all affected organisations to confirm that report functionality and service performance have been fully restored. In parallel, teams continue to implement broader remediation measures across the environment and are closely monitoring the service to ensure stability while work towards full resolution continues.

4. identified Jul 23, 2026, 04:39 AM UTC

   Our teams have applied the fix to all identified organizations. Initial validation indicates that the affected organizations are recovering as expected. Technical teams are continuing to validate the effectiveness of the remediation across the broader Europe region to confirm that service has been fully restored. We are closely monitoring platform performance and will provide a further update once regional validation has been completed.

5. resolved Jul 23, 2026, 07:52 AM UTC

   Further investigation identified a synchronisation issue as the underlying cause of the incident. Our technical teams implemented targeted remediation actions, including service restarts, to restore normal operations. Following extended monitoring and post-remediation validation, service performance has remained stable, and we have confirmed that all affected services have returned to normal operation. The issue is now considered resolved.

6. postmortem Aug 03, 2026, 06:37 PM UTC

   **Description:** Flexera One – IT Visibility – EU – Failure to Load Reports **Timeframe:** July 22, 2026, 3:11 AM PDT – July 22, 2026, 11:04 PM PDT **Incident Summary** On July 22, 2026, at approximately 3:11 AM PDT, an issue began affecting IT Visibility reporting functionality in the Flexera One EU production environment. During the affected period, customers in the EU region experienced failures when attempting to load IT Visibility reports and dashboards, including Software Inventory, Hardware Inventory, Technology Intelligence \(TI\), Sustainability, and FinOps reporting views. Technical teams began investigating after multiple customer reports were received regarding report loading failures across the EU region. Initial analysis confirmed the issue was limited to the EU production environment, while equivalent reporting functionality in other regions continued to operate normally. The investigation determined that an authentication-related issue had occurred within the EU reporting environment. As a result, affected reports and dashboards were unable to retrieve the data required to load successfully, causing report loading failures for impacted customers. Technical teams implemented corrective updates within the affected reporting environment and performed validation activities across impacted customer organizations. Following these actions, reports and dashboards resumed normal operation and customers were once again able to access reporting data successfully. Following validation of affected customer environments and confirmation that reports were loading successfully, service functionality was restored and the incident was considered resolved. Technical teams continued monitoring following restoration to ensure ongoing service stability. **Root Cause** The incident was caused by an authentication-related issue within the EU reporting environment. This issue prevented affected reports and dashboards from successfully retrieving the data required to display results, resulting in report loading failures for impacted customers. **Remediation Actions** The following actions were taken during the incident response: 1. Regional Impact Assessment: Technical teams investigated customer reports and confirmed the issue was isolated to the EU production environment. Additional validation was performed across other regions to verify that reporting functionality remained operational outside the affected environment. 2. Authentication Failure Analysis: Technical teams reviewed report processing, authentication workflows, reporting workspaces, and recent platform changes to identify the source of the failures. The investigation determined that affected reports were unable to successfully authenticate when retrieving underlying data required for report rendering. 3. Restoration and Validation Activities: Technical teams applied updates across affected customer environments and reporting workspaces to restore successful report data retrieval. Following implementation, impacted customer organizations were validated to confirm reports and dashboards were loading successfully and displaying data as expected. 4. Post-Recovery Verification: Following restoration, additional monitoring and validation activities were conducted to verify continued report functionality, confirm successful recovery, and ensure service stability across the EU production environment. **Future Preventative Measures** The following follow-up actions were identified during the incident: • Authentication Update Process Review: Technical teams are reviewing the authentication update process to understand why the update was not successfully applied across all affected reporting workspaces in the EU production environment and to identify improvements that will help prevent similar issues in future updates.

Read the full incident report →

Started Jul 22, 2026, 08:25 AM UTC· resolved Jul 22, 2026, 04:16 PM UTC

1. identified Jul 22, 2026, 08:25 AM UTC

   Incident Description: We have identified an issue affecting inventory processing in Flexera One IT Asset Management following the deployment of the 2026 R1.1 release in our US production environment. As a result, some customers may experience degraded performance and intermittent reliability issues when accessing certain areas of the user interface and performing system-related tasks. Priority: P3 Restoration Activity: Our investigation has determined that the issue is related to a software defect introduced with the 2026 R1.1 release. While the defect had been previously identified and mitigation procedures were incorporated into the deployment process, the automated remediation encountered unexpected execution issues . As a result, technical teams have implemented alternative mitigation measures to reduce customer impact and stabilise system performance. We continue to actively monitor the environment and apply corrective actions to address the underlying defect and restore normal service operation.

2. identified Jul 22, 2026, 01:38 PM UTC

   Our teams continue to work on implementing a hotfix to address the issue . During deployment, the hotfix encountered database conditions that are preventing it from completing successfully. Our technical teams are actively working to resolve this and are evaluating targeted mitigation actions to allow the hotfix to complete. Once the hotfix has been successfully applied, teams will validate service performance and continue monitoring to confirm recovery. We will provide another update as more information becomes available.

3. monitoring Jul 22, 2026, 03:40 PM UTC

   The hotfix has been successfully deployed, and engineering teams are currently validating its effectiveness. Teams are continuing to monitor platform behaviour and review telemetry to confirm the issue resolution.

4. resolved Jul 22, 2026, 04:16 PM UTC

   Our teams have completed post-deployment validation and confirmed that service performance has returned to expected levels. Continued monitoring has shown stable platform operation with no further impact observed. Based on these results, this issue is now considered resolved.

5. postmortem Aug 04, 2026, 08:57 PM UTC

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

Read the full incident report →

Started Jul 17, 2026, 10:24 AM UTC· resolved Jul 19, 2026, 12:59 PM UTC

1. investigating Jul 17, 2026, 10:24 AM UTC

   Incident Description: We have identified an issue impacting billing and cost visibility for AWS customers in all regions. As a result of an active service provider disruption, customers may observe inaccurate, incomplete, or delayed estimated cost and usage information within the Billing and Cost Management Console. This issue is limited to AWS-based services and does not affect customers using other cloud platforms. Priority: P2 Restoration Activity: Our technical teams have confirmed that the issue is related to an active AWS service event affecting all regions. We are actively monitoring the situation and working closely with AWS updates to assess customer impact. Service restoration is dependent on AWS resolving the underlying issue, and we will continue to provide updates as additional information becomes available.

2. investigating Jul 17, 2026, 10:27 AM UTC

   We are continuing to investigate this issue.

3. identified Jul 17, 2026, 01:14 PM UTC

   We continue to closely monitor the service provider outage and its impact on affected services. Further updates will be provided as new information becomes available.

4. identified Jul 17, 2026, 06:24 PM UTC

   Our investigation and validation efforts to date have not identified any impact to Spot billing or cost analysis data. The billing and pricing data reviewed remains consistent with expected values. While initial validation results are positive, we are continuing additional validation activities as further data becomes available to confirm these findings. We remain engaged with AWS and will continue to monitor the situation closely. We will share additional updates as our validation activities continue.

5. identified Jul 18, 2026, 08:05 AM UTC

   We remain actively engaged with AWS and continue to closely monitor the situation. AWS has identified the root cause and implemented mitigation measures to address the underlying issue that resulted in incorrect estimated cost and usage data being displayed. AWS has begun backfilling data to restore accurate cost and usage information for all customers and full recovery is expected by 18 July 2026, 12:00 PM PDT.

6. monitoring Jul 18, 2026, 07:33 PM UTC

   We continue to monitor the AWS service event and remain engaged with AWS as they complete their recovery activities. Validation completed to date has not identified any impact to Spot billing or cost analysis data. We are continuing to monitor the situation and complete any remaining validation activities before determining closure of this incident.

7. resolved Jul 19, 2026, 12:59 PM UTC

   AWS resolved their service disruption on 18 July at 6:57 AM PDT. Following successful validation by our technical teams, we have confirmed that service functionality has been restored .

8. postmortem Jul 30, 2026, 06:10 PM UTC

   **Description:** Flexera Spot – AWS Billing Service Disruption Timeframe: July 17, 2026, 1:33 AM PDT – July 18, 2026, 6:57 AM PDT **Incident Summary** On July 17, 2026, at approximately 1:33 AM PDT, Flexera technical teams became aware of an AWS issue affecting estimated billing and usage data displayed within AWS Billing and Cost Management, Cost Explorer, and Cost and Usage Reports. Given the nature of the AWS service disruption, technical teams initiated an investigation to determine whether Spot billing, cost analysis, or savings calculations for AWS customers were affected. During the investigation, teams reviewed the billing and pricing data used by Spot, validated relevant cost and pricing tables, monitored AWS updates, and assessed whether any customer-facing billing or savings data had been impacted. Technical teams validated the billing and pricing data used by Spot and confirmed that the relevant cost and pricing tables were operating as expected. The investigation did not identify any issues within the data used by Spot, and no incorrect billing or savings calculations were observed. AWS subsequently confirmed that the issue originated within AWS Billing and Cost Management services, identified and mitigated the underlying issue, and completed data recovery and backfill activities. Based on the validation performed throughout the investigation, no customer impact was observed within Spot. Following confirmation of AWS recovery and completion of post-recovery validation activities, the incident was considered resolved. **Root Cause** The incident was caused by an AWS service issue affecting estimated billing and usage data displayed within AWS Billing and Cost Management, Cost Explorer, and Cost and Usage Reports. AWS identified and mitigated the underlying issue and completed data recovery activities. **Remediation Actions** The following actions were taken during the incident response: • Incident Investigation Initiated: Technical teams began investigating the AWS billing and usage data issue to determine whether Spot customers were affected. • Impact Assessment Performed: Technical teams evaluated whether the AWS service disruption affected Spot billing analysis and savings calculations. • Data Validation Completed: Teams reviewed and validated the billing and pricing data used by Spot and confirmed that relevant cost and pricing tables were operating as expected. • AWS Recovery Monitored: Technical teams monitored AWS communications, service updates, and recovery activities throughout the incident. • Post-Recovery Validation Performed: Additional validation was completed following AWS recovery and data backfill activities to confirm the integrity of billing and pricing data used by Spot. • Incident Resolved: The incident was closed after AWS confirmed recovery and technical validation identified no impact within Spot. **Future Preventative Measures** The following follow-up actions were identified during the incident: • AWS Collaboration and Review: Continue working closely with AWS to understand the underlying cause of provider-managed incidents and review any recommendations or learnings resulting from their investigation. • Resiliency and Validation Review: Review opportunities to further strengthen validation processes for billing-related data to support faster impact assessment and response during similar third-party service disruptions in the future.

Read the full incident report →

Started Jul 17, 2026, 08:24 AM UTC· resolved Jul 18, 2026, 07:29 PM UTC

1. identified Jul 17, 2026, 08:24 AM UTC

   Incident Description: We have identified an issue affecting inventory processing in Flexera One IT Asset Management following the deployment of the 2026 R1.1 release in our APAC and Europe environments. As a result, a subset of customers may experience degraded performance when accessing certain areas of the user interface and while performing system-related tasks. Priority: P3 Restoration Activity: Our technical teams have identified the issue as a software defect introduced with the 2026 R1.1 release. Mitigation measures have been implemented to reduce customer impact, and teams are actively working to fully restore service performance. We will continue to provide updates as progress is made.

2. identified Jul 17, 2026, 03:58 PM UTC

   We continue to make progress in addressing the performance issues affecting a subset of customers in the APAC and Europe production environments. The identified fixes have now been deployed, and we are actively monitoring the environment as customer processing activities continue. Our teams are validating the effectiveness of these changes and assessing overall platform performance. We will provide additional updates as more information becomes available.

3. monitoring Jul 18, 2026, 08:10 AM UTC

   Our teams continue to validate the recently deployed hotfixes, and initial results look positive. We are closely monitoring affected processing activities to confirm the effectiveness of the fix and ensure platform stability. Validation is ongoing, and we will continue to monitor performance before confirming full resolution. We will provide another update as more information becomes available.

4. resolved Jul 18, 2026, 07:29 PM UTC

   Following deployment of the identified fixes, previously impacted processing activities are now completing successfully, and we are no longer seeing recurrence of the issues observed following the recent release. Based on the results observed after deployment of the fixes, this incident is now resolved. We will publish a full RCA in the coming days that will include a detailed summary of the issue, root cause, and preventative measures being implemented to help prevent recurrence.

5. postmortem Jul 30, 2026, 05:47 PM UTC

   **Description:** Flexera One – IT Asset Management – APAC & EU – Slowness and Degraded Performance **Timeframe:** July 13, 2026, 1:00 PM PDT – July 18, 2026, 7:10 AM PDT **Incident Summary** On July 13, 2026, at approximately 1:00 PM PDT, an issue began affecting Flexera One IT Asset Management customers in the APAC and Europe production environments following deployment of the 2026 R1.1 release. During the affected period, some customers experienced intermittent application slowness, delayed processing, reconcile failures, and degraded performance when accessing certain areas of the application or performing inventory-related activities. As customer reports increased, technical teams began investigating common patterns across the reported symptoms to determine the underlying cause. The investigation identified a defect introduced as part of the Flexera One IT Asset Management 2026 R1.1 release. Under certain conditions, the defect resulted in significantly higher database processing activity during inventory-related operations. As inventory data was processed, the increased workload contributed to processing delays, timeout conditions, and degraded application performance for some customers. Technical teams developed and deployed hotfixes to address the issue in the affected production environments. Following deployment, teams performed validation activities and monitored impacted processing workflows to confirm recovery. By July 18, 2026, at approximately 7:10 AM PDT, validation confirmed successful processing of previously impacted workloads and that the failure patterns associated with the issue were no longer occurring. The incident was considered resolved and technical teams continued monitoring to confirm service stability. **Root Cause** The incident was caused by a defect introduced in the Flexera One IT Asset Management 2026 R1.1 release affecting inventory-related processing operations. Under certain conditions, the defect caused significantly more database processing activity than intended during inventory-related processing operations. This increased workload resulted in elevated resource consumption, processing delays, and timeout conditions. These conditions contributed to intermittent application slowness, delayed processing, reconcile failures, and degraded performance affecting some IT Asset Management functionality. **Remediation Actions** 1. Incident Investigation Initiated: Technical teams began investigating reports of application slowness, processing delays, and reliability issues affecting APAC and Europe production environments. 2. Impact Assessment Performed: Teams reviewed customer-reported symptoms, system performance data, and processing behavior to determine the scope and nature of the issue. 3. Cause Identified: Investigation determined that a defect introduced in the 2026 R1.1 release was generating excessive processing activity during inventory-related operations. 4. Hotfixes Developed and Deployed: Technical teams developed and deployed hotfixes to correct the affected processing behavior in the APAC and Europe production environments. 5. Recovery Validated: Teams validated the effectiveness of the hotfixes through monitoring and successful execution of previously impacted processing activities. 6. Post-Restoration Monitoring Performed: Additional monitoring confirmed that the previously observed failures and performance degradation were no longer occurring and that service stability had been restored. **Future Preventative Measures** Based on the investigation, the following follow-up activity has been identified: • Processing Logic Improvements: Technical teams implemented corrections to the affected processing logic to eliminate the inefficient behavior that contributed to increased resource consumption and performance degradation.

Read the full incident report →

Started Jul 14, 2026, 09:13 AM UTC· resolved Jul 15, 2026, 07:51 PM UTC

1. resolved Jul 14, 2026, 09:13 AM UTC

   Incident Description:Our teams identified an issue affecting Cognos Analytics in the EU Production environment. During the impact window, affected customers may have been unable to access or load Cognos Analytics. Current investigation confirmed that the impact was limited to the EU Production region. Priority:P2 Restoration Activity: Our technical teams determined that the issue was related to a recent upgrade to Cognos Analytics , which was completed as part of the EU Production IT Asset Management release activities. The team identified a configuration issue introduced during the upgrade, implemented the necessary configuration corrections, and restored normal service functionality. The environment remains stable under monitoring. Further details, including the root cause and preventative measures, will be shared in a post-mortem report.

2. postmortem Jul 26, 2026, 07:06 AM UTC

   **Description:** Flexera One - IT Asset Management - EU - Congnos analytics access issue **Timeframe:** July 13, 2026, 12:51 PM PDT to July 14, 2026, 1:52 AM PDT ‌ **Incident Summary** ‌ On Monday, July 13, 2026, at 12:51 PM PDT, Following the Cognos Analytics 12.1.2 upgrade implemented as part of the Flexera One IT Asset Management release in the Europe \(EU\) Production environment, our teams identified an issue that prevented customers from accessing Cognos Analytics. As a result, affected users were unable to successfully launch the application after the scheduled maintenance activities had been completed. Technical teams immediately initiated an investigation and confirmed that the issue was isolated to the EU Production environment, with no impact observed in any other production regions. Further analysis determined that the upgrade itself had completed successfully; however, a portion of the required post-upgrade configuration activities had not been fully applied, preventing Cognos Analytics from starting correctly. The remaining configuration tasks were promptly completed, restoring normal Cognos Analytics functionality. Following comprehensive validation of customer access and a period of enhanced monitoring, the service was confirmed to be operating normally and the incident was declared resolved. ‌ **Root Cause** ‌ * Incomplete Post-Upgrade Configuration: Although the Cognos Analytics 12.1.2 upgrade completed successfully, required post-upgrade configuration tasks were not fully completed before the environment was returned to service. * Service Initialization Failure: The incomplete configuration prevented Cognos Analytics from initializing correctly, resulting in customers being unable to access the application. * Regional Impact: The issue was limited to the EU Production environment. No impact was identified in North America, APAC, or other production regions. ‌ **Remediation Actions** ‌ To restore service, technical teams: * Completed the required post-upgrade configuration activities that had not been fully applied during the deployment. * Restarted and validated Cognos Analytics services to confirm successful application initialisation. * Performed functional testing and customer access validation to verify that reporting capabilities were operating as expected. * Placed the environment under enhanced monitoring following recovery to ensure continued service stability. ‌ **Future Preventative Measures** ‌ * Enhanced Post-Upgrade Validation: Strengthen deployment validation procedures to verify that all required post-upgrade configuration activities have completed successfully before concluding maintenance activities. * Improved Monitoring and Alerting: Enhance Cognos Analytics monitoring and alerting to enable earlier detection of service degradation following upgrades. * Deployment Checklist Improvements: Update deployment runbooks and operational checklists to include additional verification of post-upgrade configuration completion prior to returning the environment to production service. * Operational Readiness Review: Review upgrade execution procedures to ensure all mandatory post-deployment tasks are completed and validated before maintenance windows are closed.

Read the full incident report →

Started Jul 12, 2026, 11:51 PM UTC· resolved Jul 13, 2026, 03:44 AM UTC

1. investigating Jul 12, 2026, 11:51 PM UTC

   Incident Description: We are experiencing an issue affecting Flexera One IT Asset Management (ITAM) customers in the APAC region. Customers may notice that certain navigation and menu items within the ITAM interface are not visible, resulting in limited access to some functionality. Priority: P2 Restoration Activity: Our technical teams are actively investigating this issue and working to restore full functionality. We will continue to provide updates as more information becomes available.

2. identified Jul 13, 2026, 12:28 AM UTC

   Our investigation has identified elevated resource utilization affecting the functionality associated with the reported issue. Mitigation actions are currently underway, including increasing system capacity to support recovery efforts. We are actively monitoring the environment and validating platform behavior as these changes are implemented. Work remains ongoing to restore full functionality for affected customers, and we will share additional updates as progress is made.

3. identified Jul 13, 2026, 01:52 AM UTC

   Our investigation has identified a potential configuration issue associated with the affected functionality. As part of ongoing mitigation efforts, configuration changes have been reverted, and previously initiated capacity increases have now been completed. We are actively monitoring the environment and validating platform behavior as these changes take effect. Work remains ongoing to restore full functionality for affected customers, and we will provide further updates as progress is made.

4. resolved Jul 13, 2026, 03:44 AM UTC

   Following extended monitoring, we have confirmed that service performance has remained stable and is operating as expected. This issue is now resolved.

5. postmortem Aug 12, 2026, 05:15 AM UTC

   **Description:** Flexera One - IT Asset Management - APAC - Missing Menu Items **Timeframe:** July 12, 2026, 3:00 PM PDT - July 12, 2026, 7:16 PM PDT **Incident Summary** On Sunday, July 12, 2026, at 3:00 PM PDT, customers in the APAC production environment began reporting that several IT Asset Management \(ITAM\) menu items, including functionality such as Reports and All Applications, were no longer visible within the Flexera One user interface. Multiple customers were affected, impacting their ability to navigate and access portions of the ITAM application. Technical teams immediately began investigating the issue and identified authentication-related errors affecting the ITAM user interface. During the investigation, teams reviewed infrastructure health, application behavior, and recent platform changes to determine the source of the problem. The investigation determined that an application configuration change associated with a newly introduced authentication capability had been incorrectly applied to the production environment. The issue became apparent when application instances were refreshed, resulting in authentication-related failures that prevented certain ITAM menu items from loading correctly for affected users. Technical teams reverted the affected configuration, refreshed the impacted application instances, and validated recovery across the environment. Following these actions, menu functionality was restored, affected customers confirmed recovery, and the incident was resolved on July 12, 2026, at 7:16 PM PDT after validation and monitoring confirmed normal operation had returned. **Root Cause** Investigation determined that an application configuration change associated with a new authentication capability was incorrectly applied to the production environment. When application instances were subsequently refreshed, the incorrect configuration resulted in authentication-related errors within the ITAM user interface. These errors prevented certain navigation components from loading correctly, causing affected users to experience missing menu items until the configuration was corrected and the affected instances were refreshed. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Investigation Initiated: Technical teams began investigating after receiving reports from multiple customers regarding missing ITAM menu items. 2. Application Configuration Reviewed: Recent application and configuration changes were reviewed to identify the source of the menu-loading failures. 3. Incorrect Configuration Identified: Technical teams determined that an authentication-related configuration change had been incorrectly applied to the production environment. 4. Configuration Corrected: The affected configuration was removed from the impacted production instances. 5. Application Instances Refreshed: Impacted application instances were refreshed to ensure the corrected configuration was consistently applied across the environment. 6. Recovery Validation Performed: Technical teams validated menu visibility and functionality across the affected environment and confirmed recovery with impacted customers. **Future Preventative Measures** Following the incident, corrective measures were implemented to prevent recurrence of the issue and improve detection of similar conditions in the future. 1. Configuration Control Validation: The incorrect authentication-related configuration was removed from environments where it was not intended to be deployed. This change prevents the same configuration issue from being introduced into affected environments in the future. 2. Health Check Monitoring Improvements: The existing health check was updated to detect the application behavior associated with this failure condition. The revised monitoring is designed to identify similar menu-loading and authentication-related application failures more effectively and accelerate detection should a similar issue occur in the future.

Read the full incident report →

Started Jul 06, 2026, 02:19 PM UTC· resolved Jul 06, 2026, 04:57 PM UTC

1. investigating Jul 06, 2026, 02:19 PM UTC

   Incident Description: We are currently investigating degraded performance affecting the Spot Ocean ECS console for AWS customers. Customers may experience significant slowness or delays when accessing or navigating the console. Priority: P2 Restoration Activity: Our technical teams are actively investigating and working to restore normal functionality. We will provide further updates as more information becomes available.

2. monitoring Jul 06, 2026, 03:11 PM UTC

   Our investigation identified that the degradation was related to an AWS service health event impacting the us-east-1 region. AWS has since reported that the issue has been resolved, and we are now seeing signs of recovery on our side, including improved Spot Ocean ECS console performance and successful completion of related AWS workflows. The production environment appears stable at this time. Our teams will continue monitoring for a short validation period to ensure performance remains stable before marking the incident resolved.

3. resolved Jul 06, 2026, 04:57 PM UTC

   We have continued to monitor the environment for an extended period and services have remained stable, with no further issues observed. This incident has been resolved.

4. postmortem Jul 20, 2026, 07:00 AM UTC

   **Description:** Spot Ocean – AWS – Ocean ECS Console Performance Degradation **Timeframe:** July 6, 2026, 05:45 AM PDT to July 6, 2026, 07:53 AM PDT ‌ **Incident Summary** ‌ On Monday, July 6, 2026, at 05:45 AM PDT , our teams identified a performance degradation affecting Spot Ocean ECS for AWS customers. During the impact window, customers experienced increased latency when accessing the Ocean ECS console, and some AWS-related operations were delayed or did not complete successfully. Technical teams immediately initiated an investigation to identify the source of the issue. As an AWS service disruption was occurring concurrently in the AWS us-east-1 region, the investigation initially considered both the external AWS event and a recently completed production deployment as potential contributing factors. Through detailed analysis, teams determined that the primary cause of the customer impact was instability introduced by the recent Gateway deployment. The resulting degradation in Gateway performance affected request processing and responsiveness within Spot Ocean ECS. While the concurrent AWS service disruption added complexity to the investigation, it was confirmed not to be the primary driver of the customer-facing impact. To restore service, teams rolled back the deployment to the previous stable version. Following the rollback, platform performance returned to expected levels and customer workflows resumed normal operation. An extended period of monitoring confirmed sustained service stability before the event was formally resolved. ‌ **Root Cause** ‌ The incident was caused by instability introduced in a Gateway deployment .The deployment resulted in degraded performance within the Gateway service, reducing its ability to efficiently process customer requests. This caused increased response times and intermittent failures for Spot Ocean ECS console operations and AWS-related workflows. Rolling back to the previous stable Gateway version restored normal platform performance and resolved the customer impact. Contributing Factors * A concurrent AWS service disruption in the us-east-1 region occurred during the same timeframe. While it was not the cause of the incident, it complicated the initial investigation and delayed identification of the underlying Gateway issue. * The Gateway rollback required additional time due to the scale of the production deployment, extending the overall recovery process. * Operations involving resource creation and updates experienced greater impact than read-only activities because of the degraded Gateway responsiveness. ‌ **Remediation Actions** ‌ * Technical teams investigated the degradation and identified a recent Gateway deployment as the primary source of the issue. * The affected Gateway deployment was rolled back to last know stable version, restoring service stability. * Platform performance and customer-facing workflows were validated following the rollback. * Technical teams completed an extended monitoring period to confirm stable service operation before closing the incident. ‌ **Future Preventative Measures** ‌ * Improved Deployment Safeguards - Engineering teams will strengthen deployment controls and validation processes to reduce the likelihood of similar deployment-related issues affecting production environments. * Enhanced Platform Monitoring - Additional monitoring and alerting will be implemented to provide earlier detection of abnormal Gateway behavior, including service responsiveness, resource utilization, and application stability. * Improved Recovery Procedures - Rollback procedures will be enhanced and regularly validated to reduce recovery time and improve operational efficiency during deployment-related incidents. * Proactive Service Health Validation - Synthetic health checks will be expanded to continuously validate critical Ocean ECS user workflows, enabling earlier identification of customer-facing performance degradation. * Enhanced Dependency Monitoring - Engineering teams will continue improving visibility into external cloud service events and platform dependencies to enable faster differentiation between internal platform issues and third-party service disruptions during future investigations.

Read the full incident report →

Started Jul 03, 2026, 06:20 PM UTC· resolved Jul 03, 2026, 06:50 PM UTC

1. resolved Jul 03, 2026, 07:07 PM UTC

   Incident Description: We identified an issue affecting a subset of Flexera One services in the APAC region, which may have resulted in intermittent access issues or failures for some users. The impact was intermittent, and other regions were not impacted. The issue has been resolved, and affected services are operating normally. Priority: P2 Restoration Activity: Our technical teams investigated the issue and reverted a recent change to restore service. We validated that the affected services are functioning normally and continued monitoring to ensure platform stability. This incident has been resolved.

2. postmortem Jul 17, 2026, 06:11 AM UTC

   **Description:** Flexera One – APAC – Intermittent Access Issues **Timeframe:** July 3, 2026, 11:20 AM PDT – July 3, 2026, 11:50 AM PDT **Incident Summary** On July 3, 2026, at approximately 11:20 AM PDT, an issue was identified affecting a subset of Flexera One services in the APAC production environment. During the incident window, some customers may have experienced intermittent access issues or failures when accessing certain areas of the Flexera One platform. The impact was intermittent in nature, as redundant service capacity remained available and continued serving traffic during the incident. Other Flexera One regions, including NAM and EU, were not impacted. Technical teams began investigating immediately and reviewed the affected services and supporting platform components within the APAC environment. The investigation identified that a recent change made within the APAC environment was contributing to the intermittent service failures being observed. As part of the recovery effort, the change was reverted and service behavior was monitored to validate recovery. Following the rollback, service stability was restored and customers were able to access affected functionality normally. By approximately 11:50 AM PDT, services were operating as expected and the incident was considered resolved. ‌ **Root Cause** The incident was caused by a configuration change within the APAC environment that unintentionally affected communication between a subset of platform services and a backend platform component. During the investigation, technical teams determined that the change resulted in certain platform services being unable to communicate properly with the affected component. This led to intermittent failures affecting a subset of Flexera One services in the APAC region. While the issue was occurring, one or more pods supporting the affected services remained available and continued serving traffic. As a result, customers experienced intermittent access issues rather than a complete service outage. ‌ **Remediation Actions** The following actions were taken during the incident response: • Incident Investigation Initiated: Technical teams began investigating intermittent access issues affecting a subset of Flexera One services in the APAC region. • Platform Review Completed: Technical teams reviewed the affected services and supporting platform components within the APAC environment to identify the source of the issue. • Recent Change Identified: Investigation identified a recently implemented change that correlated with the observed service degradation. • Change Reverted: The identified change was reverted as part of the mitigation effort to restore normal service behavior. • Service Recovery Validated: Technical teams monitored service behavior following the rollback and confirmed that affected functionality was operating normally. • Platform Stability Monitoring Continued: Additional monitoring was performed after restoration activities to verify continued service stability before the incident was closed. ‌ **Future Preventative Measures** This incident highlighted the importance of validating platform changes to ensure unintended impacts are identified before they affect service availability. Based on the investigation, the following follow-up activities are being pursued: • Configuration Validation Improvements: Review and enhance validation processes for infrastructure and platform configuration changes to help identify unintended impacts before changes are implemented in production environments. • Post-Deployment Verification Enhancements: Review post-deployment verification procedures to ensure critical service dependencies remain accessible and functioning as expected following configuration changes.

Read the full incident report →

Started Jun 24, 2026, 04:00 PM UTC· resolved Jun 25, 2026, 06:35 AM UTC

1. resolved Jun 25, 2026, 06:54 AM UTC

   Incident Description: We identified an issue affecting inventory processing in Flexera One IT Asset Management following the 2026 R1 release in the APAC and Europe production environments, as well as the corresponding UAT environments. As a result, some inventory uploads were not processed successfully, causing inventory data displayed in Flexera One IT Asset Management to be delayed and not reflect the most recently uploaded customer inventory. Priority: P2 Restoration Activity: Technical teams identified a capacity-related issue affecting inventory processing and performed targeted service restarts across the impacted regions to restore normal processing. Service was restored by June 24, 2026, 11:00 PM PDT, and inventory files are now processing successfully. Our teams are continuing to monitor the platform to ensure sustained stability. A post-mortem report detailing the root cause and preventative measures will be shared once the investigation is complete.

2. postmortem Jul 15, 2026, 06:18 AM UTC

   **Description:** Flexera One- IT Asset management- APAC & EU - NDI Inventory Import Failures **Timeframe:** June 18, 2026, 09:00 AM PDT to June 25, 2026, 02:42 AM PDT ‌ **Incident Summary** ‌ On Wednesday, June 24, 2026, 11:35 PM PDT, following the deployment of the Flexera One IT Asset Management 2026 R1 release to the Australia and Europe Production environments, our teams identified an issue affecting the processing of NDI inventory files. As a result, a significant number of inventory files failed during processing and were not reflected in customer inventory data, causing inventory information displayed in Flexera One ITAM to become outdated for affected customers. Technical teams immediately initiated an investigation and determined that the issue occurred within the inventory processing workflow introduced with the 2026 R1 release. Failed inventory files accumulated following repeated processing failures, preventing successful completion of inventory updates and contributing to increased processing load on the affected services. To restore service, technical teams implemented corrective actions by refreshing the affected application services across impacted environments. Following the restoration activities, inventory processing resumed successfully, and new inventory uploads were processed as expected. Continued monitoring confirmed stable platform behavior, and the incident was declared resolved after sustained validation. ‌ **Root Cause** ‌ The issue was caused by a defect introduced with the Flexera One IT Asset Management 2026 R1 release that affected the processing of NDI inventory files. Under specific conditions, inventory files could not be processed successfully due to an issue within the authentication and processing workflow, causing the files to be rejected before processing could complete. As failed files accumulated, processing capacity was increasingly consumed by repeated failures, preventing successful inventory processing and delaying inventory updates for affected customers. Contributing Factors * Failed inventory files accumulated within the processing workflow, increasing resource utilization on affected inventory services. * The increased processing load reduced the capacity available for new inventory processing requests. * The issue affected production environments running the 2026 R1 release; North America Production was not impacted because the release had not yet been deployed. ‌ **Remediation Actions** ‌ * Technical teams identified the affected inventory processing workflow and implemented corrective actions to restore service. * Application services were refreshed across the impacted production environments, restoring normal inventory processing. * Processing of new inventory files resumed successfully following the service restoration. * The environment remained under enhanced monitoring to validate processing performance and confirm sustained recovery. ‌ **Future Preventative Measures** ‌ * Improved Release Validation - Release validation procedures will be enhanced to include additional end-to-end testing of inventory processing workflows following major platform releases. * Enhanced Processing Monitoring - Monitoring and alerting will be reviewed and expanded to provide earlier detection of abnormal inventory processing failures and excessive file accumulation within processing queues. * Operational Resiliency - Additional safeguards will be implemented within the inventory processing workflow to improve recovery from processing failures and minimize customer impact should similar conditions occur in the future. * Code Quality and Review Improvements \(Completed\) - As part of the post-incident review, the affected code has been corrected to ensure failures in communication are handled appropriately and do not result in broader processing impacts. In addition, the development and review process has been reinforced to ensure that review findings are appropriately evaluated and addressed before future changes are approved for release.

Read the full incident report →

Started Jun 24, 2026, 08:00 AM UTC· resolved Jun 24, 2026, 09:00 AM UTC

1. investigating Jun 24, 2026, 08:00 AM UTC

   Incident Description: We have identified an issue affecting login access to Flexera One in the EU region. Customers may receive errors when attempting to log in to Flexera One. Priority: P1 Restoration Activity: Our technical teams are actively investigating the issue and working to implement corrective actions to restore normal login functionality. Investigation and stabilization efforts remain ongoing. We will continue to monitor the situation closely and provide further updates as progress continues.

2. resolved Jun 24, 2026, 09:00 AM UTC

   The issue has been resolved, and login functionality has been restored for affected customers. Technical teams identified the cause of the issue and implemented corrective actions to restore normal service operation. The environment remains stable, and ongoing monitoring has confirmed successful authentication and platform access. A post-mortem report containing additional details, will be shared upon completion of the investigation.

3. postmortem Jul 07, 2026, 08:28 AM UTC

   **Description:** Flexera One – EU – Login Access Disruption **Timeframe:** June 24, 2026, 12:41 AM PDT to June 24, 2026, 02:04 AM PDT ‌ **Incident Summary** ‌ On Wednesday, June 24, 2026, at 12:41 AM PDT, our teams detected an issue affecting customers in the EU region. Impacted users experienced authentication failures when attempting to sign in to Flexera One using Single Sign-On \(SSO\), resulting in server errors and preventing access to the platform. Upon detection, technical teams immediately initiated an investigation and confirmed that the issue was isolated to the authentication workflow. Validation of the application and underlying platform services showed that all core infrastructure remained healthy and operational. Further analysis determined that a service account used to communicate with the identity provider had become unavailable, causing authentication requests to fail. The service account was promptly restored, which re-established normal authentication processing and fully restored customer access. Following restoration, the environment was closely monitored and login functionality was comprehensively validated to ensure service stability. No additional customer impact was observed, and the incident was subsequently declared resolved. ‌ **Root Cause** ‌ The issue was caused by the unintended suspension of a service account that supports authentication between Flexera One and the identity provider. As a result, authentication requests could not be processed successfully, preventing affected customers in the EU production region from accessing the platform through Single Sign-On \(SSO\). Contributing Factors * A service account critical to the authentication workflow was inadvertently suspended during a routine cleanup activity. * The suspension prevented authentication requests from being validated successfully, resulting in login failures for impacted customers. * The issue was isolated to the authentication service and did not affect the availability of the underlying application or platform infrastructure. ‌ **Remediation Actions** ‌ * The affected service account was restored, re-establishing authentication with the identity provider. * Login functionality was validated following restoration. * Engineering teams continued monitoring to confirm platform stability and successful customer authentication. ‌ **Future Preventative Measures** ‌ * Service Account Governance - Processes governing critical service accounts will be strengthened to reduce the risk of inadvertent changes affecting production services. * Enhanced Monitoring - Monitoring and alerting will be enhanced to provide earlier detection of authentication failures affecting customer login workflows. * Operational Process Improvements - Our teams have documented this as lesson learnt and will implement process improvements to reduce the likelihood of similar incidents.

Read the full incident report →

Started Jun 18, 2026, 03:33 PM UTC· resolved Jun 18, 2026, 06:08 PM UTC

1. monitoring Jun 18, 2026, 03:33 PM UTC

   Incident Description: We experienced an issue affecting Snow Atlas in the West Europe region. During the incident window, customers may have experienced errors that prevented access to the platform and impacted functionality. Priority: P1 Restoration Activity: Service has been restored and is currently stable. Our technical teams are continuing to investigate a disruption affecting underlying dependent services in the region. Efforts are focused on ensuring stability and preventing recurrence. We will continue to monitor closely and provide updates as more information becomes available.

2. resolved Jun 18, 2026, 06:08 PM UTC

   The issue affecting Snow Atlas in the West Europe region has been resolved, and service is currently operating normally. Our technical teams have mitigated the underlying service instability and continue to monitor closely to ensure sustained stability. We will provide a detailed post-incident report outlining the root cause and preventative measures in the coming days.

3. postmortem Jul 07, 2026, 08:57 AM UTC

   **Description:** Snow Atlas - West Europe - Service Disruption **Timeframe:** June 18, 2026, 07:00 AM PDT to June 18, 2026, 08:23 AM PDT ‌ **Incident Summary** ‌ On Thursday, 18 June 2026 at 07:00 AM PDT, customers in the West Europe production region experienced a service disruption that affected access to Snow Atlas. During this service event, users encountered HTTP 504 timeout and HTTP 404 errors, which prevented access to the platform and impacted the use of Snow Atlas functionality. Upon detection, technical teams immediately initiated an investigation and identified the issue within a core platform component responsible for communication between backend services. The degradation disrupted service interactions, resulting in request failures and temporary service unavailability. The affected messaging components were restored, enabling dependent services to recover and normal platform operations to resume. Following recovery, extensive validation activities confirmed that service functionality had been fully restored. The environment remained stable under enhanced monitoring, no further customer impact was observed, and the service disruption was formally resolved. ‌ **Root Cause** ‌ The service disruption originated from an unexpected failure within a core platform component that facilitates communication between backend services. During the event, multiple messaging components became unavailable simultaneously, preventing critical communication between backend services responsible for processing customer requests. The degradation impaired the ability of dependent services to exchange and process requests, leading to timeouts and routing failures. As a result, customers in the affected region experienced difficulty accessing the Snow Atlas platform until service communications were restored and normal operations resumed. Contributing Factors * Multiple messaging service components became unavailable at the same time, reducing the platform's ability to process inter-service communication. * Service communication failures propagated across dependent platform components, resulting in HTTP 504 timeout and HTTP 404 errors. * The issue affected the shared messaging infrastructure supporting the West Europe production environment, resulting in widespread customer impact within the region. ‌ **Remediation Actions** ‌ * Technical teams identified the affected messaging infrastructure components and restored normal service operation. * Dependent platform services recovered automatically as messaging functionality was re-established. * Service functionality was validated following recovery to confirm successful customer access. * Enhanced monitoring was maintained after restoration to verify continued platform stability. ‌ **Future Preventative Measures** ‌ * Problem Management Review – A comprehensive review is underway to further validate the root cause and identify long-term corrective actions to prevent recurrence. * Platform Resiliency Enhancements – Opportunities to strengthen the resiliency of the platform's messaging infrastructure will be evaluated to reduce the impact of component-level failures on service availability. * Monitoring and Detection Improvements – Monitoring and alerting capabilities for critical platform components will be enhanced to enable earlier identification of degradation and accelerate response and recovery efforts.

Read the full incident report →

Started Jun 18, 2026, 02:44 PM UTC· resolved Jun 18, 2026, 03:06 PM UTC

1. investigating Jun 18, 2026, 02:44 PM UTC

   Incident Description: We are investigating an issue affecting Data Explorer functionality for Flexera One IT Visibility in the APAC region. As a result, customers may experience failures when running queries, delays in retrieving data, and issues accessing related features that depend on Data Explorer. Priority: P2 Restoration Activity: Our technical teams are actively investigating a disruption impacting upstream services required for Data Explorer. Recovery efforts are focused on restoring connectivity between dependent services and stabilizing query processing and data access. We will continue to monitor progress and provide updates as more information becomes available.

2. resolved Jun 18, 2026, 03:06 PM UTC

   This issue has been resolved. Data Explorer functionality in the APAC region has been fully restored following the identification and rollback of a recent service change that was impacting service communication. All services have been validated and are operating as expected. A full post-incident report, including detailed root cause and preventative measures, will be shared in the coming days.

3. postmortem Jul 07, 2026, 06:33 AM UTC

   **Description:** Flexera One – IT Visibility – APAC – Data Explorer Service Disruption **Timeframe:** June 17, 2026, 6:47 PM PDT – June 18, 2026, 7:46 AM PDT **Incident Summary** During the incident window, customers experienced issues with Data Explorer functionality for Flexera One IT Visibility in the APAC region. Affected customers experienced failures when running queries, delays and errors when retrieving data, and issues accessing related functionality that depends on Data Explorer. Some dependent functionality, including reporting and connections, did not operate as expected. Technical teams investigated and identified that Data Explorer and related services were unable to successfully communicate with required internal services used for request processing. This resulted in query execution failures and degraded behavior for related data and connection workflows. As part of the recovery effort, technical teams identified the issue and reverted the changes to restore the previous stable state. Following the rollback, connectivity between services was restored, and Data Explorer, query execution, reporting, connections, and related functionality returned to expected behavior. By June 18, 2026, at approximately 7:46 AM PDT, services had been validated and confirmed to be operating normally across APAC. The impact was limited to APAC. North America and Europe remained unaffected throughout the incident. **Root Cause** The issue occurred during an ongoing migration of internal platform services, where services were being moved incrementally to a new platform. During this activity, a change introduced while migrating a majority of dependent services caused a disruption in service-to-service connectivity. This impacted downstream components that rely on those services for request processing. The issue was not observed during validation performed before and after the migration activity. After the connectivity disruption occurred, Data Explorer and related services were unable to successfully communicate with the required internal services. This caused failures when running queries, delays and errors when retrieving data, and issues with dependent functionality including reporting and connections. **Remediation Actions** The following actions were taken during the incident response: 1. **Incident Investigation Initiated:** Technical teams investigated reports of Data Explorer issues affecting Flexera One IT Visibility in the APAC region. 2. **Impact Scope Reviewed:** The issue was confirmed to affect APAC. North America and Europe were reviewed and confirmed to be operating as expected. 3. **Dependent Functionality Reviewed:** Technical teams reviewed related functionality, including query execution, reporting, and connection-related workflows. 4. **Service Communication Issue Identified:** Technical teams identified that downstream services were unable to successfully communicate with required internal services. 5. **Migration Activity Reviewed:** Technical teams determined that the issue occurred during an ongoing migration of internal platform services to a new platform. 6. **Changes Reverted:** The changes introduced during the migration activity were reverted to restore the previous stable state. 7. **Service Connectivity Restored:** Following the rollback, connectivity between services was restored. 8. **Service Recovery Validated:** Technical teams validated Data Explorer, query execution, reporting, connections, and related functionality and confirmed that services were operating normally in APAC. **Future Preventative Measures** This incident highlighted the importance of planning, visibility, and validation for internal platform migration activities that may affect customer-facing services or downstream dependencies. Based on the investigation, the following follow-up activities are being reviewed: * **Migration Assessment and Planning:** Review assessment and planning practices for internal platform migration activities to better identify downstream dependencies, required validation steps, impacted workflows, and any potential customer impact before migration work is performed. * **Scheduled Maintenance Planning:** Ensure internal platform migration activities with any potential customer impact are planned and communicated through a scheduled maintenance window. * **Validation Coverage Review:** Review validation practices for migration activity to help ensure testing covers dependent customer-facing workflows before and after migration work is performed, especially where prior validation does not identify service-to-service connectivity issues.

Read the full incident report →

Started Jun 18, 2026, 12:45 PM UTC· resolved Jun 18, 2026, 01:16 PM UTC

1. investigating Jun 18, 2026, 12:45 PM UTC

   Incident Description: We have identified an issue affecting access to Flexera One IT Asset Management (ITAM) in the APAC region. Affected customers may encounter errors when attempting to access ITAM pages and functionality within the Flexera One platform. Priority: P1 Restoration Activity: Technical teams have engaged and are actively investigating the issue to determine the underlying cause. Initial remediation efforts are underway, and teams are working to restore normal service functionality as quickly as possible. We are closely monitoring the environment and will provide additional updates as more information becomes available.

2. resolved Jun 18, 2026, 01:16 PM UTC

   The issue was traced to a recent configuration change that had been implemented to improve service performance. The change has been rolled back, and service functionality has been fully restored. This issue has been resolved. Our teams will continue to monitor the environment to ensure ongoing stability. Additional details, including the root cause analysis and preventative measures, will be shared in a post-mortem report.

3. postmortem Jul 02, 2026, 05:49 AM UTC

   **Description:** Flexera One- IT Asset management- APAC - Page loading issues **Timeframe:** June 18, 2026, 05:22 AM PDT to June 18, 2026, 06:09 AM PDT ‌ **Incident Summary** ‌ On Thursday, 18 June 2026, at 05:22 AM PDT, our teams detected an issue affecting customers in the APAC production region. Impacted users were unable to access the Flexera One IT Asset Management \(ITAM\) service, as the ITAM landing page failed to load and key navigation components did not initialise correctly. As a result, customers were unable to access ITAM functionality through the user interface. Upon detection, our technical teams immediately launched an investigation and confirmed that the issue was isolated to the APAC region. Initial assessments indicated that the underlying application infrastructure remained healthy, which focused the investigation on the authentication and service authorisation components supporting the platform. Further analysis determined that a recent configuration change introduced during a service migration resulted in authentication failures between internal platform services. Although pre-migration testing indicated no expected service impact, the configuration behaved unexpectedly under specific conditions, preventing successful service-to-service authentication. As a result, a critical backend service responsible for tenant management became unavailable. This prevented the ITAM application from retrieving the tenant information required to initialise the user interface, causing customers to be unable to access the platform. Once the configuration issue was identified, the change was rolled back to restore normal service communication. Following the rollback, technical teams validated the functionality of all affected services and confirmed that customer access had been fully restored. The environment remained stable throughout the post-restoration monitoring period, and the incident was formally declared resolved. ‌ **Root Cause** ‌ The incident was triggered by a configuration change introduced during a planned service migration. Based on pre-migration testing, no service disruption was anticipated. However, under specific conditions, the configuration prevented successful authentication between internal platform services, resulting in the unavailability of a critical backend service responsible for tenant management. As a consequence, the ITAM application was unable to retrieve the tenant information required to initialise the user interface, preventing customers from accessing the platform. Contributing Factors * The configuration change affected authentication between internal platform services in the APAC environment. * A backend service supporting tenant management was unable to authenticate with its underlying data store because of the configuration change. * Since the ITAM user interface depends on successful initialization of this service, customers experienced missing navigation elements and page load failures. * The issue was isolated to the APAC region, as the configuration change was specific to that environment. ‌ **Remediation Actions** ‌ * Technical teams identified the configuration change responsible for the authentication failures. * The configuration was rolled back, restoring normal communication between platform services. * Service functionality and customer access were validated following the rollback. * Enhanced monitoring was maintained to confirm continued platform stability after restoration. ‌ **Future Preventative Measures** ‌ * Strengthened Configuration Validation - Configuration changes associated with infrastructure migrations will undergo additional validation and production readiness checks before deployment. * Enhanced Monitoring and Alerting - Monitoring capabilities will be expanded to provide earlier detection of authentication and service authorization failures affecting critical platform components. * Improved Change Governance - The change management process for infrastructure migrations will be enhanced with additional validation checkpoints and post-deployment verification to reduce the likelihood of similar configuration-related issues in the future.

Read the full incident report →

Started Jun 12, 2026, 01:38 AM UTC· resolved Jun 12, 2026, 06:24 AM UTC

1. investigating Jun 12, 2026, 01:38 AM UTC

   Incident Description: We are investigating an issue affecting a small subset of customers in the Australia production environment using Snow Atlas. Affected users may be unable to access certain Snow Atlas pages, including the Home page and SAM Core Overview page. Priority: P2 Restoration Activity: Technical teams have engaged and are actively investigating the issue. Current analysis confirms the impact is limited to a small subset of customers in the Australia region. We are closely monitoring the environment and will provide further updates as additional information becomes available.

2. resolved Jun 12, 2026, 06:24 AM UTC

   Our teams identified an issue affecting the database server and performed a restart, which successfully restored service. We will continue to investigate the underlying root cause to determine what led to the issue and identify any necessary preventative measures. Additional details and findings will be shared in a post-mortem report.

3. postmortem Jun 12, 2026, 02:38 PM 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 Jun 04, 2026, 09:17 PM UTC· resolved Jun 08, 2026, 07:47 AM UTC

1. investigating Jun 04, 2026, 09:17 PM UTC

   Incident Description: We are investigating an issue affecting third-party inventory imports in IT Asset Management. As a result, some customers may experience third-party inventory imports timing out, failing, or remaining in progress longer than expected. Priority: P2 Restoration Activity: Technical teams have identified that some third-party inventory uploads are not completing successfully after the import package is created. Teams are applying backend mitigation where available while continuing work to restore the standard upload flow. No customer action is required at this time.

2. investigating Jun 05, 2026, 08:15 AM UTC

   Our teams have developed and deployed a fix to address the issue affecting data uploads in a test environment. Initial validation indicates improved upload success rates, and teams are currently performing comprehensive testing to verify end-to-end processing and data integrity before proceeding with a broader rollout. In parallel, the investigation into intermittent request-processing behavior remains ongoing. Teams are continuing to analyze system performance and stability to ensure the underlying issues are fully addressed . We will continue to monitor progress closely and provide additional updates as more information becomes available.

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

   Our teams have completed additional validation of the fix in the test environment, including larger uploads and multiple import paths. Results continue to be positive, and teams are working through the next steps needed for a controlled production rollout. We are continuing to validate remaining scenarios and review upload-processing behavior to ensure the fix addresses the issue safely before broader deployment. We will provide another update as rollout planning and validation progress.

4. monitoring Jun 05, 2026, 06:21 PM UTC

   Teams have completed the production deployment of the fix and are monitoring upload behavior across impacted regions. Initial production results are positive, and larger third-party inventory uploads are now being received successfully. Teams are continuing to validate downstream processing to confirm imports complete as expected. We will provide another update once additional production validation is complete.

5. monitoring Jun 06, 2026, 08:03 AM UTC

   Post deployment of a corrective fix, initial observations are encouraging and indicate improved processing behavior following the change. Validation efforts are ongoing to confirm that affected workflows are completing successfully from end to end. Teams continue to closely monitor system performance and recovery progress to ensure the issue has been fully addressed. We will provide further updates as additional information becomes available.

6. monitoring Jun 06, 2026, 08:02 PM UTC

   Validation following the corrective fix continues to show positive results. Previously affected third-party inventory import workflows are now completing successfully, and teams continue to monitor processing behavior across impacted regions. We will continue monitoring through the weekend and provide updates as validation progresses.

7. monitoring Jun 07, 2026, 01:15 PM UTC

   Validation of the corrective fix continues to produce positive results. Previously impacted inventory import workflows are processing successfully, and teams are continuing to monitor performance and processing activity across affected regions to confirm sustained recovery. Monitoring activities will continue through the weekend to ensure stability and consistent processing. We will provide further updates as additional validation is completed.

8. resolved Jun 08, 2026, 07:47 AM UTC

   Validation of the corrective fix has been successful, and previously impacted inventory import workflows are now processing normally. Our teams have continued to monitor performance and processing activity across affected regions over the weekend and have observed stable system behavior with no further signs of the issue. As a result, this issue is now considered resolved.

9. postmortem Jun 19, 2026, 06:36 AM UTC

   **Description:** Flexera One - IT Asset Management - All Regions - Third-Party Inventory Import Issues **Timeframe:** June 4, 2026, 1:45 PM PDT to June 08, 2026, 00:47 PDT ‌ **Incident Summary** ‌ On Thursday, June 4, 2026, at 1:45 PM PDT, our teams identified an issue affecting third-party inventory imports in IT Asset Management caused some inventory uploads to time out, fail, or remain in progress longer than expected. The issue impacted the processing of certain third-party inventory sources and resulted in delays to inventory data availability for affected customers. Investigation determined that, following a recent platform change, a subset of third-party inventory imports encountered issues during the transfer of inventory data into IT Asset Management. The issue was initially identified through a combination of customer reports and internal monitoring. Further investigation confirmed that while inventory data was successfully generated and processed through earlier stages of the workflow, certain uploads failed to complete successfully, resulting in import processing delays and failures. Due to the nature of the response received during these failures, the underlying cause was not immediately apparent, which extended the time required for diagnosis. Technical teams performed a detailed analysis of the processing workflow and identified that certain larger inventory uploads were not being handled as expected under specific conditions. A solution was implemented to improve how these larger data transfers are managed. The corrective update was validated in a controlled environment, followed by comprehensive end‑to‑end testing, and then deployed to production. Following deployment, inventory processing returned to expected behaviour by Jun 06, 2026 , 01:03 PDT. Continued monitoring confirmed stable performance, and no further recurrence of the issue was observed. After extended monitoring, the incident was declared as resolved on Jun 08, 2026 at 00:47 PDT. ‌ **Root Cause** ‌ The issue was caused by limitations encountered during the transfer of larger inventory data sets between platform services following the production change. Under specific conditions, larger inventory uploads were not processed successfully, leading to incomplete or delayed processing. When these uploads failed, the receiving service returned a generic client error response rather than an error specifically indicating a file size limitation. As a result, the sending service interpreted the response as a capability or configuration issue rather than an upload failure, preventing the true cause from being immediately identified. Contributing Factors * The response returned during failure scenarios did not clearly indicate the underlying condition. * This response behaviour initially led to misinterpretation of the failure, extending diagnosis time. * Pre release validation included large data scenarios; however, production conditions introduced additional variability not fully represented during testing. * Platform configuration indicated support for larger data handling, which made the practical limitation difficult to anticipate during design and validation. ‌ **Remediation Actions** ‌ * The processing workflow was analysed to identify the point of failure within the inventory transfer process. * Data transfer behaviour between platform components was reviewed and validated. * A revised approach was implemented to transfer larger data sets in smaller segments. The solution was validated through staging and end to end testing to ensure data integrity and processing completion. * The validated fix was deployed to production environments. * Enhanced monitoring was maintained throughout rollout and validation to confirm successful processing and overall stability. ‌ **Future Preventative Measures** ‌ * Improved Data Transfer Handling - Large inventory data transfers configuration has been updated, improving reliability and reducing dependency on single transaction limits. * Enhanced Error Reporting - Improvements will be made to ensure that system responses more clearly reflect the underlying cause of failures, enabling faster and more accurate diagnosis. * Expanded Validation Scenarios - Additional testing scenarios involving larger and more complex data sets will be incorporated to better reflect real world conditions prior to release. * Stronger Integration Validation - Future changes will include deeper validation of interactions between platform components to identify and mitigate potential constraints earlier. * Monitoring and Detection Enhancements - Monitoring and alerting capabilities will be further enhanced to provide earlier visibility into processing delays or failures, helping to reduce time to detection and resolution.

Read the full incident report →

Started Jun 03, 2026, 04:00 PM UTC· resolved Jun 04, 2026, 06:58 PM UTC

1. investigating Jun 03, 2026, 04:00 PM UTC

   Incident Description: We are investigating an issue affecting batch job processing for Flexera One IT Asset Management in the North America region. As a result, customers may experience delays in the completion of scheduled or queued batch processing jobs. Priority: P2 Restoration Activity: Our technical team is actively working to restore expected batch processing levels. Recovery actions are underway to increase processing capacity, reduce the current queue, and improve batch job processing throughput. We will continue to monitor progress and provide updates as recovery work continues.

2. identified Jun 03, 2026, 06:22 PM UTC

   Our technical team is continuing recovery work to restore expected batch processing levels. Additional processing capacity has been added to help reduce the current queue, and the team is continuing to review how queued jobs are being distributed for processing to improve overall throughput. Recovery efforts remain in progress, and we will continue monitoring the environment while work continues.

3. identified Jun 03, 2026, 08:46 PM UTC

   Our technical team is continuing recovery work to restore expected batch processing levels. Cleanup activities have been completed to reduce the current queue, and processing throughput is now improving. The team is continuing to monitor progress while recovery efforts remain in progress.

4. monitoring Jun 04, 2026, 02:52 AM UTC

   Our technical team has added processing capacity to improve batch processing throughput and reduce the remaining backlog. Additional processing capacity remains in place and is helping queued work continue to process. Processing activity has improved, and the backlog is continuing to decrease. The team is keeping the incident in a monitoring state while the remaining queued work clears and will continue tracking throughput and queue levels to confirm full recovery.

5. monitoring Jun 04, 2026, 07:45 AM UTC

   Processing activity continues to improve, and backlog levels are steadily decreasing. Our teams remain in a monitoring phase while the remaining queued work is processed and are continuing to track processing rates and queue volumes to validate sustained recovery. We will provide further updates as more information becomes available.

6. resolved Jun 04, 2026, 06:58 PM UTC

   Our technical team has confirmed that batch processing has recovered and is operating as expected. Earlier delays have been addressed, and queued work is now processing normally. We will keep monitoring the environment to ensure stability, and this incident is now resolved.

7. postmortem Aug 12, 2026, 02:23 AM UTC

   **Description:** Flexera One IT Asset Management \(ITAM\) - North America - Delayed Batch Processing **Timeframe:** June 2, 2026, 10:29 PM PDT - June 4, 2026, 6:29 AM PDT **Incident Summary** On June 2, 2026, following a scheduled production release in the North America production environment, customers using Flexera One IT Asset Management \(ITAM\) experienced delays in batch processing activities. After the release completed, technical teams identified that batch processing workloads were accumulating in processing queues and were not being executed at the expected rate. As the backlog increased, customers experienced delays in processing activities that relied on the ITAM batch processing platform. Technical teams immediately began investigating the issue and observed that processing capacity was not being utilized as expected. Additional batch processing capacity was temporarily introduced, workloads were reviewed and rebalanced, and non-critical processing tasks were reduced to help restore overall processing throughput. These actions resulted in a steady improvement in processing rates and a gradual reduction of the accumulated backlog. Throughout the recovery effort, technical teams closely monitored queue levels and processing activity while maintaining additional capacity to accelerate backlog reduction. Processing throughput continued to improve and queued workloads steadily decreased until normal operating conditions were restored. By June 4, processing backlogs had been cleared, remaining queued work was processing normally, and technical teams confirmed there was no longer any customer-facing impact. Following validation and continued monitoring, the incident was resolved. **Root Cause** Investigation determined that a release pipeline sequencing issue allowed infrastructure deployment activities to begin before a required release step had been completed. As a result, server instances became available earlier than intended during the production release process. This created conditions that led to abnormal batch processing behavior and the accumulation of processing workloads within the batch queues. The resulting backlog significantly reduced overall processing throughput and delayed execution of customer batch processing activities until mitigation measures were implemented and normal processing rates were restored. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Investigation Initiated: Technical teams began investigating after identifying abnormal growth in batch processing queues following the production release. 2. Additional Processing Capacity Added: Additional batch processing instances were deployed to increase processing throughput and accelerate backlog reduction. 3. Workload Rebalancing Performed: Processing workloads were reviewed and rebalanced to improve utilization of available processing resources. 4. Queue Cleanup Activities Executed: Non-critical processing workloads were reduced to allow processing resources to focus on customer-impacting batch activities and improve overall processing throughput. 5. Continuous Monitoring and Validation: Technical teams continuously monitored queue levels, processing throughput, and backlog reduction until normal operating conditions were restored. 6. Release Pipeline Corrected: The release pipeline was updated to ensure required release steps are completed before infrastructure deployment activities can proceed. **Future Preventative Measures** Following the incident, changes were implemented to the release process to prevent the condition that contributed to this issue from occurring during future deployments. 1. Release Process Improvement: The release process was updated to ensure that critical deployment steps are completed in the correct order before server deployment activities begin. This prevents server components from starting earlier than intended and reduces the risk of similar batch processing disruptions during future releases.

Read the full incident report →

Started Jun 03, 2026, 02:49 PM UTC· resolved Jun 03, 2026, 02:49 PM UTC

1. resolved Jun 03, 2026, 02:49 PM UTC

   Incident Description: We experienced a service disruption affecting Snow Atlas access through snowsoftware.io in the West EU region. During this time, customers in the affected region may have been unable to access the service. Priority: P1 Impact Start Time: 6:11 AM PDT Impact End Time: 6:28 AM PDT Impact Duration: 17 minutes Restoration Activity: The service disruption has been resolved, and Snow Atlas access in the West EU region has been restored. We are continuing to monitor the environment to ensure sustained service stability. A formal root cause analysis will be conducted, and a post-mortem report containing the incident summary, root cause, future preventative measures, and other relevant details will be shared in the coming days.

2. postmortem Jun 16, 2026, 08:36 AM UTC

   **Description:** Snow Atlas - West EU - Service Disruption **Timeframe:** June 3, 2026, 06:33 AM PDT to June 3, 2026, 07:28 AM PDT ‌ **Incident Summary** ‌ On Wednesday, June 3, 2026 at 06:33 AM PDT, customers in the West EU production environment experienced a service disruption that prevented access to Snow Atlas through snowsoftware.io. Affected users were unable to log in to the platform and, in some cases, encountered service availability errors during authentication attempts. Upon investigation, our teams determined that a critical identity and authentication service within the West EU environment became unavailable during infrastructure maintenance activities being performed in a separate region. As a result, authentication requests could not be processed successfully, preventing customers from accessing the platform. Once the issue was identified, the affected service was promptly restored, and normal authentication functionality resumed. Following restoration, technical teams conducted validation activities and continued enhanced monitoring to confirm platform stability and verify that customer access had been fully restored. ‌ **Root Cause** The issue was caused by an operational error during planned maintenance activities. While performing maintenance preparations in a separate production region, an action intended for that environment was inadvertently executed against the West EU environment. This resulted in a critical identity and authentication service being unintentionally scaled down, causing authentication failures and preventing customer access to Snow Atlas. ‌ **Contributing Factors** ‌ * A delay in updating the active management session resulted in commands being executed against the unintended environment. * The affected authentication service represented a critical dependency for customer login and platform access. * Existing monitoring and alerting did not provide timely notification to the responsible engineering team when the authentication service became unavailable, extending the time required to identify and remediate the issue. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * The affected authentication service was restored, re-establishing customer access to the platform. * Technical teams validated service functionality and confirmed successful customer authentication following recovery. * Engineering teams reviewed maintenance procedures and execution logs to identify the sequence of events that led to the incident. * Monitoring was maintained following restoration to verify continued platform stability and service availability. ‌ **Future Preventative Measures** * Enhanced Change Controls - Maintenance procedures will be updated to include additional safeguards and verification steps before executing operational actions across production environments. * Strengthened Monitoring and Alerting - Monitoring and alerting coverage for critical authentication services will be enhanced to ensure responsible teams receive immediate notification of service degradation or outages. * Operational Process Improvements - The lessons learned from this incident have been incorporated into our maintenance and change management practices. These improvements will further strengthen operational controls, reduce the likelihood of similar events, and improve our ability to detect and respond to service disruptions.

Read the full incident report →