Flexera outage history

Incident Description: We are investigating an issue affecting Snow Atlas SAM Core functionality in the UK South region. Some customers may experience issues accessing Users functionality and may encounter errors when accessing Computer Details. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and assessing the scope of impact. We are working to identify the underlying cause and restore the affected functionality. Further updates will be provided as more information becomes available.

Our technical teams identified timeout errors affecting service components supporting the impacted functionality and performed targeted service restarts. Following these recovery actions, Users and Computer Details functionality is responding successfully during validation. We are continuing to monitor service behavior and perform final validation to confirm sustained stability.

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.

Incident Description: Following the scheduled Flexera One IT Asset Management 2026R1.4 production release in the Australia region, we experienced an issue affecting Flexera One IT Asset Management services in APAC. As a result, customers were unable to access Flexera One IT Asset Management during the impact period. Priority: P1 Impact Start: October 15, 2026 at 11:34 AM PDT Impact End: October 15, 2026 at 12:32 PM PDT Restoration Activity: Our technical teams identified an issue affecting service components following the scheduled production release. Remediation was applied to the affected components to restore service availability. Following recovery, Flexera One IT Asset Management services in APAC returned to normal operation, and the issue is now considered resolved.

**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.

Incident Description: We are investigating an issue affecting the License Service within SAM Core. Users may be unable to load license information and may encounter error messages while accessing License Service functionality. The issue has been confirmed in UK South and West Europe, and technical teams are currently assessing the full scope of impact. Priority: P2 Restoration Activity: Technical teams are actively investigating the issue and reviewing the affected service. Additional validation is underway to determine the full scope of impact and restore normal service operation. Further updates will be provided as more information becomes available.

We have identified the issue as being related to a recent deployment affecting the Licenses service. Corrective changes have been implemented, and service functionality has been restored. We are currently validating service health and monitoring the environment to ensure continued stability. Further updates will be provided as additional validation is completed.

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.

Incident Description: We are investigating an issue affecting the Agreements functionality in Snow Atlas for customers in Australia. Customers may experience missing or unavailable data when accessing the Agreements tab, and data refresh operations may fail. Priority: P2 Restoration Activity: Technical teams are actively investigating the issue and assessing the extent of customer impact. Work is underway to identify the cause of the issue and restore normal functionality. Further updates will be provided as more information becomes available.

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.

Incident Description: We are investigating reports of intermittent issues affecting Ocean Kubernetes customers. Some customers have reported receiving alerts related to connectivity between Ocean Kubernetes components and their clusters. Technical teams are actively investigating the scope of impact and any associated service degradation. Priority: P2 Restoration Activity: Our technical teams are actively investigating the reported behavior, reviewing customer reports, and validating the scope and impact across affected environments. We will provide additional updates as more information becomes available.

We continue to investigate the intermittent connectivity issues previously reported. At this time, no additional occurrences have been observed since the original impact window. Technical teams are actively reviewing available telemetry and investigation findings to determine the underlying cause and validate the overall scope of impact. Further updates will be provided as more information becomes available.

We have not observed any additional occurrences since the originally reported impact window, and service stability has been maintained. Technical teams continue to investigate the underlying cause of the intermittent connectivity issues reported earlier today.

Based on the sustained stability observed since the originally reported impact window and the absence of any additional reported occurrences, we are moving this incident to Monitoring. Technical teams continue to investigate the underlying cause while service stability is being monitored. Further updates will be provided as more information becomes available.

We have not observed any additional occurrences since the original reported impact, and service stability has been maintained. Technical teams completed additional investigation into the intermittent connectivity issues reported earlier today. Multiple potential correlations were reviewed during the investigation, and final analysis is still pending. Based on the sustained stability observed and the absence of any recurrence, this incident is now considered resolved. Technical teams will continue monitoring and investigation activities to further understand the behavior observed during the reported impact window, and a formal RCA report will be provided once the analysis has been completed.

**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.

Incident Description: We are investigating an issue affecting the event notification service across multiple production environments. Customers may experience delays or failures when receiving v2 event notifications, including notifications delivered through email, webhooks, Slack, and other supported channels. Events continue to be recorded and remain accessible through the Flexera One console and API. There is currently no indication that core platform functionality or event data has been impacted. Priority: P3 Restoration Activity: Our technical teams have identified the issue and implemented service recovery actions. Monitoring indicates that error rates are decreasing, and teams are continuing to validate service stability and assess the full scope of the impact. Further updates will be provided as the investigation and recovery efforts progress. Update: Further investigation confirmed that this issue did not impact customers. The affected notifications were not intended to be published.

After closely monitoring the services to confirm stability, our teams observed no further errors or recurrence of the issue. This incident is now resolved.

**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.

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

The issue affecting Power BI reporting dashboards in the APAC region has been resolved. Initial investigation indicates that a configuration update was required following a recent upgrade. Our technical teams completed the necessary remediation, and subsequent validation confirmed that the affected dashboards are now accessible and operating as expected. All services have returned to normal operation, and this incident is now considered resolved.

**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.

Incident Description: We are investigating an issue affecting certain IT Asset Management integration and App Portal services across all regions. Customers using affected API-based integrations may experience authentication failures resulting in HTTP 401 Unauthorized errors, which may prevent requests from completing successfully. App Portal users may also encounter errors when submitting requests. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and evaluating corrective actions. Investigation and validation activities are ongoing, and we are working to restore normal service functionality as quickly as possible. Further updates will be provided as more information becomes available.

The corrected hotfix is currently pending completion of the build process, which is taking longer than expected. Once the build is complete, our technical teams will proceed with UAT validation before moving forward with production deployment. The team is also working to confirm the deployment plan, ownership, and expected timeline. Further updates will be provided as these activities progress.

Our teams have successfully implemented a hotfix, and initial validation confirms that services are operating as expected. We are continuing to closely monitor the environment while awaiting confirmation from affected customers.

The APIs are operating as expected, and the previously observed errors are no longer being detected. The incident remains in monitoring while additional validation is completed and customer confirmation is obtained.

Following remediation activities completed over the weekend, we continued to monitor the affected services to validate sustained stability and recovery. Customer validation has now been received confirming that App Portal functionality and API request processing are operating normally. Further investigation identified an issue affecting authentication processing within a service component, resulting in HTTP 401 Unauthorized errors for affected API requests and errors when submitting requests through App Portal. Our technical teams implemented corrective actions to address the issue and performed additional validation after identifying and resolving a separate issue encountered during the remediation process. Following remediation and extended monitoring, services have remained stable with no further issues observed. A full root cause analysis will be conducted, and a post-incident report will be shared detailing the root cause, remediation activities, and corrective actions identified as part of the investigation.

**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.

Incident Description: We are investigating an issue affecting a subset of Flexera One IT Asset Management customers. Affected customers may experience missing inventory data or empty results when accessing the All Inventory view and related inventory-based views. The issue is limited to a subset of customers in North America. Priority: P2 Restoration Activity: Technical teams are actively investigating the issue and reviewing inventory data processing workflows associated with the affected functionality. The scope of impact is being validated while mitigation and recovery options are assessed. Further updates will be provided as more information becomes available.

Technical teams have identified a likely cause of the issue associated with a recent capability level change affecting inventory data processing. Recovery activities are underway, including rollback and corrective actions designed to restore normal inventory data processing. Technical teams are actively working through the remediation and validating recovery for affected customers. Further updates will be provided as more information becomes available.

Technical teams continue working through remediation activities associated with the issue and are actively executing recovery actions designed to restore normal inventory data processing. During execution, teams encountered additional conditions that required adjustments to the remediation approach, and updated recovery activities are currently in progress. Technical teams remain actively engaged and are working continuously to complete the remediation and restore normal service for affected customers as quickly as possible. We appreciate your patience while these efforts continue and apologize for the ongoing impact. Further updates will be provided as meaningful progress is made.

Technical teams continue working through remediation activities associated with the issue and are actively executing rollback and corrective actions designed to restore normal inventory data processing. Recovery activities remain in progress, and technical teams are actively monitoring execution as remediation proceeds.

Our technical teams successfully completed the required remediation activity. The blocking tasks were cleared. Post-remediation validation confirmed that the relevant database functions and procedures are operating in the expected state. Teams will continue to monitor the environment to ensure stability.

All validation checks have been completed successfully, and services have returned to normal operation. The issue is now resolved.

Incident Description: We are investigating an issue affecting Spot Ocean for AWS. Customers may be unable to launch new instances due to instance provisioning failures. As a result, affected clusters may be unable to scale as expected. Existing workloads remain operational. Our technical teams are actively investigating the scope and impact of the issue. Priority: P2 Restoration Activity: Our technical teams have identified a potential issue related to a recent change affecting instance provisioning and are actively validating the impact. Mitigation activities are underway, including rollback of a recent change while teams monitor recovery and service behavior. Further updates will be provided as more information becomes available.

Further investigation determined that a recent change affecting instance provisioning behavior contributed to the issue. Technical teams completed a rollback of the change and validated recovery. Following the rollback, error levels returned to normal and new instance provisioning resumed successfully. Throughout the incident, existing instances and workloads remained operational. The impact was limited to new instance launches and cluster scale-up operations. The issue is now considered resolved. A detailed post-mortem report will be shared following completion of the root cause analysis and post-incident review, documenting the full sequence of events, contributing factors, lessons learned, and any follow-up actions identified.

**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.

Incident Description: Earlier today, an issue affecting inventory processing in Flexera One IT Asset Management (ITAM) in the NAM region impacted a subset of customers. Investigation identified that inventory uploads were being received successfully but were not being processed for affected customers, resulting in delays to inventory data reflected within Flexera One ITAM. Recovery actions were implemented and inventory processing has since resumed successfully. Inventory files continue to process normally; however, recovery of the remaining backlog is still in progress and is being tracked through this incident. Priority: P2 Restoration Activity: Technical teams implemented recovery actions that restored inventory file processing and have validated successful processing through monitoring and logging. Service operation remains stable, and backlog recovery is continuing as previously queued inventory files are processed. Technical teams are actively monitoring recovery progress, service health, and backlog reduction while ongoing validation activities continue. Previous updates related to the earlier stages of this incident can be found in the incident history linked below. Further updates will be provided as backlog recovery progresses and validation activities continue. https://status.flexera.com/incidents/5wrg6jl9bj2h

Backlog recovery continues as previously queued inventory files are processed. Backlog levels are now within an acceptable range, with one organisation remaining above expected levels. Technical teams continue to monitor recovery, service health, and processing activity while validation remains ongoing.

The backlog accumulated during the incident has been successfully processed, and processing levels have returned to normal operating ranges. Our teams have completed recovery validation, and this incident is now being resolved. Further details regarding the underlying cause and actions taken will be provided in the post-mortem report.

**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.

Incident Description: We are investigating an issue affecting a subset of customers using Flexera One IT Asset Management (ITAM) in the NAM region. Affected customers may experience issues with navigation, including menu items not being visible in the ITAM interface, resulting in limited access to some functionality. Priority: P2 Restoration Activity: Our technical teams are actively investigating this issue and working to restore full functionality. We will continue to provide updates as more information becomes available.

Technical teams continue to investigate the issue affecting Flexera One IT Asset Management in the NAM Production environment. Current efforts are focused on identifying where the failures are occurring within the affected workflow. Teams are reviewing application behavior, validation processes, service interactions, platform telemetry, and any recent changes or environmental conditions that may be contributing to the issue. The investigation remains ongoing, and further updates will be provided as additional information becomes available.

Technical teams have made progress narrowing the scope of the issue and are focusing on the application components involved in loading user access and navigation information. Current findings indicate that some requests within this process are not completing as expected, resulting in menu items failing to load for affected users. Work remains ongoing to determine the underlying cause and validate the appropriate remediation. Additional updates will be provided as more information becomes available.

Technical teams are currently observing stable service behavior and a significant reduction in the errors associated with this incident. Affected application functions are operating normally based on current telemetry and monitoring data. While service stability has improved, technical teams continue to monitor the environment closely to confirm that the issue does not recur. Investigation into the underlying cause remains ongoing. We will continue monitoring and provide further updates as additional information becomes available.

Technical teams have confirmed that service has remained stable and affected IT Asset Management functionality is operating normally. During the investigation, technical teams identified connection saturation conditions affecting application components responsible for user access and navigation functions. These conditions were observed during the impact window and coincided with the failures experienced by affected users. Service functionality recovered, and customer validation confirmed that affected ITAM pages and menu items were loading successfully. Following a period of monitoring with no recurrence of the issue, the incident is now considered resolved. A detailed review of the incident is ongoing to further validate contributing factors and identify any additional preventative actions.

**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.

Incident Description: We identified an issue affecting inventory processing in Flexera One IT Asset Management (ITAM) in the NAM region, impacting a subset of customers. As a result, some inventory uploads are not being processed successfully, causing inventory data displayed in Flexera One ITAM to be delayed and not reflect the most recently uploaded inventory. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue to identify the underlying cause and implement a fix. We are continuing to monitor the situation closely and will provide further updates as the investigation progresses.

Further investigation indicates that the issue appears to be associated with the service responsible for transferring inventory data to ITAM. Our technical teams are continuing to investigate the issue and are working to identify the underlying cause and determine the appropriate remediation. We will continue to provide further updates as more information becomes available.

Our team performed targeted pod restarts, following which inventory file processing resumed successfully for all affected customers. Successful processing has been validated through logs and monitoring graphs. We will continue to closely monitor the services to ensure continued stability and provide further updates as additional information becomes available.

Our technical teams continue to observe successful inventory file processing and stable service operation following the recovery actions. Validation through monitoring confirms that affected inventory files are processing successfully. Backlog recovery is currently in progress, with inventory processing queues continuing to decrease as files are processed. Technical teams are actively monitoring recovery progress and overall service health while the remaining backlog is cleared. We will continue to provide updates as recovery progresses.

This incident was inadvertently marked as resolved with an update intended for a separate incident. Inventory processing recovery remains under monitoring as the remaining backlog continues to clear. Technical teams continue to observe successful file processing and stable service operation. Ongoing recovery updates and backlog monitoring will continue under the newly created incident: https://status.flexera.com/incidents/vztp63wmxjjb We will provide further updates as backlog recovery progresses and recovery validation continues.

**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.

Incident Description: We are currently investigating an issue affecting access to our services in the EU environment. Customers in the EU may experience issues accessing the service. Priority: P1 Restoration Activity: Our technical teams are actively investigating the issue as a priority and working to restore normal service as quickly as possible.

The services have been restored, and access is now functioning as expected. Our teams are closely monitoring the platform to ensure continued stability.

Our teams have continued to monitor the platform and have observed no recurrence of the issue. This incident is now resolved. We will continue our investigation to determine the underlying root cause and identify appropriate corrective actions. Further details will be provided in the post-mortem report.

**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.

Incident Description: We are currently investigating an issue affecting the Flexera One IT Asset Management (ITAM) North America Production environment, which remains unavailable due to scheduled maintenance extending beyond the planned maintenance window. The maintenance activity is still in progress while a database rebuild completes. Priority: P1 Restoration Activity: Our technical teams are actively working to complete the remaining maintenance activity and restore service as quickly as possible. The ETA for the database rebuild is approximately 2 Hours. Our teams are closely monitoring the progress and will provide further details as they become available.

Our technical teams have completed a major phase of the ongoing maintenance activity and are continuing with the remaining processing required to complete the upgrade. The process is taking longer than originally estimated. The environment remains unavailable while these activities are in progress. Teams are actively monitoring the remaining processing and evaluating options to restore service as quickly and safely as possible. Further updates will be provided as the upgrade progresses and the restoration timeline becomes clearer.

The upgrade has been completed successfully. Our teams are now working to restore the services and perform post-deployment validation.

The upgrade has been completed successfully, and the site is now back online. Our team is performing final validation checks to confirm service stability before declaring the incident resolved.

Service has been restored and is operating normally. Following recovery, technical teams completed extended monitoring and validation activities and have confirmed stable operation. The incident is now considered resolved.

**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.

Incident Description: We are currently investigating an issue affecting a subset of our customers using Snow Atlas in the Australia region. The affected customers may experience delays in seeing the latest computer information and data ingestion may also be impacted. Priority: P2 Restoration Activity: An earlier DNS-related issue was identified and has been resolved. However, additional errors are now being observed. Our technical teams are actively investigating these errors to determine the underlying cause and restore normal processing. We will continue to assess the impact and provide further updates as additional information becomes available.

Our teams have performed targeted service restarts, which have improved the processing delays. Monitoring indicates that inventory data is now being updated successfully. The remaining errors are still under investigation, and our teams are working to identify the underlying cause and implement a permanent fix.

The remediation actions have resolved the processing delays and stale data issues. Some residual issues remain and are currently under investigation by our technical teams. The teams are monitoring the services and will continue collecting and reviewing logs over the next 24 hours to support the investigation. We will continue to monitor the services closely and provide further updates as more information becomes available.

Our teams continued to monitor the services overnight and confirmed that no new issues have been observed. Additional spot checks were also completed successfully. This incident is now being resolved. Further information regarding the root cause and actions taken will be provided in the post-mortem report.

**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.

Incident Description: We are investigating an issue affecting inventory data processing in the EU and APAC production environments. Customers may observe delays in inventory updates, resulting in inventory data not reflecting the most recent import activity. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue, validating the scope of impact, and working with relevant dependencies to restore normal inventory processing. Further updates will be provided as more information becomes available.

Our technical teams have traced the issue to a recent deployment and have implemented remediation actions. Initial validation indicates inventory processing has resumed, and technical teams are actively monitoring processing activity and backlog recovery. We are continuing to validate recovery across the affected environments and will provide further updates as more information becomes available.

Technical teams have completed the required configuration updates, and inventory data continues to be processed successfully. Additional processing capacity has been allocated to accelerate backlog recovery, and technical teams are actively monitoring throughput and backlog reduction across the affected environments. Recovery activities remain in progress, and further updates will be provided as backlog processing continues.

Inventory data processing continues to recover, and technical teams are observing a downward trend in backlog volume. Additional processing capacity remains in place, and recovery progress is being closely monitored across the affected environments. We will continue to monitor backlog reduction and provide further updates as recovery progresses.

Inventory data processing continues following the previously implemented remediation. Technical teams are actively monitoring processing throughput and backlog recovery across the affected environments. Technical teams are continuing to assess recovery progress and any additional actions that may help accelerate backlog processing. Further updates will be provided as recovery progresses.

Backlog recovery has completed in APAC following the previously implemented remediation, and inventory data processing has returned to expected levels in the region. Recovery activities continue in EU, where technical teams are monitoring processing throughput and backlog reduction. Additional recovery measures are being evaluated to support backlog processing as recovery progresses.

Recovery efforts continue in EU, and technical teams are observing ongoing reduction of the remaining backlog. Additional recovery optimizations have been implemented to support backlog processing in EU, and technical teams continue to monitor throughput and overall recovery progress. Further updates will be provided as progress continues.

Recovery continues to progress, with the remaining backlog steadily decreasing. Additional optimisations implemented in the EU environment are supporting backlog processing effectively. Our teams continue to closely monitor recovery progress and will provide further updates as appropriate.

Recovery efforts continue in EU, and technical teams are observing continued reduction of the backlog following the previously implemented optimizations. Based on current recovery trends, backlog levels have been significantly reduced and continue to move in the expected direction. Further updates will be provided as progress continues.

Technical teams have confirmed that inventory data processing in EU has returned to normal operation following the previously implemented remediation. The issue was traced to a deployment configuration issue affecting inventory data processing. The required configuration updates were applied, restoring normal processing. Following validation and extended monitoring, backlog recovery in EU has completed and inventory processing remains stable across both EU and APAC. This incident is now considered resolved.

**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.

Incident Description: We are currently experiencing an issue affecting the Flexera Community site. Due to an ongoing outage impacting a third-party service provider, customers may be unable to access the Flexera Community portal or may experience intermittent and unreliable behaviour. Additionally, customers may be unable to create, update, or interact with support cases through the Community site. Emails sent to [email protected] during this period may not be received or processed until the underlying outage has been resolved. This third party service provider outage also impacts the proactive monitoring ability for Spot support teams to detect any customer environment issues along with a chatbot widget inside the Spot console as well. Priority: P3 Restoration Activity: Our technical teams are actively monitoring the situation and working with the third-party provider to track restoration efforts. We will continue to assess customer impact and provide further updates as additional information becomes available.

The service provider has successfully validated the fix in a test environment and has begun deploying it across all affected instances. The rollout is progressing on a region-by-region basis, and services are returning to normal in regions where deployment has been completed.

Our service provider reports that service telemetry has remained healthy following deployment of the mitigation. Community remains accessible at this time, and no confirmed ongoing impact has been identified. We will continue monitoring the environment to ensure ongoing stability while final validation activities are completed. We will provide a further update as additional information becomes available.

Our service provider has declared the underlying incident resolved following successful mitigation and extended validation. Community remains accessible, and no confirmed ongoing impact has been identified. Monitoring throughout the recovery period has not identified any additional issues. This incident is now considered resolved.

Our teams have continued to monitor the service throughout the recovery period, and no additional issues have been observed. Based on the sustained stability of the service, this incident is now considered resolved.

**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 [email protected] 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.

Incident Description: We are currently investigating an issue affecting the Policies and Automation services in the EU Production environment. Customers in the EU may experience failures when using Policies and may be unable to view their policies through the user interface. The impact is limited to the EU region. Priority: P2 Restoration Activity: Our technical teams have been engaged and are actively investigating an issue encountered during an infrastructure upgrade to identify the underlying cause and restore normal service as quickly as possible. Further updates will be provided as the investigation progresses.

The issue affecting the EU environment has been resolved, and access to the user interface has been fully restored. While the service is now operating normally, it may take some time for the backlog of queued work that accumulated during the outage to be processed. Our teams are actively monitoring the recovery to ensure the backlog is cleared and services continue to perform as expected. We will continue to monitor the environment closely and confirm once processing has fully returned to normal levels.

Our teams have continued to monitor the service closely, and no new issues have been observed. The backlog of queued work that accumulated during the disruption is processing successfully and continuing to decrease as expected. Based on the stability observed since recovery, this incident is now resolved. We will continue to monitor processing to ensure the remaining backlog clears completely and the service continues to operate as expected.

**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.

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

Our investigation identified a connectivity issue within a service dependency path that affected customer access in the North America environment. Our technical teams updated the routing configuration, successfully restoring connectivity between the affected services. Service has been fully restored and is operating normally. The issue is resolved.

**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.