Flexera System Incident History

1. investigatingOct 29 · 22:24 UTC

   Further investigation has identified prolonged connectivity timeouts while processing requests associated with AWS operations, alongside degraded responsiveness across multiple Spot operations for AWS. Our technical teams are implementing configuration and resource adjustments to improve service stability while continuing to investigate the underlying cause and monitor affected customer operations.

Reported by Flexera System on their status page.

1. resolvedOct 29 · 16:16 UTC

   Investigation identified a database configuration issue that prevented a supporting service from starting successfully, resulting in the Managed Applications page being unavailable in the EU region. Our technical teams rebuilt the affected database configuration and restored the dependent services. The Managed Applications page is now accessible and functioning normally. Other SaaS Manager functionality remained available, and no impact was identified in other regions. The incident is now resolved.

Reported by Flexera System on their status page.

1. resolvedOct 29 · 06:37 UTC

   Incident Description: Our teams previously identified an issue affecting the Flexera One IT Asset Management (ITAM) service in the US region for a subset of customers. During this time, affected customers may have experienced difficulties accessing the platform and related functionality, with the ITAM interface either failing to load or experiencing longer-than-expected loading times. Business Impact: A subset of customers in the affected US region may have experienced ITAM access issues, including pages failing to load or taking longer than expected to become available. Restoration Activity: Our investigation identified an issue with a database server within the affected production cluster. Our technical teams took corrective action to address the database activity contributing to the issue, after which service returned to normal operation. The incident has been confirmed as resolved.

Reported by Flexera System on their status page.

1. resolvedOct 29 · 07:53 UTC

   The billing-related issue affecting the AWS China account has been successfully resolved, and the account has been restored. Normal service has resumed, and the incident is confirmed as resolved.

Reported by Flexera System on their status page.

1. resolvedOct 28 · 10:35 UTC

   The Technopedia content refresh has been completed, and validation has confirmed that the updated content is available across the affected services. Normal content refresh operations have been restored, and the issue is resolved.

Reported by Flexera System on their status page.

1. resolvedOct 22 · 07:38 UTC

   Following the recovery actions previously implemented, our technical teams completed additional validation and monitoring. Users and Computer Details functionality has remained stable with no further issues observed. Normal operation has been confirmed, and this incident is now considered resolved.

Reported by Flexera System on their status page.

1. postmortemOct 21 · 23:40 UTC

   Description: Flexera One - IT Asset Management - APAC - Service Unavailability Following 2026R1.4 Release

   Timeframe: October 15, 2026, 11:34 AM PDT - October 15, 2026, 12:32 PM PDT

   Incident Summary

   On October 15, 2026, customers using Flexera One IT Asset Management in the APAC region experienced a service disruption that prevented access to the application. The disruption occurred following completion of the ITAM 2026R1.4 production release. Although services were initially available and operating normally after the release, the application subsequently became inaccessible.

   Technical teams investigated the disruption and identified failures affecting the initialization of application instances. Further investigation revealed that the production environment retained a dependency on a previous application initialization process while a transition to an updated process was underway. Although the application instances had been successfully initialized during the release, replacement instances were unable to complete the same process due to an outdated configuration.

   The affected replacement instances were unable to complete initialization successfully or pass the required health checks, preventing the application from returning to normal operation.

   Technical teams corrected the production configuration to reference the updated initialization process and performed an instance refresh. Following these changes, the affected instances initialized successfully, and ITAM service availability was restored at approximately 12:32 PM PDT.

   Root Cause

   The incident was caused by a remaining production dependency on a previous application initialization process during the transition to an updated process in the APAC production environment.

   While staging and user acceptance testing environments had already transitioned to the updated process, the APAC production environment retained a configuration that referenced the previous initialization process. During the 2026R1.4 production release, application instances were manually initialized using the updated process, allowing ITAM to initially operate normally despite the remaining production dependency.

   Components supporting the previous process were subsequently scaled down under the understanding that the broader transition had largely been completed. When replacement application instances were launched, the production configuration continued directing them to the previous initialization process. The affected instances were therefore unable to complete initialization successfully or pass their required health checks, resulting in the service disruption.

   The remaining production dependency on the previous initialization process was confirmed as the underlying cause of the incident. Correcting the production configuration to use the updated initialization process removed that dependency and allowed replacement instances to initialize successfully.

   Remediation Actions

   The following actions were taken during the incident response:

   1. Incident Investigation Initiated: Technical teams investigated the application unavailability and identified failures affecting the initialization and health checks of application instances in the APAC production environment.
   2. Configuration Issue Identified: Investigation determined that the production configuration continued referencing the previous application initialization process rather than the updated process.
   3. Production Configuration Corrected: The production configuration was updated to reference the correct application initialization process, removing the dependency on the previous process.
   4. Application Instances Refreshed: Technical teams performed an instance refresh following the configuration correction, allowing replacement instances to initialize successfully.
   5. Service Recovery Validated: Technical teams confirmed that the affected instances were initializing successfully, application health checks were passing, and ITAM services had returned to normal operation.

   Future Preventative Measures

   Following the incident, a retrospective was conducted to review the application initialization process, remaining production dependencies, release-validation procedures, and opportunities to improve incident detection and response.

   The following corrective actions and improvement activities have been completed or are underway:

   1. Production Configuration Correction: The APAC production environment has been updated to use the correct application initialization process, replacing the previous configuration.
   2. Legacy Dependency Validation: A follow-up action has been established to add a validation step before legacy platform components are scaled down or decommissioned, ensuring that production services have fully transitioned and no remaining dependencies exist on the previous platform.
   3. Release and Application Health-Check Review: Existing application health checks, release-validation procedures, and post-release sanity-test coverage are being reviewed against the failure observed during this incident. The review will determine whether any coverage gaps exist and whether additional monitoring, validation, or other improvements are required.
   4. Instance Scaling Investigation: We will continue to investigate what triggered the original application instances to scale following the release and determine whether any additional corrective or preventative action is required.
   5. Customer Communication Improvements: We identified an opportunity for more timely customer communication during this incident. Our established incident escalation and communication practices are designed to ensure proactive customer notification when unplanned service impact is identified. The learning from this incident has been incorporated into our ongoing incident response practices to help ensure these procedures are applied consistently and that timely, proactive updates are provided to customers during service disruptions.

Reported by Flexera System on their status page.

1. resolvedOct 8 · 12:11 UTC

   Following validation and a period of monitoring, the service has remained stable and License functionality is loading successfully across the affected regions. The issue is now considered resolved.

Reported by Flexera System on their status page.

1. resolvedOct 8 · 01:39 UTC

   Further investigation identified a communication issue affecting a backend service supporting Agreements functionality in Snow Atlas Australia. Technical teams implemented recovery actions, including restarting the affected service components, which restored communication and normal operation. Functionality has been validated across multiple customer environments, and Agreements data is now displaying correctly. We have not observed any further issues following recovery and validation activities. The issue is now considered resolved.

Reported by Flexera System on their status page.

1. postmortemOct 20 · 17:50 UTC

   Description: Spot Ocean - Kubernetes - Intermittent Controller Connectivity Issues

   Timeframe: October 7, 2026, 11:20 AM PDT - 12:30 PM PDT

   Incident Summary

   On Wednesday, October 7, 2026, at 11:20 AM PDT, multiple Spot Ocean for Kubernetes environments experienced intermittent controller connectivity alerts. During the incident, the platform temporarily interpreted controller heartbeat information as outdated and suspended scaling operations for affected clusters as a safety measure.

   The affected controllers continued to report heartbeat information during the incident. However, the timestamp used to validate controller connectivity became outdated within a database component, causing active controllers to appear temporarily unresponsive. The behavior was intermittent, and current heartbeat information subsequently became available without manual intervention, allowing normal scaling operations to resume.

   Technical teams reviewed the controller heartbeat processing path, database behavior, service telemetry, and related infrastructure signals to determine why valid heartbeat activity was being interpreted as stale. No additional occurrences were observed after the incident window. Following continued monitoring and validation of service stability, the incident was considered resolved.

   Root Cause

   The incident was caused by an older controller heartbeat timestamp overwriting a more recent valid timestamp within a database component.

   Although the affected controllers continued reporting heartbeats normally, the outdated timestamp made the most recently stored heartbeat appear older than it was. When the platform evaluated this timestamp, it exceeded the configured heartbeat threshold and triggered a safety mechanism that temporarily suspended scaling operations for the affected clusters.

   The specific condition that delayed the older database update has not been conclusively established. However, the database update process did not contain a safeguard to prevent an older heartbeat timestamp from replacing a newer valid timestamp. This allowed delayed heartbeat information to create the appearance that actively reporting controllers were unresponsive.

   Remediation Actions

   The following actions were taken during the incident response:

   1. Customer Reports and Service Behavior Reviewed: Technical teams reviewed reported examples to confirm the behavior, establish the impact window, and determine whether the issue was isolated or affecting multiple environments.
   2. Controller Heartbeat Activity Validated: Controller activity was reviewed to determine whether the affected controllers had stopped reporting. The investigation confirmed that heartbeat information continued to be sent during the incident.
   3. Heartbeat Processing Path Investigated: Technical teams traced how heartbeat information was generated, stored, and evaluated to identify where current heartbeat activity was being interpreted as outdated.
   4. Database and Service Health Assessed: Relevant database performance, service behavior, and infrastructure telemetry were reviewed to evaluate potential processing delays and rule out broader platform instability.
   5. Timestamp Regression Identified: The investigation determined that an older heartbeat timestamp had overwritten a newer valid timestamp, causing the platform to temporarily interpret the heartbeat as stale.
   6. Service Stability Validated: Technical teams continued monitoring following recovery. No additional occurrences were observed, and scaling operations remained stable before the incident was closed.

   Future Preventative Measures

   The following improvements are planned to strengthen heartbeat processing and improve detection of similar conditions:

   1. Heartbeat Timestamp Protection: The database update process will be modified to prevent an older heartbeat timestamp from overwriting a more recent valid timestamp.
   2. Improved Diagnostic Logging: Additional logging will be introduced around heartbeat updates to capture the source of each update, relevant request context, previous and new timestamp values, and the source of the timestamp.
   3. Monitoring and Alerting: New monitoring and alerting will be developed using the additional diagnostic information to identify timestamp regressions and similar heartbeat-processing conditions more quickly.
   4. Database Access Review: Database access patterns associated with heartbeat processing will be reviewed to identify opportunities to reduce processing delays and optimize performance under elevated load.

Reported by Flexera System on their status page.

1. postmortemOct 13 · 04:42 UTC

   Description: Spot by Flexera - Event Notification Processing Errors

   Timeframe: September 29, 2026, 2:06 AM PDT - 4:51 AM PDT

   Incident Summary

   On September 29, 2026, Flexera identified elevated application errors within a notification processing component responsible for handling certain event notification workflows. Automated monitoring detected increased error activity, prompting an investigation to determine whether customer-facing notifications were affected.

   During the investigation, technical teams identified failures occurring within a notification processing path and performed a detailed assessment of the affected events, notification workflows, and potential customer impact. Initial analysis suggested the issue could potentially affect notification processing more broadly, and a Major Incident was declared while the scope and impact were being validated.

   Further impact assessment confirmed that the affected notifications were not intended to be published to customers. Event information continued to be successfully recorded and remained available through the platform throughout the investigation. No customer-facing functionality was disrupted, no event data was lost, and no customer impact was identified as a result of this issue.

   Based on the results of the impact assessment, the incident priority was downgraded and the investigation was concluded after validation confirmed that customer-facing services remained unaffected.

   Root Cause

   Investigation determined that a notification processing workflow encountered an application exception while handling a subset of internally generated events. These events were configured such that they were not intended for customer notification delivery.

   Although the exceptions generated elevated application errors and warranted investigation, subsequent analysis confirmed that the affected notifications were not expected to be distributed to customers. As a result, customer-facing notification delivery, platform functionality, and access to event information were not adversely impacted.

   Remediation Actions

   The following actions were taken during the incident response:

   1. Incident Investigation Initiated: Technical teams investigated elevated application errors detected through automated monitoring and assessed potential customer impact.
   2. Notification Processing Analysis Performed: The affected notification workflow was reviewed to identify the source of the application exceptions and determine the scope of the issue.
   3. Customer Impact Assessment Completed: Technical teams validated the affected notification types, reviewed event publication behavior, and confirmed that the notifications involved were not intended for customer delivery.
   4. System Validation and Monitoring Conducted: Error trends, service behavior, and notification processing were monitored to confirm stable operation and validate that customer-facing services remained unaffected.
   5. Incident Reclassification Completed: Following confirmation that no customer impact existed, the incident priority was downgraded and the incident was formally resolved.

   Future Preventative Measures

   Following this investigation, we identified opportunities to improve the speed and accuracy of impact assessment when operational alerts involve internal processing workflows.

   1. Improved Impact Assessment: Review internal notification classifications and investigation procedures to accelerate determination of whether an issue affects customer-facing functionality during future incidents.
   2. Enhanced Notification Workflow Visibility: Improve operational visibility into customer-facing and non-customer-facing notification processing paths to support faster impact validation and incident response activities.

Reported by Flexera System on their status page.

1. postmortemOct 26 · 12:10 UTC

   Description: Flexera One- IT Visibility- APAC - Reporting dashboards unavailable

   Timeframe: September 28, 2026, 1:38 AM PDT to September 28, 2026, 2:15 AM PDT

   ‌

   Incident Summary

   ‌

   On Monday, 28 September 2026, at 1:38 AM PDT, Flexera identified an issue affecting access to Power BI reporting dashboards for customers in the APAC region. Our technical teams were promptly engaged and the the initial investigation confirmed that the impact was limited to APAC, while the other regions remained responsive.

   Further investigation determined that configuration changes associated with a planned identity and access management migration had affected the connection settings required by the reporting services. During the application of these changes, the reporting services' connection settings were reset to values that did not contain the complete service addresses required for successful communication. Consequently, the affected services failed to start correctly, resulting in the unavailability of Power BI reporting dashboards for APAC customers.

   To restore service, the technical team manually corrected the affected connection settings in the APAC environment. This restored communication between the reporting and authentication services, allowing the affected services to recover. Following restoration, validation confirmed that the Power BI reporting dashboards were accessible and operating normally at approximately 2:15 AM PDT.

   ‌

   Root Cause

   ‌

   The incident was caused by incorrect connection settings applied to the APAC environment during a configuration change associated with the identity and access management migration. The change reset the reporting services' connection addresses to values that did not contain the complete addresses required for successful communication with the authentication services. As a result, the affected reporting services failed to start correctly, making Power BI reporting dashboards unavailable to customers in the APAC region.

   Contributing Factors

   • Configuration inconsistency: The required connection addresses had previously been updated directly in the environment but were not reflected in the deployment configuration. Consequently, the subsequent configuration change reintroduced the incorrect values.

   • Deployment validation gap: The deployment process did not identify the incorrect connection settings before they affected service availability.

   • Change Coordination and Dependency Validation: The migration process did not fully account for the configuration requirements of all dependent services, resulting in endpoint changes being applied without prior validation across the affected service dependencies.

   ‌

   Remediation Actions

   Our teams performed the below actions to restore the services to normalcy:

   • The affected connection settings were corrected to restore communication between the reporting and authentication services.

   • The affected services recovered, and validation confirmed that Power BI reporting dashboards were accessible and operating normally.

   • The configuration was subsequently corrected to ensure the required connection settings are maintained consistently for future deployments.

   ‌

   Future Preventative Measures

   ‌

   The following actions have been identified and are being worked on to reduce the likelihood of recurrence and improve service resilience:

   • Configuration management: Ensure service configuration changes are managed consistently to prevent discrepancies between deployed settings and maintained configurations.

   • Deployment validation: Review planned configuration changes before deployment to verify that required service connection settings remain correct.

   • Configuration consistency: Ensure critical connection settings are maintained in the appropriate configuration sources and do not depend on manual changes to individual environments.

   • Change coordination: Improve coordination for planned migrations and configuration changes, including validation of the requirements and dependencies of affected services.

   • Deployment safeguards: Strengthen pre-deployment checks to identify incorrect configuration settings before they cause service failures.

Reported by Flexera System on their status page.

1. postmortemOct 8 · 11:25 UTC

   Description: Flexera One – IT Asset Management – All Regions – App Portal Errors and API Request Failures

   Timeframe: September 24, 2026, 12:12 PM PDT – September 26, 2026, 4:38 AM PDT

   Incident Summary

   Beginning September 24, 2026, at approximately 12:12 PM PDT, customers using API-based integrations with Flexera One IT Asset Management (ITAM) experienced authentication failures that returned HTTP 401 Unauthorized responses. App Portal users also encountered errors when submitting requests, and integrations such as App Broker and Business Adapter that rely on these APIs were affected. Impact was observed across the North America, Europe, and Asia-Pacific regions.

   Technical teams investigated and confirmed that the failures were not related to customer credentials or customer configuration. Application logs showed that the components required to authenticate these requests were failing to initialize. Further investigation determined that the behavior was introduced by a hotfix deployed as a preventative measure during the response to the earlier ITAM menu loading incident on September 24.

   Technical teams reproduced the behavior in testing, developed a corrective fix, and validated it. During deployment validation, a secondary component-loading issue was identified and addressed through an updated hotfix. Following deployment of the updated hotfix to Production, technical teams verified that API functionality was operating as expected, and service was restored on September 26 at approximately 4:38 AM PDT. The incident then moved to extended monitoring while customer confirmation was obtained, and confirmation was received on September 28.

   Following the restoration of service, isolated intermittent authentication failures were reported and investigated separately from the main incident. Technical teams identified additional connection-handling and environment-specific configuration conditions and deployed further hotfixes, which were validated through September 30. Continued monitoring and customer review through October 1 confirmed that the issue could no longer be reproduced and that no further occurrences had been observed.

   Root Cause

   The incident was caused by a defect in a hotfix that was deployed as a preventative measure during the response to the earlier ITAM menu loading incident on September 24. The hotfix removed a dependency from the application's authentication components and changed how the application reads the configuration it uses to connect to authentication services.

   The required settings were present in the deployed configuration. However, the application attempted to read them using a method that is not supported for configuration loaded at runtime. As a result, the components required for authentication could not be initialized, and requests that required authentication were rejected as unauthorized. This produced the API errors and App Portal request failures that customers experienced.

   The same behavior occurred in the pre-production validation environment when the hotfix was applied there. It was not identified before the hotfix reached Production because the affected APIs are not actively used in that environment, and specific error alerting was not yet in place for them.

   The initial fix addressed the primary configuration defect. During subsequent validation and monitoring, additional component-loading, connection-handling, and environment-specific configuration conditions were identified and required further hotfixes before sustained stability could be confirmed.

   Remediation Actions

   The following actions were taken during the incident response:

   1. Incident Response Initiated: Technical teams began investigating after customers reported authentication failures and API errors.
   2. Scope and Customer Configuration Assessed: Technical teams confirmed that the failures were not related to customer credentials or configuration, and confirmed that impact extended to multiple regions.
   3. Underlying Condition Identified: Technical teams determined that the required authentication settings were present but could not be read at runtime, and reproduced the behavior in testing.
   4. Corrective Fix Developed and Validated: The application code was updated to read the settings using a supported method. Validation testing confirmed that the authentication errors no longer occurred.
   5. Corrective Fix Deployed and Service Restored: A secondary component-loading issue identified during deployment validation was addressed through an updated hotfix. After the updated hotfix was deployed to Production, technical teams verified that API functionality was operating as expected.
   6. Extended Monitoring and Customer Validation: Technical teams monitored service behavior through the weekend and obtained confirmation from an affected customer.
   7. Post-Incident Remediation: After isolated intermittent failures were reported following the restoration of service, technical teams deployed further hotfixes and validated them through September 30. Monitoring and customer review continued through October 1 to confirm that the issue no longer occurred.

   Future Preventative Measures

   Following the incident, we conducted a retrospective to review the technical cause, hotfix validation process, monitoring capabilities, and factors that contributed to the customer impact.

   The following measures have been completed or are being implemented:

   1. Runtime Configuration Correction: The application has been corrected to read its authentication configuration using a supported method, and additional hotfixes have been deployed and validated across production environments.
   2. API Monitoring and Alerting: Error-rate alerting is being added for the affected APIs so that authentication failures are detected in both pre-production and Production environments, even when the service is not actively used.
   3. Hotfix Validation Process: We are evaluating additional checks of dependent services, such as API integrations and App Portal functionality, as part of hotfix validation before changes are approved for Production.

Reported by Flexera System on their status page.

1. postmortemOct 9 · 06:33 UTC

   Description: Spot Ocean for AWS – Instance Provisioning Failures

   Timeframe: September 24, 2026, 12:00 PM PDT to September 24, 2026, 2:54 PM PDT

   ‌

   Incident Summary

   ‌

   On September 24, 2026, Spot Ocean for AWS experienced an issue that prevented some customers from launching new instances. As a result, affected clusters were unable to scale as expected when additional compute capacity was required.

   Existing instances and workloads remained operational throughout the incident. The impact was limited to new instance provisioning and cluster scale-up operations.

   The technical team identified that a recent software change introduced unexpected behavior during the instance provisioning process. The change was rolled back, which cleared the provisioning errors and restored normal service operation.

   Following the rollback, the underlying software issue was identified and corrected. The updated functionality has undergone additional validation to ensure the issue is fully addressed before it is reintroduced into the production environment.

   Technical teams validated successful instance launches following the rollback, and customer validation confirmed that new instance provisioning was functioning as expected. The incident was resolved at 2:54 PM PDT on September 24, 2026.

   ‌

   Root Cause

   ‌

   The incident was caused by a recent software change that introduced unintended behavior during AWS instance provisioning. The change affected how certain cluster configuration information was processed, resulting in provisioning failures for some scale-up operations. While the change was designed to support tagging for specific AWS resources, its behavior also affected other supported cluster configurations. Under certain conditions, the updated tagging logic resulted in duplicate tag information being submitted as part of the instance provisioning request. AWS rejected these requests because the tag information did not meet the expected requirements. As a result, Spot Ocean was unable to successfully complete the provisioning of some new instances.

   This primarily affected new instance launches and cluster scale-up operations. Existing instances had already been successfully provisioned and therefore continued to operate normally throughout the incident.

   The underlying functionality has since been corrected, and additional validation is being performed to ensure the updated behavior works consistently across the supported AWS cluster configurations before it is returned to production.

   ‌

   ‌

   Remediation Actions

   Our teams performed the below actions to restore the services to normalcy:

   • Rolled back the software change, restoring normal instance provisioning.
   • Identified and corrected the underlying issue in the affected functionality.
   • Performed additional validation of the corrected functionality.
   • Introduced additional safeguards to allow the updated functionality to be rolled out in a controlled manner.
   • Validated that new instance provisioning and cluster scaling operations were functioning as expected following the rollback.

   ‌

   Future Preventative Measures

   • Expand automated testing for instance provisioning and cluster scaling scenarios.
   • Increase regression testing across supported AWS cluster configurations.
   • Expand end-to-end testing for scaling workflows.
   • Improve monitoring and alerting for provisioning and scaling failures.
   • Strengthen validation of changes before production deployment.
   • Introduce additional safeguards for controlled rollout of changes that affect provisioning behavior.
   • Increase testing coverage for edge cases and error-handling scenarios.

Reported by Flexera System on their status page.

1. postmortemOct 23 · 17:27 UTC

   Description: Flexera One - IT Asset Management - NAM - Inventory Processing Delays Following Production Release Activity

   Timeframe: September 22, 2026, 7:05 PM PDT - September 25, 2026, 5:30 AM PDT

   Incident Summary

   On September 24, 2026, technical teams began investigating reports of delayed inventory updates affecting a subset of customers using Flexera One IT Asset Management (ITAM) in the North America (NAM) region. Although inventory files were being successfully uploaded and remained available, some customers experienced delays in processing these files, preventing the latest inventory information from being reflected in the application. Beacon status information displayed in ITAM could also have been outdated for affected customers. Inventory processing continued normally for other customers.

   The issue occurred following the ITAM 2026R1.3 production release activity on September 22, 2026. Investigation identified an interruption in the process responsible for transferring uploaded inventory files to the ITAM inventory-processing services. While the affected files remained available in storage, they were not being forwarded for processing. Technical teams also observed elevated application errors during the investigation, although these errors were not conclusively established as the cause of the interruption.

   Technical teams performed a targeted restart of the affected service component, restoring the transfer of inventory files and allowing processing to resume for previously affected customers. Additional diagnostic logging was enabled to support further investigation. However, a significant backlog of inventory files had accumulated during the interruption and required additional time to process.

   Following restoration of processing, technical teams continued monitoring inventory activity and the accumulated backlog. By Friday, September 25, 2026, at approximately 5:30 AM PDT, the incident-related backlog had returned to normal operating levels, confirming recovery of inventory processing.

   Root Cause

   The incident was caused by an interruption in the inventory-processing workflow following the ITAM 2026R1.3 production release activity in the NAM region.

   Although inventory files were successfully uploaded and remained available in storage, the component responsible for forwarding these files to ITAM processing stopped transferring inventory data for a subset of customers. As a result, affected inventory files were not processed, delaying inventory updates.

   The issue did not affect all customers, as inventory processing continued normally for other organizations. Investigation identified elevated application errors and behavior indicating that the affected processing component was not recovering as expected. The precise technical condition responsible for the partial interruption remains under investigation.

   A targeted restart of the affected service component restored inventory processing for impacted customers. The accumulated backlog was subsequently processed, allowing inventory updates to return to normal levels.

   Remediation Actions

   The following actions were taken during the incident response:

   1. Incident Investigation Initiated: Technical teams investigated reports of delayed inventory updates affecting a subset of customers in the NAM region and reviewed the inventory-processing workflow to determine the scope of the issue.
   2. Inventory Processing Interruption Identified: Investigation confirmed that uploaded inventory files were available in storage but were not being forwarded to the processing services for affected customers.
   3. Affected Service Component Restarted: A targeted restart of the affected service component restored the transfer of inventory files and allowed processing to resume for previously affected customers.
   4. Additional Diagnostic Logging Enabled: Additional logging was enabled to capture further technical information and support continued investigation into the underlying processing interruption.
   5. Inventory Backlog Recovery Monitored: Technical teams monitored the accumulated inventory backlog following restoration of processing and confirmed that inventory files were being processed successfully.
   6. Service Recovery Validated: Technical teams confirmed that the incident-related backlog had returned to normal operating levels by September 25 and that inventory processing remained stable.

   Future Preventative Measures

   Following the incident, we conducted a retrospective to review the partial inventory-processing failure, the existing inventory-delivery architecture, available diagnostic information, and opportunities to improve processing reliability and failure visibility.

   The following corrective actions and improvement activities are underway:

   1. Inventory Processing Architecture Improvement: Work is planned to simplify the inventory-processing integration by enabling ITAM to retrieve uploaded inventory files directly from the storage layer rather than relying on the existing intermediate forwarding service. This change will remove an additional dependency from the processing path and provide greater control over processing, backlog management, capacity, and recovery.
   2. Improved Failure Diagnostics: The diagnostic logging and telemetry required to capture the relevant service state during a partial inventory-processing failure will be assessed and enhanced as appropriate. This will provide improved technical information to support root-cause determination if a similar condition recurs.

Reported by Flexera System on their status page.

1. postmortemOct 8 · 11:23 UTC

   Description: Flexera One – IT Asset Management – NAM – Menu Items Not Loading

   Timeframe: September 24, 2026, 5:27 AM PDT – September 24, 2026, 10:48 AM PDT

   Incident Summary

   On September 24, 2026, customers using Flexera One IT Asset Management (ITAM) in the North America region experienced intermittent issues loading application menu items and accessing portions of ITAM functionality. Some customers encountered partially loaded or missing menus, error messages, and inconsistent application behavior.

   Technical teams investigated the issue across the application and supporting services and identified abnormal connection utilization within components supporting ITAM functionality. As available connection capacity became exhausted, some application requests could no longer complete successfully, resulting in authentication-related failures and preventing portions of ITAM functionality from loading.

   Service began recovering at approximately 10:46 AM PDT, before deployment of the corrective hotfix was completed. The last related application errors were recorded at 10:48 AM PDT. Technical teams continued investigating the underlying cause while monitoring the environment and validating customer functionality.

   Post-incident analysis indicated that application services on the affected servers had restarted, releasing accumulated connections and allowing new connections to be established. The corrective hotfix was subsequently deployed as a preventative measure to address the connection-handling behavior while investigation into the underlying cause continued.

   Following continued monitoring and customer validation, technical teams confirmed that ITAM functionality had returned to normal operation.

   Root Cause

   The incident was caused by a connection-management issue introduced during the ITAM 2026 R1.3 production release.

   A change to the application authentication flow caused new service connections to be created repeatedly rather than reusing existing connections. Over time, these connections accumulated and exhausted the available connection capacity within affected application components.

   Once that capacity was exhausted, new application requests could not be established successfully. This resulted in authentication-related failures and prevented portions of ITAM functionality from loading, causing missing menu items, error messages, and intermittent loss of access for affected customers.
   A hotfix correcting this behavior had already been created and was included in the release deployment plan before the Production deployment. The hotfix had initially been designated for the validation environment because Production had not yet been upgraded. It was intended to be applied to Production as part of the R1.3 release, but it was not applied during the Production deployment. As a result, the connection-management correction was not in place when the release went live.

   Remediation Actions

   1. Incident Investigation Initiated: Technical teams investigated the application errors and intermittent loss of ITAM functionality to determine the scope and underlying cause.
   2. Connection Saturation Identified: Analysis of affected application components identified abnormal connection accumulation that was exhausting available connection capacity and preventing new application requests from completing successfully.
   3. Corrective Hotfix Confirmed: Technical teams identified the existing hotfix that corrected the connection-handling behavior by reusing service connections rather than creating new connections for each request.
   4. Corrective Hotfix Deployed: The hotfix was deployed to Production as a preventative measure to address the connection-management issue and prevent further connection accumulation.
   5. Service Recovery Validated: Technical teams continued monitoring application behavior and validating customer functionality after recovery to confirm that ITAM services had returned to normal operation.

   Future Preventative Measures

   Following the incident, we conducted a retrospective to review the technical cause, release and hotfix deployment process, monitoring capabilities, and factors that contributed to the customer impact.
   The following measures have been completed or are being implemented:

   1. Connection Management Correction: The corrective change has been implemented to ensure service connections are appropriately reused and to prevent connection accumulation from exhausting available application resources.
   2. Production Deployment Validation: The connection-management correction has been deployed and validated across all production regions to ensure consistent implementation.
   3. Release and Hotfix Process Improvements: Release procedures are being strengthened so that hotfixes included in release deployment plans are consistently designated for Production deployment, including hotfixes initially created or validated before the Production environment is upgraded.
   4. Hotfix Process Review: We are evaluating improvements to the overall hotfix process to reduce reliance on production hotfixes and further reduce the risk of required corrective changes not being included in future production releases.
   5. Enhanced Application Monitoring: Additional application-level monitoring and alerting are being implemented to improve early detection of intermittent failures and abnormal error conditions before they result in broader customer impact.

Reported by Flexera System on their status page.

1. postmortemOct 23 · 17:25 UTC

   Description: Flexera One - IT Asset Management - NAM - Inventory Processing Delays Following Production Release Activity

   Timeframe: September 22, 2026, 7:05 PM PDT - September 25, 2026, 5:30 AM PDT

   Incident Summary

   On September 24, 2026, technical teams began investigating reports of delayed inventory updates affecting a subset of customers using Flexera One IT Asset Management (ITAM) in the North America (NAM) region. Although inventory files were being successfully uploaded and remained available, some customers experienced delays in processing these files, preventing the latest inventory information from being reflected in the application. Beacon status information displayed in ITAM could also have been outdated for affected customers. Inventory processing continued normally for other customers.

   The issue occurred following the ITAM 2026R1.3 production release activity on September 22, 2026. Investigation identified an interruption in the process responsible for transferring uploaded inventory files to the ITAM inventory-processing services. While the affected files remained available in storage, they were not being forwarded for processing. Technical teams also observed elevated application errors during the investigation, although these errors were not conclusively established as the cause of the interruption.

   Technical teams performed a targeted restart of the affected service component, restoring the transfer of inventory files and allowing processing to resume for previously affected customers. Additional diagnostic logging was enabled to support further investigation. However, a significant backlog of inventory files had accumulated during the interruption and required additional time to process.

   Following restoration of processing, technical teams continued monitoring inventory activity and the accumulated backlog. By Friday, September 25, 2026, at approximately 5:30 AM PDT, the incident-related backlog had returned to normal operating levels, confirming recovery of inventory processing.

   Root Cause

   The incident was caused by an interruption in the inventory-processing workflow following the ITAM 2026R1.3 production release activity in the NAM region.

   Although inventory files were successfully uploaded and remained available in storage, the component responsible for forwarding these files to ITAM processing stopped transferring inventory data for a subset of customers. As a result, affected inventory files were not processed, delaying inventory updates.

   The issue did not affect all customers, as inventory processing continued normally for other organizations. Investigation identified elevated application errors and behavior indicating that the affected processing component was not recovering as expected. The precise technical condition responsible for the partial interruption remains under investigation.

   A targeted restart of the affected service component restored inventory processing for impacted customers. The accumulated backlog was subsequently processed, allowing inventory updates to return to normal levels.

   Remediation Actions

   The following actions were taken during the incident response:

   1. Incident Investigation Initiated: Technical teams investigated reports of delayed inventory updates affecting a subset of customers in the NAM region and reviewed the inventory-processing workflow to determine the scope of the issue.
   2. Inventory Processing Interruption Identified: Investigation confirmed that uploaded inventory files were available in storage but were not being forwarded to the processing services for affected customers.
   3. Affected Service Component Restarted: A targeted restart of the affected service component restored the transfer of inventory files and allowed processing to resume for previously affected customers.
   4. Additional Diagnostic Logging Enabled: Additional logging was enabled to capture further technical information and support continued investigation into the underlying processing interruption.
   5. Inventory Backlog Recovery Monitored: Technical teams monitored the accumulated inventory backlog following restoration of processing and confirmed that inventory files were being processed successfully.
   6. Service Recovery Validated: Technical teams confirmed that the incident-related backlog had returned to normal operating levels by September 25 and that inventory processing remained stable.

   Future Preventative Measures

   Following the incident, we conducted a retrospective to review the partial inventory-processing failure, the existing inventory-delivery architecture, available diagnostic information, and opportunities to improve processing reliability and failure visibility.

   The following corrective actions and improvement activities are underway:

   1. Inventory Processing Architecture Improvement: Work is planned to simplify the inventory-processing integration by enabling ITAM to retrieve uploaded inventory files directly from the storage layer rather than relying on the existing intermediate forwarding service. This change will remove an additional dependency from the processing path and provide greater control over processing, backlog management, capacity, and recovery.
   2. Improved Failure Diagnostics: The diagnostic logging and telemetry required to capture the relevant service state during a partial inventory-processing failure will be assessed and enhanced as appropriate. This will provide improved technical information to support root-cause determination if a similar condition recurs.

Reported by Flexera System on their status page.

1. postmortemOct 26 · 10:40 UTC

   Description: Flexera One - EU - Access unavailable

   Timeframe:

   • September 24, 2026, 2:51 AM PDT to September 24, 2026, 3:18 AM PDT
   • September 25, 2026, 3:50 AM to September 25, 2026, 4:30 AM PDT

   ‌

   Incident Summary

   ‌

   On 24 September 2026 at 2:51 AM PDT, customers experienced login failures when attempting to access the Flexera One EU Production environment. Investigation confirmed degradation of the EU Identity and Access Management services, which prevented customers from accessing the platform.

   The investigation identified a significant increase in database connections associated with elevated traffic from a single organisation. Further analysis determined that repeated downstream requests generated by other services also contributed to the increased load on the authentication and access-control services.

   At 3:18 AM PDT, customer login functionality was restored without direct technical intervention, and the platform returned to normal operation.

   On 25 September 2026 at approximately 3:50 AM PDT, another increase in database connections was observed, associated with elevated traffic from the same organisation. The increased load continued for approximately 40 minutes. In response, autoscaling was enabled for the resource management service to increase capacity and improve platform stability..

   ‌

   Root Cause

   ‌

   The incident was caused by an unexpected increase in traffic that placed excessive demand on the EU authentication services and associated database connections. The increased load affected the services responsible for processing authentication requests, resulting in customer login failures within the EU Production environment.

   Repeated requests from other services to the authentication and access-control services further contributed to the elevated load. In addition, automatic scaling was not enabled for the resource management service, limiting its ability to dynamically increase capacity in response to higher demand.

   Gaps in proactive monitoring and alerting also limited the ability to identify the degradation before customers experienced access failures.

   ‌

   Remediation Actions

   ‌

   Our teams performed the below actions to restore the services to normalcy:

   • The September 24 incident resolved without direct engineering intervention, and customer login functionality was restored at 3:18 AM PDT.
   • On 25 September, autoscaling was enabled for the resource management service to increase capacity in response to elevated demand.
   • The team continued monitoring database connections and service health to assess platform stability.

   ‌

   Future Preventative Measures

   ‌

   The following actions have been identified and are being worked on to reduce the likelihood of recurrence and improve service resilience:

   • Automatic scaling: Review autoscaling configuration for the resource management service across all production regions, to ensure capacity adjusts to changes in workload.
   • Database capacity management: Review database connection pool settings and ensure that service scaling remains within the database's available connection capacity.
   • Proactive monitoring and alerting: Review and introduce alerts for abnormal database connection growth, connection pool saturation, service latency, error rates, and resource utilization.
   • Traffic monitoring: Improve visibility into organization-level traffic patterns to identify unusual request spikes before they affect other customers.
   • Traffic management: Evaluate appropriate rate-limiting and throttling controls to prevent excessive traffic from a single organization from affecting platform-wide availability.
   • Load and capacity testing: Conduct load testing using traffic patterns representative of the incident to validate service performance and database capacity under elevated demand.

Reported by Flexera System on their status page.

1. postmortemSep 30 · 16:02 UTC

   Description: Flexera One – IT Asset Management – North America – Service Unavailability Following 2026R1.3 Maintenance

   Timeframe: September 22, 2026, 9:00 PM PDT – September 23, 2026, 5:47 AM PDT

   Incident Summary

   On September 22, 2026, Flexera conducted the planned 2026R1.3 production release for Flexera One IT Asset Management in the North America region.

   The upgrade progressed successfully across the vast majority of databases within the environment. However, when the scheduled maintenance window concluded at 9:00 PM PDT, a required database migration operation remained in progress. Because the production environment could not be restored until the migration completed, IT Asset Management remained unavailable beyond the scheduled maintenance period.

   The remaining migration required a large database index rebuild involving a significant volume of data. The operation became the critical path for completing the release and took substantially longer than anticipated. After the initial index-processing stage completed, the database still needed to perform additional sorting and index-creation activities. This work continued for several hours and extended the overall duration of the migration.

   During the investigation, technical teams evaluated available recovery options, including whether the affected database could be temporarily separated from the migration path to allow the remainder of the environment to return to service. Due to the stage of the deployment and the additional recovery work this approach would have required, the most reliable recovery path was to allow the database operation to complete before restoring the environment.

   Once the database migration completed, technical teams began restoring application and supporting services. During startup, an additional service-recovery issue was encountered that required manual intervention before restoration could continue. Following remediation, the remaining application and platform services were successfully restored.

   Technical teams then completed validation activities, confirmed customer access, and performed extended monitoring to verify service stability. Customer impact ended on September 23, 2026, at 5:47 AM PDT.

   Root Cause

   The outage was caused by a database index configuration discrepancy that was identified during the 2026R1.3 migration, resulting in a large index rebuild operation that substantially exceeded the planned maintenance window.

   Post-incident investigation determined that an index within the affected database did not match the database structure expected by the current release. The index had previously been recreated using an older definition that did not incorporate a subsequent database design change.

   During the 2026R1.3 deployment, the migration process identified this difference and initiated the database operation required to bring the index into alignment with the current database definition. Because of the exceptionally large size of the dataset involved, the resulting rebuild became a long-running and resource-intensive operation that significantly exceeded the planned maintenance window.

   Once the rebuild was underway, the remaining processing duration could not be reliably predicted, which made it difficult to provide an accurate completion estimate while the operation continued.

   Remediation Actions

   The following actions were taken during the incident response:

   • Index Rebuild Monitored: The index rebuild and remaining database upgrade activities were continuously monitored through completion.
   • Recovery Options Evaluated: Available restoration approaches were assessed to determine the safest and most reliable path for returning the production environment to service.
   • Database Upgrade Completed: The index rebuild and remaining database upgrade activities were completed before application restoration began.
   • Application and Supporting Services Restored: Application and supporting services were restored. Targeted recovery actions were performed when an additional service-startup issue was encountered.
   • Service Recovery Validated: Customer access and application functionality were confirmed, remaining background processing was reviewed, and extended monitoring was completed to verify stable operation.

   Future Preventative Measures

   Flexera recognizes the significance and duration of this outage and the impact it had on customers in the North America region. A full root cause analysis and cross-functional retrospective have been completed, and the following preventative measures have been identified as part of the ongoing improvement effort:

   1. Database Procedure Validation: Technical teams are assessing how database remediation procedures are reviewed and maintained to ensure they remain aligned with current product requirements as the platform evolves.
   2. Pre-Deployment Verification: Release-validation processes are being evaluated to determine how unexpected database configuration differences can be identified and assessed before production maintenance begins.
   3. High-Impact Operation Assessment: Technical teams are assessing how potentially long-running or resource-intensive database operations can be identified during release preparation so their expected duration and operational impact can be better understood before deployment.
   4. Release Readiness and Recovery Planning: Release-readiness and recovery-planning practices are being reviewed to improve visibility into activities that may significantly affect deployment duration and service-restoration timelines.

   Providing reliable and resilient services remains a priority. The findings from the completed root cause analysis and retrospective are being incorporated into technical and operational improvements intended to reduce the likelihood of recurrence and strengthen the planning and execution of future maintenance activities.

Reported by Flexera System on their status page.

1. postmortemOct 13 · 12:49 UTC

   Description: Snow Atlas- APAC - Data Ingestion and Processing delays

   Timeframe: September 21, 2026, 5:48 PM PDT to September 22, 2026, 3:15 AM PDT

   ‌

   Incident Summary

   On Monday, September 21, 2026, at 5:48 PM PDT , an issue affected multiple Snow Atlas tenants in the Australia East (AE) region, resulting in delays in inventory data updates. Affected customers experienced outdated device information on the Computers page, while Snow Extenders displayed a “Running with Errors” status. Errors were also observed during data ingestion.

   Investigation identified an outdated DNS record associated with previously decommissioned infrastructure in the Australia Southeast region. This record interfered with connectivity to the Australia East environment, preventing inventory data from being processed as expected.

   The outdated DNS record was removed, allowing traffic to reach the correct endpoint and enabling inventory scan updates to resume. Following the change, inventory counts began progressing, and the affected connectivity service statuses subsequently returned to normal on September 22, 2026, at 3:15 AM PDT. Following an extended period of overnight monitoring, connectivity services remained stable, and the issue was declared resolved on 23 September at 12:05 AM PDT. No further issues have been reported, and the previously used Australia Southeast infrastructure has been fully decommissioned.

   ‌

   Root Cause

   The incident was caused by an outdated DNS record that remained after the decommissioning of infrastructure in the Australia Southeast region.

   This record directed traffic away from the correct endpoint for the Australia East environment, disrupting connectivity required for inventory data processing. As a result, inventory updates were delayed, and affected customers could not retrieve the latest device information. The outdated record was removed, restoring connectivity to the correct endpoint and allowing inventory processing to resume.

   ‌

   Remediation Actions

   Our teams performed the below actions to restore the services to normalcy:

   • Identified and removed the outdated DNS record associated with the previously decommissioned infrastructure.
   • Restored connectivity to the correct Australia East endpoint.
   • Verified that inventory scan updates and inventory counts were progressing.
   • Monitored the environment to confirm service stability.
   • Confirmed that Snow connectivity service statuses subsequently returned to normal and no further issues were reported.

   ‌

   Future Preventative Measures

   • Review DNS record cleanup during infrastructure decommissioning to ensure obsolete records are removed.
   • Improve post-decommissioning checks to identify records that remain after resource removal.

Reported by Flexera System on their status page.

1. postmortemOct 23 · 17:20 UTC

   Description: Flexera One - IT Asset Management - EU & APAC - Inventory Processing Delays Following a Deployment Configuration Issue

   Timeframe: September 16, 2026, 2:00 PM PDT - September 20, 2026, 9:52 AM PDT

   Incident Summary

   On Friday, September 18, 2026, technical teams began investigating reports of delayed inventory updates affecting Flexera One IT Asset Management (ITAM) customers in the Europe (EU) and Asia-Pacific (APAC) regions. Updated inventory information was not being reflected in the application, with some customers reporting that their latest available inventory data remained dated September 16. The issue affected inventory processing rather than general availability of the ITAM platform.

   Initial analysis indicated that the inventory-processing services appeared healthy, but incoming inventory files were not progressing through the expected processing workflow. Further investigation traced the interruption to a deployment performed on September 16, during which a configuration issue affected the services responsible for processing inventory data.

   Technical teams identified and corrected the deployment configuration, allowing inventory processing to resume. However, a significant backlog of inventory files had accumulated during the interruption and required additional time to process.

   Inventory processing recovered first in APAC, where the accumulated backlog was cleared on September 18 at approximately 12:21 PM PDT. The EU region required additional recovery time due to the volume of outstanding files. Technical teams adjusted processing capacity settings and continued monitoring the backlog as inventory files were processed.

   The remaining EU backlog was fully cleared on September 20 at approximately 9:52 AM PDT. Subsequent monitoring confirmed that inventory processing had returned to normal operating levels.

   Root Cause

   The incident was caused by a deployment configuration issue introduced during a September 16 update to the inventory-processing services.

   At the time of the deployment, the inventory-processing infrastructure was transitioning between application environments, with different services required to remain active in each environment depending on the region. This increased the complexity of maintaining the correct production configuration, and the required service configuration was not correctly maintained during the deployment.

   As a result, the inventory-processing workflow was interrupted in the EU and APAC regions, preventing incoming inventory files from being processed and delaying inventory data updates. Once the configuration was corrected, inventory processing resumed, with the accumulated backlog requiring additional time to process before normal operating levels were fully restored.

   Remediation Actions

   The following actions were taken during the incident response:

   1. Incident Investigation Initiated: Technical teams investigated reports of delayed inventory updates in the EU and APAC regions and reviewed the inventory-processing workflow to identify the source of the interruption.
   2. Deployment Configuration Issue Identified: Investigation traced the interruption to the September 16 deployment and identified an incorrect service configuration affecting inventory processing across the impacted regions.
   3. Production Configuration Corrected: The required configuration updates were applied to restore the affected inventory-processing services, allowing incoming inventory files to resume processing.
   4. Inventory Backlog Recovery Initiated: Technical teams monitored the accumulated inventory files and adjusted available processing resources to support backlog recovery following restoration of the processing workflow.
   5. Processing Throughput Optimized: During EU recovery, technical teams identified processing capacity constraints under the increased workload and adjusted processing concurrency to improve throughput while maintaining service stability.
   6. Service Recovery Validated: Technical teams confirmed that the APAC backlog had cleared on September 18, followed by complete EU backlog recovery on September 20. Continued monitoring verified that inventory processing had returned to normal operating levels.

   Future Preventative Measures

   Following the incident, we conducted a retrospective to review the deployment configuration issue, differences between application environments, inventory-processing monitoring capabilities, and opportunities to improve deployment validation and operational visibility.

   The following corrective actions and improvement activities have been completed or are underway:

   1. Regional Service Configuration Management: A regional service configuration list has been implemented to document and maintain the required service configurations across the different deployment environments, reducing the risk of configuration inconsistencies during future releases.
   2. Deployment Validation Improvements: A deployment checklist has been implemented to verify that the required inventory-processing services are running in the appropriate environments during deployment activities.
   3. Enhanced Inventory Processing Monitoring: Additional monitoring and alerting have been implemented to identify interruptions in inventory processing earlier and enable faster investigation and recovery.
   4. Improved Processing Error Visibility: Monitoring dashboards have been implemented to provide greater visibility into abnormal application response patterns, including processing capacity-related errors. These improvements have already supported earlier detection and recovery during subsequent processing issues.
   5. Production Environment Simplification: Ongoing work to consolidate the deployment model will reduce the operational complexity associated with maintaining different service configurations across environments and regions, helping reduce the risk of similar configuration-related processing interruptions.

Reported by Flexera System on their status page.

1. postmortemSep 30 · 12:30 UTC

   Description: Flexera Community- Service unavailable

   Timeframe: September 16, 2026, 12:50 AM PDT to September 16, 2026, 8:26 AM PDT

   ‌

   Incident Summary

   ‌

   On September 16, 2026, at 12:50 AM PDT , Flexera identified an issue affecting the availability and reliability of the Flexera Community site due to an outage affecting an external service provider supporting the Community platform.

   During the incident, customers may have been unable to access the Flexera Community, raise or manage support cases, or receive responses to existing cases through the Community. Emails sent to support@flexera.com may also have been delayed or not processed during the outage.

   The issue also affected the chatbot functionality within the Spot console, which relies on the impacted services. In addition, the outage affected proactive monitoring capabilities used by Spot Support teams to identify certain customer environment issues that depend on service notifications.

   The service provider subsequently validated a fix and began deploying it across affected instances on a region-by-region basis. As the mitigation was deployed, services progressively returned to normal.

   Following deployment, service telemetry remained healthy across customer-facing environments. Validation confirmed that the Flexera Community and Spot chatbot functionality were operating normally. The underlying provider incident was subsequently declared resolved, and Flexera completed final validation and closed the incident..

   ‌

   Root Cause

   ‌

   The incident was caused by an outage affecting an external service provider's services that support the Flexera Community and related functionality.

   The service disruption affected the availability and reliability of the Community platform and associated integrations, resulting in temporary disruption to customer support case functionality and related Spot capabilities.

   ‌

   Remediation Actions

   ‌

   • Provider remediation: The external service provider validated and deployed a fix across the affected instances.

   • Service validation: Flexera teams monitored the Community, chatbot functionality, and related services as the remediation was deployed.

   • Recovery monitoring: Service health and functionality were monitored to confirm stability following remediation.

   • Incident closure: After the underlying provider issue was resolved and Flexera completed validation, the incident was closed.

   ‌

   Future Preventative Measures

   ‌

   • Enhanced dependency monitoring: Continue monitoring critical external dependencies that support customer-facing services.

   • Customer impact assessment: Continue assessing the impact of external service disruptions across integrated Flexera services, including Community, support case management, and Spot functionality.

   • Post-incident monitoring: Continue monitoring for residual customer impact following restoration of external services.

Reported by Flexera System on their status page.

1. postmortemOct 12 · 12:02 UTC

   Description: Flexera - EU - Policies/Automation Unavailable

   Timeframe: September 15, 2026, 3:50 PM PDT to September 16, 2026, 1:22 AM PDT

   ‌

   Incident Summary

   On September 15, 2026, at 3:50 PM PDT, an infrastructure upgrade supporting Automation in the EU Production environment resulted in a network connectivity disruption affecting Policies and Automation. Customers experienced difficulties viewing policies in the user interface, and policy-related operations failed.

   The investigation identified unexpected behavior from a legacy network component . This disrupted connectivity required by the affected services.The team identified the component involved and brought the required resource online, restoring network connectivity. The underlying issue was resolved on September 15 at 10:13 PM PDT. Following this, the team continued monitoring service recovery and the processing of the backlog accumulated during the disruption.

   Once backlog processing had progressed as expected and service stability was confirmed, the incident was declared fully restored on September 16, 2026, at 1:22 AM PDT.

   The impact was limited to the EU Production environment.

   ‌

   Root Cause

   The incident was caused by unexpected behavior from a legacy network component during the Automation infrastructure upgrade in the EU region. This disrupted network connectivity required by Policies and Automation, resulting in service unavailability and failures in policy-related functionality.

   ‌

   Remediation Actions

   Our teams performed the below actions to restore the services to normalcy:

   • Connectivity restoration: Identified the legacy component involved and brought the required resource online to restore network connectivity.

   • Service recovery: Restored connectivity and resolved the underlying issue affecting Policies and Automation.

   • Backlog processing: Monitored the accumulated backlog as processing recovered following service restoration.

   • Post-restoration validation: Confirmed service stability and verified that backlog processing was progressing as expected before declaring the incident fully restored.

   ‌

   Future Preventative Measures

   • Migration planning: The corresponding US migration was rescheduled with a longer maintenance window to allow additional time for troubleshooting and recovery.

   • Legacy component replacement: The legacy component is being replaced as part of the infrastructure modernization effort. Once the replacement is complete, this specific legacy dependency is expected to be eliminated in all environments.

Reported by Flexera System on their status page.

1. postmortemOct 12 · 10:47 UTC

   Description: Flexera One - NAM - Access Disruption

   Timeframe: September 14, 2026, 2:39 PM PDT to September 14, 2026, 3:42 PM PDT

   Incident Summary

   On Monday, September 14, 2026, at 2:39 PM PDT, our teams identified an issue affecting customer access to Flexera One in the North America production region. Symptoms included prolonged application loading and authentication failures. The investigation confirmed that the impact was limited to NAM.

   The investigation identified a connectivity issue between services responsible for access control and audit-related functionality. Following a planned change, requests were directed to a downstream service environment that could not be reached through the established communication path. This disrupted communication between the dependent services, resulting in repeated service failures and instability that affected customer access.

   The technical teams corrected the affected routing configuration and restored connectivity between the dependent services. Following these changes, service stability recovered, and customer access to Flexera One in NAM was validated. The incident was resolved on September 14, 2026, at 3:42 PM PDT, and the platform returned to normal operation.

   ‌

   Root Cause

   The incident was caused by an incorrect service routing configuration introduced during the migration of audit-related services in the NAM environment. This prevented dependent services from communicating successfully, resulting in service instability and customer access failures.

   Contributing factor:

   The traffic migration to Audit Services in the NAM region proceeded without fully establishing service connectivity and readiness in the target environment. Although the corresponding migration was operating successfully in other production regions, additional validation was required before proceeding with NAM.

   ‌

   Remediation Actions

   Flexera technical teams performed the below actions to restore the services to normalcy:

   • Routing correction: Updated the affected service routing configuration to restore connectivity between the dependent services.
   • Service recovery: Confirmed that the affected services recovered and returned to stable operation.
   • Access validation: Validated successful customer access to Flexera One in the NAM production region.
   • Post-restoration monitoring: Verified service health following remediation to confirm that normal operation had resumed.

   ‌

   Future Preventative Measures

   • Pre-migration validation: Strengthen validation for dependent services to ensure they are reachable and operating correctly in the target region before migrating production traffic.
   • Regional readiness checks: Strengthen region-specific readiness assessments.
   • Migration safeguards: Introduce additional validation checkpoints to identify connectivity and routing issues before they affect customers.
   • Post-migration verification: Perform targeted service connectivity and customer access checks following each regional traffic migration.

Reported by Flexera System on their status page.

1. postmortemOct 15 · 10:36 UTC

   Description: Flexera One – IT Asset Management – EU – Intermittent UI Access Issues

   Timeframe: September 10, 2026, 2:00 AM PDT– September 10, 2026, 6:00 AM PDT

   ‌

   Incident Summary

   On September 10, 2026, a subset of customers using Flexera One IT Asset Management (ITAM) in the EU region experienced intermittent issues accessing ITAM functionality. Symptoms included missing ITAM menu items, blank or pink error screens, and intermittent failures when loading the ITAM user interface. Other Flexera One modules remained accessible, and ITAM functionality continued to work intermittently throughout the incident.

   The issue self-resolved without any targeted remediation. Error volumes decreased significantly, affected customers regained access to ITAM, and engineering teams confirmed that authentication-related error rates had returned to normal levels. Teams continued monitoring the environment to confirm stability. The exact number of affected customers and root cause could not be determined because the available logging did not provide sufficient tenant-level visibility.

   The underlying cause was identified following a similar incident in the North America region on September 24, 2026. Investigation determined that a connection-management issue introduced during the ITAM 2026 R1.3 production release was responsible for the intermittent failures. A corrective hotfix intended to address this behavior had been prepared for the release but was not applied during the Production deployment.

   Following identification of the root cause, the corrective hotfix was deployed to Production and validated across all production regions. Additional improvements to release validation and application monitoring are being implemented to reduce the risk of recurrence.

   ‌

   Root Cause

   The incident was caused by a connection-management issue introduced during the ITAM 2026 R1.3 production release.

   A change to the application authentication flow caused new service connections to be created repeatedly rather than reusing existing connections. Over time, these connections accumulated and exhausted the available connection capacity within affected application components.

   Once that capacity was exhausted, new application requests could not be established successfully. This resulted in authentication-related failures and prevented portions of ITAM functionality from loading, causing missing menu items, error messages, and intermittent loss of access for affected customers.

   A hotfix correcting this behavior had already been created and was included in the release deployment plan before the Production deployment. The hotfix had initially been designated for the validation environment because Production had not yet been upgraded. It was intended to be applied to Production as part of the R1.3 release, but it was not applied during the Production deployment. As a result, the connection-management correction was not in place when the release went live.

   ‌

   Remediation Actions

   • Service Recovery: The issue self-resolved, with error volumes decreasing and affected customers regaining access to ITAM.
   • Recovery Validation: Engineering teams confirmed that authentication-related error rates had returned to normal levels.
   • Continued Monitoring: Teams monitored service health and error trends to confirm that the environment had stabilized.
   • Subsequent Corrective Fix: Following identification of the underlying cause during the September 24, 2026, North America incident, a corrective hotfix was deployed to Production to address the connection-management issue.
   • Cross-Region Validation: The corrective change was validated across all production regions to ensure consistent implementation.

   ‌

   Future Preventative Measures

   Following the incidents, we conducted a retrospective to review the technical cause, release and hotfix deployment process, monitoring capabilities, and factors that contributed to the customer impact.

   The following measures have been completed or are being implemented:

   • Connection Management Correction: The corrective change has been implemented to ensure service connections are appropriately reused and to prevent connection accumulation from exhausting available application resources.
   • Production Deployment Validation: The connection-management correction has been deployed and validated across all production regions to ensure consistent implementation.
   • Release and Hotfix Process Improvements: Release procedures are being strengthened so that hotfixes included in release deployment plans are consistently designated for Production deployment, including hotfixes initially created or validated before the Production environment is upgraded.
   • Hotfix Process Review: We are evaluating improvements to the overall hotfix process to reduce reliance on production hotfixes and further reduce the risk of required corrective changes not being included in future production releases.
   • Enhanced Application Monitoring: Additional application-level monitoring and alerting are being implemented to improve early detection of intermittent failures and abnormal error conditions before they result in broader customer impact.

Reported by Flexera System on their status page.

1. postmortemOct 12 · 14:34 UTC

   Description: Flexera One - IT Asset Management - APAC & EU - Inventory .ZIP File Processing Delays

   Timeframe: September 10, 2026, 12:21 AM PDT to September 16, 2026, 8:24 PM PDT

   ‌

   Incident Summary

   On September 10, 2026, at 12:21 AM PDT, Following the 2026 R1.3 release, an issue was identified affecting the processing of AWS and inventory ZIP files in the EU and APAC production environments. Although the files were uploaded successfully, the system did not initiate the corresponding import tasks. Consequently, affected tasks remained in an “In Progress” state before eventually timing out, preventing inventory data from being imported as expected.

   The investigation identified a defect in the inventory processing logic introduced as part of the release. A source-type exclusion intended to prevent certain data extraction uploads from generating import tasks also excluded valid inventory uploads.

   The technical teams developed and validated a corrective hotfix, which was deployed to the EU and APAC production environments on September 16, 2026. Following deployment, the teams continued monitoring the affected services and confirmed that import tasks were being created and processed normally, with no new errors observed.

   The issue was resolved following the successful deployment and validation of the hotfix. The North America production environment was not affected because it had not yet been upgraded to the 2026 R1.3 release.

   ‌

   Root Cause

   A defect introduced in the 2026 R1.3 release caused valid inventory uploads to be excluded from processing. The change added a exclusion list to prevent data uploads without a valid communication pathway record from creating ITAM batch import tasks. However, the list incorrectly included the valid source type values .

   Consequently, the batch scheduler excluded valid inventory uploads and did not create the corresponding import tasks. Uploaded inventory files were therefore not processed, resulting in prolonged task states, timeouts, and delayed inventory data updates.

   Contributing Factors

   • Overly broad exclusion logic: Fixed source type names were used in the exclusion list, causing legitimate inventory sources to match the exclusion criteria.

   • Regression test coverage: Few import scenarios were not covered sufficiently in regression testing before the 2026 R1.3 release.

   ‌

   Remediation Actions

   Our teams performed the below actions to restore the services to normalcy:

   • Defect correction: Updated the inventory processing logic to remove the exclusion rules that incorrectly prevented valid uploads from being processed.

   • Hotfix validation: Completed testing and validation of the corrective changes before production deployment.

   • Production deployment: Deployed the updated hotfix to the EU and APAC production environments on September 16, 2026.

   • Post-deployment verification: Monitored the affected services and confirmed 7 that import tasks were being created and processed normally.

   • Release integration: Merged the corrective changes into the release and main branches for inclusion in future releases.

   ‌

   Future Preventative Measures

   • Expanded regression testing: Expand regression testing for changes to inventory processing and source-type exclusion logic.

   • Improved exclusion logic: Ensure that rules intended to exclude specific data extraction uploads do not inadvertently affect valid inventory sources.

   • Release validation: Strengthen validation of inventory upload and task creation workflows before production releases.

   • Post-release monitoring: Continue monitoring inventory task creation, processing completion, and timeout patterns to identify similar issues promptly.

   • Future release coverage: Ensure the corrective changes are included in subsequent releases to prevent recurrence.

Reported by Flexera System on their status page.

1. postmortemSep 30 · 05:42 UTC

   Description: Flexera One IT Asset Management – EU & APAC – Reconciliation Failures

   Timeframe: September 8, 2026, 1:01 PM PDT to September 15, 2026, 3:21 PM PDT

   ‌

   Incident Summary

   ‌

   On Tuesday, September 8, 2026, at 1:01 PM PDT, following the ITAM 2026 R1.3 release, our teams identified an issue affecting reconciliation processing in the EU Production environment. Some reconciliation jobs were unable to successfully retrieve processing results within the available processing window, resulting in failed or delayed reconciliation results for affected customers.

   The issue was identified through monitoring and customer reports. Our teams also detected similar errors in APAC region. During the investigation, our technical teams implemented several service-level and infrastructure mitigations to improve the processing path and reduce reconciliation failures.

   The investigation ultimately determined that a change introduced as part of the 2026 R1.3 release altered the timeout behavior for NextGen License Reconcile processing. This caused certain requests to fail earlier when an underlying performance condition occurred, making the issue more visible.

   A corrective hotfix was developed and deployed on September 15, 2026, at 3:21 PM PDT. Following deployment, reconciliation processing was validated and the issue was resolved on September 15, 2026, at 10:28 PM PDT post monitoring to ensure sustained stability.

   ‌

   Root Cause

   ‌

   • A regression was introduced as part of the ITAM 2026 R1.3 release.
   • The release introduced a new timeout mechanism for handling errors returned by NextGen License Reconcile.
   • Previously, the affected error condition could remain in a waiting/retry state for up to approximately eight hours.
   • The updated behavior reduced the timeout for handling the error to approximately three minutes.
   • Under certain conditions, reconciliation requests subsequently exceeded the platform's available processing window and failed before results could be returned successfully.

   Contributing Factors

   • Long-running reconciliation requests: Some reconciliation operations required additional processing time and did not complete within the available timeout window.
   • Changed error-handling behavior: The updated release behavior surfaced failures that could previously remain in a retry state for a significantly longer period.
   • Variable processing behavior: The issue did not affect every reconciliation request consistently; some requests completed successfully while others experienced timeouts.

   ‌

   Remediation Actions

   ‌

   • Hotfix development: Technical teams developed a corrective fix to address the reconciliation failure.
   • Service capacity adjustments: Teams increased capacity for the affected processing service during the investigation to improve processing reliability.
   • Infrastructure changes: A new service cluster was established and the associated service routing was updated as part of the recovery activities.
   • Configuration updates: Service timeout and connection settings were adjusted to improve the reliability of communication between the components involved in reconciliation processing.
   • Post-deployment validation: Teams monitored reconciliation processing following deployment and confirmed successful execution of the affected workflows.

   ‌

   Future Preventative Measures

   ‌

   • Enhanced release testing: Expand testing of reconciliation workflows where processing times may approach configured timeout limits.
   • Timeout and retry validation: Review timeout and retry behavior for future releases that modify reconciliation error handling.
   • Review monitoring: Review and enhance monitoring for reconciliation processing delays, timeout conditions, and result retrieval failures.
   • Problem Management: Complete a full retrospective and track all identified improvement actions to closure under a problem record.

Reported by Flexera System on their status page.