Flexera System Incident History

1. postmortemSep 4 · 18:33 UTC

   **Description:** Flexera One - IT Asset Management - North America - Inventory Processing Delays **Timeframe:** August 24, 2026, at 5:33 AM PDT to August 27, 2026, at 9:30 AM PDT **Incident Summary** On Monday, August 24, 2026, at 5:33 AM PDT, reports surfaced of delayed inventory processing affecting some Flexera One IT Asset Management customers in the North America region. Customer inventory files continued to be uploaded, but some files were not progressing through downstream processing as expected. This resulted in growing processing backlogs and delayed availability of updated inventory data for affected customers. The issue affected inventory processing rather than access to the IT Asset Management platform Investigation identified that the issue followed a platform upgrade in the North America environment. During the upgrade activity, inventory upload requests experienced an elevated number of service unavailable responses, connection resets, and other connection-related failures. These conditions caused a cascade of failures within an inventory processing component. Although most inventory processing streams recovered automatically after the affected service components restarted, some streams remained stalled with inventory files queued for processing. Technical teams restarted the affected service components, which restored processing for the impacted workflows, although the accumulated inventory backlog initially cleared more slowly than expected. Processing capacity was increased, and workload, concurrency, and throughput settings were adjusted to improve processing performance. Service health checks were also updated as part of the stabilization activity. These actions increased processing throughput and enabled the accumulated backlogs to be worked through. On Thursday, August 27, 2026, at 9:30 AM PDT, the incident was considered resolved after the implemented measures restored stable inventory processing and the remaining production backlogs continued to decrease. Technical teams continued monitoring processing performance and backlog recovery following resolution. Subsequent validation confirmed that production inventory backlogs had cleared, with only isolated non-production testing backlogs remaining. **Root Cause** **Primary Root Cause:** Following a platform upgrade in the North America environment, inventory processing workflows experienced elevated service unavailable responses, connection interruptions, and related processing failures. While most processing activity recovered automatically, a subset of inventory processing workflows did not fully recover, resulting in inventory files remaining queued and unprocessed. This led to inventory processing backlogs and delayed inventory updates for affected customers. **Contributing Factors:** • Some inventory processing workflows remained stalled following the initial service disruption, preventing queued inventory data from being processed and contributing to backlog growth. • Existing monitoring capabilities did not provide visibility into this specific processing condition, resulting in abnormal backlog growth being identified through investigation rather than automated alerting. **Remediation Actions** The following actions were taken during the incident response: 1. **Incident Investigation Initiated:** Technical teams investigated reports of delayed inventory processing, reviewed processing behavior, and validated the scope of impact affecting inventory processing workflows in the North America environment. 2. **Service Recovery Actions Performed:** Affected service components were restarted to restore inventory processing activity and recover impacted processing workflows. 3. **Processing Capacity Increased:** Additional processing capacity was introduced to improve throughput, reduce processing backlogs, and support backlog recovery across affected inventory processing workflows. 4. **Processing Optimizations Applied:** Technical teams adjusted throughput, workload, and concurrency settings to improve inventory processing performance and accelerate backlog reduction. 5. **Stability and Recovery Validation Performed:** Processing throughput, backlog reduction, service health, and application stability were continuously monitored to verify successful recovery and confirm that inventory processing had returned to normal operating levels. **Future Preventative Measures** Following this incident, technical teams continue to assess the conditions that contributed to the inventory processing disruption and are implementing improvements to strengthen inventory processing reliability, detection, and recovery capabilities. 1. **Validation and Monitoring Following Platform Changes:** Technical teams are reviewing validation and monitoring activities associated with platform changes to improve the early identification of unexpected inventory processing behavior following maintenance and upgrade activities. 2. **Enhanced Inventory Processing Monitoring and Alerting:** Additional monitoring and alerting will be implemented to provide earlier visibility into abnormal inventory backlog growth and inventory processing disruptions. 3. **Inventory Processing Recovery Improvements:** Improvements will be implemented to strengthen inventory processing recovery behavior and reduce the likelihood of processing workflows remaining stalled following unexpected service interruptions.

Reported by Flexera System on their status page.

1. postmortemSep 2 · 20:41 UTC

   **Description:** Spot Ocean - Resource State Discrepancies and Under-Capacity Alerts **Timeframe:** August 25, 2026, 6:15 PM PDT – August 25, 2026, 10:22 PM PDT **Incident Summary** On Tuesday, August 25, 2026, at 6:15 PM PDT, Ocean customers began experiencing service degradation affecting resource state visibility and management operations. During the incident, customers may have observed instances remaining in a Resuming state longer than expected, under-capacity alerts, and discrepancies between resource status information displayed in Spot and AWS. In some cases, resource state information displayed within Spot did not accurately reflect the actual state of resources in AWS. Technical teams investigated the issue and identified degradation within a central Ocean service responsible for processing resource monitoring and management requests. As a result, monitoring and management operations slowed or stopped, resulting in broader service degradation across Ocean. The affected service was restarted, restoring normal request processing and service functionality. Following validation and monitoring activities, service stability was confirmed and the incident was resolved. **Root Cause** Investigation determined that a service responsible for processing resource monitoring and management requests experienced prolonged delays while communicating with a dependent service. As those delays accumulated, the service became unable to effectively process new requests. Although the service continued appearing operational, it was no longer able to process requests normally. This resulted in delayed resource state updates and contributed to the customer-facing symptoms observed during the incident, including resource state discrepancies, under-capacity alerts, and instances remaining in a Resuming state longer than expected. **Remediation Actions** The following actions were taken during the incident response: 1. **Incident Investigation Initiated:** Technical teams responded to production alerts and customer reports to assess the scope and impact of the issue. 2. **Service Degradation Identified: I**nvestigation determined that the affected service was no longer able to effectively process new monitoring and resource management requests. 3. **Service Recovery Performed:** The affected service components were restarted, restoring normal request processing and service functionality. 4. **Post-Recovery Validation Completed:** Technical teams monitored service behavior and validated stability before declaring the incident resolved. **Future Preventative Measures** Technical teams have initiated follow-up work to reduce the likelihood of similar issues occurring in the future. 1. **Monitor Service Reliability Improvements:** Technical teams have identified an existing service behavior that contributed to this incident and are implementing improvements to enhance overall service reliability. 2. **Service Design and Configuration Review:** Technical teams are reviewing the service design, configuration, and request processing behavior involved in this incident to identify additional opportunities to improve resiliency. 3. **Additional Investigation and Corrective Actions:** Technical teams are continuing to assess the findings identified during the investigation and will implement any additional corrective actions determined to be relevant to this incident.

Reported by Flexera System on their status page.

1. postmortemAug 31 · 11:34 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.

Reported by Flexera System on their status page.

1. postmortemAug 27 · 05:58 UTC

   **Description:** Flexera One IT Asset Management – EU – Reconciliation Failures **Timeframe:** August 12, 2026, 5:50 PM PDT to August 12, 2026, 8:29 PM PDT ‌ **Incident Summary** ‌ On Wednesday, August 12, 2026, at 5:50 PM PDT , Flexera identified an issue affecting reconciliation process within the Flexera One IT Asset Management \(ITAM\) EU Production environment. During the impact period, Some reconciliation jobs experienced failures when they were assigned to a specific processing instance that had not completed its required configuration. Initial investigation determined that the issue was isolated to a single server that did not complete its configuration successfully. As a result, the affected server was unable to establish communication with a required dependent service. Reconciliation jobs processed by this server failed, while jobs routed to other correctly configured processing servers continued to complete successfully. Technical teams investigated the issue, identified the configuration discrepancy, completed the required connectivity configuration, and validated successful communication with the dependent service at 8:29 PM PDT. Following remediation, reconciliation processing resumed normally, affected workloads were reprocessed, and continued monitoring confirmed service stability. After monitoring the services to ensure stability , the issue was declared as restored at 10:56 PM PDT. ‌ **Root Cause** ‌ A batch processing server entered service with an incomplete configuration due to an initialization process that did not fully complete. As part of the required deployment sequence, network connectivity configuration must be established before the IT Asset Management processing components become available to process workloads. Because the required connectivity configuration was not completed on the affected server, it was unable to communicate with a dependent reconciliation service. When reconciliation jobs were assigned to this server, processing failed, resulting in reconciliation failures for workloads routed through the misconfigured instance. Contributing Factors * The issue was isolated to a single batch processing server that did not complete its full initialization and configuration sequence successfully. * The server became available to process workloads before all required connectivity configuration steps had been fully validated. * Required service connectivity configuration was not fully established prior to the server entering normal processing operations. * Impact was limited to reconciliation jobs routed through the affected server, while jobs processed by correctly configured servers continued to complete successfully. * Existing deployment validation controls did not detect the incomplete configuration state before the server began processing customer workloads. ‌ **Remediation Actions** ‌ * Initialization Process Rerun: The failed initialization process was rerun successfully on the affected batch processing instance. * Configuration Completion: All required post-installation configuration steps were completed, restoring the instance to the expected configuration. * Connectivity Restoration: Connectivity between the IT Asset Management processing environment and the reconcile service was restored and validated. * Service Validation: Teams confirmed that reconciliation failures had stopped occurring and continued monitoring the environment to verify stable operation. ‌ **Future Preventative Measures** ‌ * Deployment Sequence Improvements - Update deployment procedures to ensure processing services remain unavailable until all initialization and configuration activities have completed successfully. * Post-Deployment Validation Enhancements - Implement additional validation checks to verify that all required configuration steps have completed before services enter production operation. * Deployment Control Review - Review and strengthen deployment controls to ensure service startup sequencing and configuration requirements are consistently enforced across future releases.

Reported by Flexera System on their status page.

1. postmortemAug 21 · 09:13 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.

Reported by Flexera System on their status page.

1. postmortemAug 21 · 09:03 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.

Reported by Flexera System on their status page.

1. postmortemAug 18 · 12:41 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.

Reported by Flexera System on their status page.

1. postmortemAug 14 · 20:02 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.

Reported by Flexera System on their status page.

1. postmortemAug 12 · 17:33 UTC

   **Description:** Flexera One - APAC - Intermittent Service Disruption ## Timeframe **Timeframe:** July 28, 2026, 3:16 PM PDT - July 28, 2026, 5:39 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. **Platform Configuration Alignment:** Platform connectivity configurations were updated to ensure application services can communicate with shared platform components using the required connection ports. Maintaining alignment between service connectivity requirements and platform configurations helps reduce the risk of similar connectivity issues following future infrastructure changes.

Reported by Flexera System on their status page.

1. postmortemAug 12 · 05:15 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. 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. 2. Deployment Process Reinforcement: The incident highlighted the importance of ensuring new authentication-related features are applied only to their intended environments. The deployment approach and expected application process for these changes have been reinforced with the technical team to reduce the risk of similar configuration issues in the future.

Reported by Flexera System on their status page.

1. postmortemAug 12 · 02:23 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.

Reported by Flexera System on their status page.

1. postmortemAug 11 · 10:28 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.

Reported by Flexera System on their status page.

1. postmortemAug 11 · 01:06 UTC

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

Reported by Flexera System on their status page.

1. postmortemJun 10 · 06:25 UTC

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

Reported by Flexera System on their status page.