Flexera Outage History

Started Nov 06, 2026, 11:11 PM UTC· resolved Nov 07, 2026, 01:45 AM UTC

1. investigating Nov 06, 2026, 11:11 PM UTC

   Incident Description: We are investigating an issue affecting Spot services in the AWS us-west-2 region. Business Impact: Customers may experience failures or degraded functionality, including when launching instances, scaling resources, and performing delete operations in the affected region. Restoration Activity: Our technical teams are actively investigating elevated error rates affecting Spot operations in the AWS us-west-2 region and assessing the scope of impact. We are monitoring service behavior and will provide further updates as more information becomes available.

2. monitoring Nov 07, 2026, 12:56 AM UTC

   Service functionality in the affected region is recovering. Our technical teams have successfully validated instance launches and Elastigroup creation, and the previously elevated error rate has significantly decreased. No new errors have been observed during the latest monitoring period. We are continuing to monitor service stability before confirming full resolution.

3. resolved Nov 07, 2026, 01:45 AM UTC

   AWS has confirmed resolution of the issue affecting services in the us-west-2 region. Our technical teams have successfully validated instance launches and Elastigroup creation, and the previously elevated error rates have returned to normal levels. Following continued monitoring and validation, Spot services in the affected region remain stable. This incident is now considered resolved.

Read the full incident report →

Started Nov 04, 2026, 12:59 PM UTC· resolved Nov 07, 2026, 12:38 AM UTC

1. investigating Nov 04, 2026, 12:59 PM UTC

   Incident Description: Our teams have identified an issue affecting a connector within Flexera SaaS Management across all production regions. During this time, affected customers may experience data aggregation failures due to HTTP 504 (Gateway Timeout) errors affecting certain API requests used by the connector. Business Impact: A subset of customers may experience unsuccessful or delayed data aggregation within Flexera SaaS Management and SNOW SaaS management. Impact Start: 3 November 2026, 07:00 AM CET Restoration Activity: The initial investigation by our teams identified timeout errors affecting specific reporting requests required by the connector. The service provider has been engaged and is actively investigating the issue. Our technical teams continue to monitor the affected environments and work closely with the service provider toward resolution. In parallel, additional mitigation measures are being evaluated to help restore successful data aggregation while the investigation continues.

2. investigating Nov 04, 2026, 10:48 PM UTC

   Our technical teams continue to investigate the issue affecting Microsoft 365 connector aggregations. The issue remains isolated to specific reporting operations used to retrieve mailbox usage and application user details, with no additional change to the scope confirmed at this time. We are working with the external service provider toward resolution while continuing to monitor affected aggregation activity. Mitigation options are also being evaluated while the issue remains ongoing. Further updates will be provided as additional information becomes available.

3. monitoring Nov 05, 2026, 04:48 AM UTC

   Our teams have confirmed that successful responses are now being received from the affected APIs following actions taken by the service provider. While response times remain longer than expected, our teams continue to work with the service provider to investigate and monitor performance. We have observed successful connector aggregations following the service recovery. Our teams are also implementing measures to further strengthen service resilience and continue to monitor the environment to confirm sustained stability.

4. resolved Nov 07, 2026, 12:38 AM UTC

   The external service dependency issue affecting SaaS Manager has been resolved. Following restoration, our technical teams continued monitoring service behavior and have observed no further issues. Service stability has been confirmed, and this incident is now considered resolved.

Read the full incident report →

Started Nov 04, 2026, 04:56 AM UTC· resolved Nov 04, 2026, 05:33 AM UTC

1. resolved Nov 04, 2026, 05:44 AM UTC

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

Read the full incident report →

Started Nov 03, 2026, 09:38 AM UTC· resolved Nov 03, 2026, 10:11 AM UTC

1. monitoring Nov 03, 2026, 09:38 AM UTC

   Incident Description: We are investigating an issue affecting Spot services, where a subset of customers may experience launch and scaling issues with across multiple cloud providers. Our monitoring identified increased error rates and service interruptions affecting request processing. Business Impact: Affected customers may experience failures or degraded performance when launching resources or performing scaling operations through Elastigroup and Ocean. Our teams are continuing to assess the overall scope and duration of the impact. Restoration Activity: Our technical teams are actively investigating the underlying cause of the disruption and monitoring service health. The previously observed alerts have recovered, and request processing appears to be returning to normal levels. Teams are continuing to validate service stability and confirm full restoration. Further updates will be provided as the investigation progresses.

2. resolved Nov 03, 2026, 10:11 AM UTC

   After extended monitoring , our teams have confirmed that the services are stable . This incident is now resolved. We will share further details via a post mortem report.

Read the full incident report →

Started Nov 02, 2026, 10:14 AM UTC· resolved Nov 02, 2026, 01:33 PM UTC

1. investigating Nov 02, 2026, 10:14 AM UTC

   Incident Description: We are investigating an issue affecting Spot services for AWS in the us-west-2 region, where increased error rates are being observed. The issue is affecting a subset of customers in the region, who may experience failures or degraded performance when performing scale-up and scale-down operations through Spot. Business Impact: Customers operating in the AWS us-west-2 region may experience failures or degraded performance with scale-up and scale-down operations. Our teams are assessing whether customers in other AWS regions may also be affected. Restoration Activity: Our technical teams are actively investigating the increased error rates and working to determine the full scope of the impact. The investigation includes assessing whether the disruption is limited to the us-west-2 region or extends to additional AWS regions. Further updates will be provided as the investigation progresses.

2. identified Nov 02, 2026, 10:49 AM UTC

   Our technical teams continue to monitor the service disruption affecting Spot services for AWS. AWS has identified the underlying issue and is actively deploying mitigation actions to restore normal service. Our teams will continue to monitor service stability and validate affected Spot operations as AWS progresses with its mitigation activities.

3. monitoring Nov 02, 2026, 11:36 AM UTC

   Following the mitigation actions implemented by AWS, we are observing a continued reduction in error rates and improved service performance. Our teams are successfully completing the majority of previously affected instance termination operations, and no further errors are currently being observed in our service logs. Service conditions appear stable. Our technical teams continue to closely monitor the service and perform validation activities while awaiting further confirmation from AWS.

4. resolved Nov 02, 2026, 01:33 PM UTC

   The issue affecting Spot services for AWS has been resolved. AWS identified an issue affecting API request processing and implemented mitigation actions to restore normal service. During the recovery period, some customers may have experienced increased throttling when performing instance termination operations. These restrictions have now been lifted, and service is operating normally. Our teams have completed validation activities and will continue to monitor service stability. This incident is now resolved.

Read the full incident report →

Started Nov 01, 2026, 04:50 AM UTC· resolved Nov 01, 2026, 04:50 AM UTC

1. resolved Nov 01, 2026, 04:50 AM UTC

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

Read the full incident report →

Started Oct 29, 2026, 09:37 PM UTC· resolved Oct 29, 2026, 11:38 PM UTC

1. investigating Oct 29, 2026, 09:37 PM UTC

   Incident Description: We are investigating an issue affecting multiple Spot operations for AWS. Customers may experience failures, delays, or degraded performance when performing AWS-related operations through Spot. Business Impact: Affected customers may experience failures or delays across multiple Spot operations for AWS, including instance termination, scaling and capacity operations, and creating or managing Elastigroups. Customers may also experience slow or unresponsive AWS Elastigroup creation workflows and issues with Ocean ECS functionality, including ECS clusters not being listed when attempting to import them. The broader scope of affected functionality continues to be assessed. Restoration Activity: Our technical teams continue to investigate elevated latency and communication failures affecting the processing of AWS operations through Spot. Mitigation changes are being deployed to improve service stability, while teams continue to monitor service recovery and validate functionality across affected Spot operations. Further updates will be provided as the investigation progresses.

2. investigating Oct 29, 2026, 10:24 PM UTC

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

3. investigating Oct 29, 2026, 10:57 PM UTC

   Our investigation identified connectivity timeouts and service instability affecting the processing of AWS operations through Spot. Technical teams increased resources for the affected service components and adjusted service health-check settings to improve stability and reduce repeated service restarts. Following these changes, service responsiveness has improved significantly, and validation has confirmed recovery of key customer-facing operations, including Elastigroup creation and scaling. We are continuing to validate remaining affected functionality and closely monitor service performance and stability before considering the incident resolved.

4. resolved Oct 29, 2026, 11:38 PM UTC

   Our technical teams have confirmed that affected Spot operations for AWS have returned to normal. Investigation identified connectivity timeouts and service instability affecting the processing of AWS operations through Spot. To restore stability, technical teams increased resources for the affected service components and adjusted the service health-check timeout to reduce repeated service restarts. Following these changes, service health and response times returned to normal operating levels. Validation confirmed recovery of affected customer-facing functionality, including Elastigroup creation and scaling and Ocean ECS operations. Service performance remained stable throughout the monitoring period, and the incident is now considered resolved. We will continue to investigate the underlying cause. A customer-facing post-mortem report will be published in the coming days with further details on the underlying cause and future preventative measures.

Read the full incident report →

Started Oct 29, 2026, 01:54 PM UTC· resolved Oct 29, 2026, 04:16 PM UTC

1. investigating Oct 29, 2026, 01:54 PM UTC

   Incident Description: We are investigating an issue affecting the Managed Applications page within SaaS Manager in the EU region. Business Impact: Customers may be unable to load the Managed Applications landing page. Other SaaS Manager functionality remains accessible. The issue is currently isolated to the EU region, with no impact identified in other regions. Restoration Activity: Our technical teams are actively investigating and working to restore normal functionality. Further updates will be provided as more information becomes available.

2. resolved Oct 29, 2026, 04:16 PM UTC

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

Read the full incident report →

Started Oct 29, 2026, 06:37 AM UTC· resolved Oct 29, 2026, 06:37 AM UTC

1. resolved Oct 29, 2026, 06:37 AM UTC

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

Read the full incident report →

Started Oct 28, 2026, 11:03 PM UTC· resolved Oct 29, 2026, 07:53 AM UTC

1. investigating Oct 28, 2026, 11:03 PM UTC

   Incident Description: We are investigating an issue affecting instance management operations for a subset of Spot customers using the AWS China North region. Business Impact: Affected customers may experience failures when attempting to launch or terminate instances. Restoration Activity: Our technical teams are actively investigating the issue and working to identify the underlying cause and restore normal instance management operations. Further updates will be provided as the investigation progresses.

2. investigating Oct 29, 2026, 01:08 AM UTC

   Our technical teams have narrowed the investigation to account configuration associated with the affected environment. Teams are reviewing current configuration data against previously known configuration to determine whether identified differences contributed to the instance management failures. The investigation remains ongoing while the identified configuration differences are validated and the appropriate remediation is determined.

3. identified Oct 29, 2026, 04:00 AM UTC

   Our teams have identified that the AWS China account is currently affected due to a billing-related issue. A support case has been raised with AWS to address the issue and restore the account. We will provide further updates as more information becomes available.

4. identified Oct 29, 2026, 07:15 AM UTC

   Our teams continue to work with AWS Support to restore the affected AWS China account. The matter has been escalated within AWS for further assistance, while our teams are also exploring available options to facilitate restoration. We remain actively engaged with AWS and will provide further updates as more information becomes available.

5. resolved Oct 29, 2026, 07:53 AM UTC

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

Read the full incident report →

Started Oct 27, 2026, 05:00 PM UTC· resolved Oct 28, 2026, 10:35 AM UTC

1. identified Oct 27, 2026, 05:00 PM UTC

   Incident Description: We are investigating delays affecting Technopedia content updates. Technopedia content used by Data Platform, IT Visibility, and API services has not been refreshed since October 22 due to repeated data processing failures. Customers may therefore see outdated Technopedia content in affected services. Priority: P2 Restoration Activity: Our technical teams have performed recovery actions to address the data processing failures and have refreshed the underlying content. Catalog generation is currently in progress, and we are monitoring this activity through completion. We will provide a further update as recovery progresses.

2. identified Oct 28, 2026, 01:44 AM UTC

   The Technopedia content refresh remains in progress. Our technical teams continue to monitor the refresh through completion. Once processing is complete, we will validate that updated Technopedia content is available across the affected services to ensure normal content refresh operations have been restored.

3. identified Oct 28, 2026, 09:39 AM UTC

   The Technopedia content refresh remains in progress and continues to be closely monitored by our technical teams. Following completion, we will validate the updated content across the affected services to confirm normal operations have been restored.

4. resolved Oct 28, 2026, 10:35 AM UTC

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

Read the full incident report →

Started Oct 22, 2026, 07:05 AM UTC· resolved Oct 22, 2026, 07:38 AM UTC

1. investigating Oct 22, 2026, 07:05 AM UTC

   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.

2. monitoring Oct 22, 2026, 07:21 AM UTC

   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.

3. resolved Oct 22, 2026, 07:38 AM UTC

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

4. postmortem Nov 05, 2026, 04:26 AM UTC

   **Description:** Flexera One - Snow Atlas - UK South - SAM Core Functionality Inaccessible **Timeframe:** October 21, 2026, 7:45 PM PDT to October 22, 2026, 12:13 AM PDT ‌ **Incident Summary** On October 21, 2026, at 7:45 PM PDT , our monitoring identified an issue affecting Snow Atlas SAM Core functionality in the UK South region, preventing access to the Users menu and associated Users pages. The impact was subsequently confirmed through a customer report. An investigation was initiated to identify the cause of the disruption. The investigation identified communication interruptions affecting application services responsible for supporting the Users functionality. Although connectivity was subsequently re-established, the affected services did not fully recover automatically, resulting in continued disruption to the functionality. As part of the recovery activity, the affected application services were restarted. Following these actions, the Users menu became available again, and the functionality was successfully validated. The technical teams continued monitoring the affected services to confirm sustained recovery. Following successful validation and confirmation that functionality remained stable, the incident was declared resolved on October 22, 2026, at 12:13 AM PDT. ‌ **Root Cause** The issue was caused by a temporary communication interruption between application services and an underlying messaging service. This interrupted message delivery and affected the operation of services supporting the Users functionality. Additionally, the affected application services did not fully recover automatically following the communication interruption, requiring targeted service restarts to restore normal functionality.. ‌ **Remediation Actions** Our teams performed the below actions to restore the services to normalcy: * Identified communication interruptions affecting the application services supporting the Users functionality. * Restarted the affected services to restore normal operation. * Validated that the Users menu was available and the Users pages were loading successfully. * Monitored the affected functionality to confirm sustained service 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: * **Improve automatic service recovery:** Enhance service recovery mechanisms to ensure application services can recover appropriately following communication interruptions. * **Improve subscription recovery:** Review how application services restore their message subscriptions following connectivity interruptions. * **Strengthen application registration:** Improve the application registration process to ensure that required functionality is successfully registered and automatically restored when necessary. * **Enhance monitoring and alerting:** Improve visibility into communication interruptions and unsuccessful application registration to support earlier detection and response.

Read the full incident report →

Started Oct 15, 2026, 06:34 PM UTC· resolved Oct 15, 2026, 07:32 PM UTC

1. resolved Oct 15, 2026, 10:37 PM UTC

   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.

2. postmortem Oct 21, 2026, 11:40 PM UTC

   **Description:** Flexera One - IT Asset Management - APAC - Service Unavailability Following 2026R1.4 Release **Timeframe:** October 15, 2026, 11:34 AM PDT - October 15, 2026, 12:32 PM PDT ## Incident Summary On October 15, 2026, customers using Flexera One IT Asset Management in the APAC region experienced a service disruption that prevented access to the application. The disruption occurred following completion of the ITAM 2026R1.4 production release. Although services were initially available and operating normally after the release, the application subsequently became inaccessible. Technical teams investigated the disruption and identified failures affecting the initialization of application instances. Further investigation revealed that the production environment retained a dependency on a previous application initialization process while a transition to an updated process was underway. Although the application instances had been successfully initialized during the release, replacement instances were unable to complete the same process due to an outdated configuration. The affected replacement instances were unable to complete initialization successfully or pass the required health checks, preventing the application from returning to normal operation. Technical teams corrected the production configuration to reference the updated initialization process and performed an instance refresh. Following these changes, the affected instances initialized successfully, and ITAM service availability was restored at approximately 12:32 PM PDT. ## Root Cause The incident was caused by a remaining production dependency on a previous application initialization process during the transition to an updated process in the APAC production environment. While staging and user acceptance testing environments had already transitioned to the updated process, the APAC production environment retained a configuration that referenced the previous initialization process. During the 2026R1.4 production release, application instances were manually initialized using the updated process, allowing ITAM to initially operate normally despite the remaining production dependency. Components supporting the previous process were subsequently scaled down under the understanding that the broader transition had largely been completed. When replacement application instances were launched, the production configuration continued directing them to the previous initialization process. The affected instances were therefore unable to complete initialization successfully or pass their required health checks, resulting in the service disruption. The remaining production dependency on the previous initialization process was confirmed as the underlying cause of the incident. Correcting the production configuration to use the updated initialization process removed that dependency and allowed replacement instances to initialize successfully. ## Remediation Actions The following actions were taken during the incident response: 1. **Incident Investigation Initiated:** Technical teams investigated the application unavailability and identified failures affecting the initialization and health checks of application instances in the APAC production environment. 2. **Configuration Issue Identified:** Investigation determined that the production configuration continued referencing the previous application initialization process rather than the updated process. 3. **Production Configuration Corrected:** The production configuration was updated to reference the correct application initialization process, removing the dependency on the previous process. 4. **Application Instances Refreshed:** Technical teams performed an instance refresh following the configuration correction, allowing replacement instances to initialize successfully. 5. **Service Recovery Validated:** Technical teams confirmed that the affected instances were initializing successfully, application health checks were passing, and ITAM services had returned to normal operation. ## Future Preventative Measures Following the incident, a retrospective was conducted to review the application initialization process, remaining production dependencies, release-validation procedures, and opportunities to improve incident detection and response. The following corrective actions and improvement activities have been completed or are underway: 1. **Production Configuration Correction:** The APAC production environment has been updated to use the correct application initialization process, replacing the previous configuration. 2. **Legacy Dependency Validation:** A follow-up action has been established to add a validation step before legacy platform components are scaled down or decommissioned, ensuring that production services have fully transitioned and no remaining dependencies exist on the previous platform. 3. **Release and Application Health-Check Review:** Existing application health checks, release-validation procedures, and post-release sanity-test coverage are being reviewed against the failure observed during this incident. The review will determine whether any coverage gaps exist and whether additional monitoring, validation, or other improvements are required. 4. **Instance Scaling Investigation:** We will continue to investigate what triggered the original application instances to scale following the release and determine whether any additional corrective or preventative action is required. 5. **Customer Communication Improvements:** We identified an opportunity for more timely customer communication during this incident. Our established incident escalation and communication practices are designed to ensure proactive customer notification when unplanned service impact is identified. The learning from this incident has been incorporated into our ongoing incident response practices to help ensure these procedures are applied consistently and that timely, proactive updates are provided to customers during service disruptions.

Read the full incident report →

Started Oct 08, 2026, 10:59 AM UTC· resolved Oct 08, 2026, 12:11 PM UTC

1. investigating Oct 08, 2026, 10:59 AM UTC

   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.

2. monitoring Oct 08, 2026, 11:30 AM UTC

   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.

3. resolved Oct 08, 2026, 12:11 PM UTC

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

4. postmortem Nov 02, 2026, 06:25 AM UTC

   **Description:** Snow Atlas - SAM Core - License Service - Service Disruption **Timeframe:** October 8, 2026, 3:18 AM PDT to October 8, 2026, 4:18 AM PDT ‌ **Incident Summary** On Thursday, October 8, 2026 AT 3:18 AM PDT, Flexera teams identified an issue affecting License functionality access within Snow Atlas. The incident affected the UK South and West Europe production environments, where users were unable to load license information and encountered service availability errors when accessing the Licenses module. The issue was reproduced across both internal test tenants and customer tenants. Investigation identified that a recent production deployment had affected the availability of the License Service across production environments. The deployment introduced a configuration omission that prevented the affected services from establishing the required communication with their dependent messaging components. Consequently, the License Service became unavailable, preventing customers from accessing license information and related functionality. To restore service, the technical teams identified and corrected the missing configuration. Following successful validation of the corrective changes, the updated configuration was deployed across the affected environments, restoring the License Service functionality. Post-restoration validation confirmed that license information was loading successfully and the originally reported issues had been resolved. The service returned to normal operation at approximately 4:18 AM PDT. ‌ **Root Cause** The incident was caused by a missing configuration requirement in a production deployment affecting the License Service. The missing configuration prevented the service from establishing the required communication with its dependent components, resulting in service failures and the unavailability of license information. Contributing Factors * Deployment configuration gap: A required configuration component was present in the development and QA environments but was inadvertently omitted from the production deployment. * Service resilience: The affected service did not handle the missing dependency configuration gracefully, resulting in service failure rather than recovering from the dependency error. * Deployment approach: Changes were deployed across production environments simultaneously, increasing the potential scope of impact when the configuration issue occurred. ‌ **Remediation Actions** Our teams performed the below actions to restore the services to normalcy: * The missing production configuration was identified and corrected. * A corrective change was prepared, validated through the automated build process, and merged. * The corrected configuration was synchronized across the production environments. * Post-restoration validation confirmed that License functionality and license information loading had returned to normal. ‌ **Future Preventative Measures** The following actions have been identified and are being worked on to reduce the likelihood of recurrence and improve service resilience: * **Deployment review and validation:** Strengthen reviews of production deployment changes, particularly configuration differences between development, QA, and production environments. * **Review configuration checks:** Review and improve existing checks to identify configuration differences between production and QA before deployment. * **Service resilience:** Improve service recovery and error-handling mechanisms to prevent dependency-related issues from causing complete service unavailability. * **Progressive deployments:** Adopt a phased production deployment approach, validating changes in individual clusters before proceeding with the remaining environments.

Read the full incident report →

Started Oct 08, 2026, 12:08 AM UTC· resolved Oct 08, 2026, 01:39 AM UTC

1. investigating Oct 08, 2026, 12:08 AM UTC

   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.

2. resolved Oct 08, 2026, 01:39 AM UTC

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

3. postmortem Oct 30, 2026, 06:34 AM UTC

   **Description:** Snow Atlas - Australia - Agreements Functionality Unavailable **Timeframe:** October 7, 2026, 4:27 PM PDT to October 7, 2026, 6:23 PM PDT ‌ **Incident Summary** On October 7, 2026, customers using Snow Atlas in Australia experienced issues accessing the Agreements functionality, including missing or unavailable data within the Agreements module. Certain Agreement-related functions, including Custom Agreement Types, also returned errors, preventing customers from accessing the expected functionality. Investigation confirmed that the issue was isolated to the Australia East Production environment, while the other environments continued operating normally. Further investigation identified a service communication issue affecting the Agreements functionality following infrastructure maintenance performed earlier that day. Although the affected services appeared operational from an infrastructure perspective, underlying application-level communication failures prevented them from functioning correctly. To restore service, the technical team restarted the affected Agreements services and their associated backend services. This restored communication between the dependent services and recovered the affected functionality. Following the recovery actions, validation was completed across multiple customer tenants. Agreements data was displaying correctly, and previously affected functionality, including Custom Agreement Types, was operating normally. Service was restored by 6:23 PM PDT, and no further customer impact was reported following recovery. ‌ **Root Cause** The incident was caused by a communication issue between the services responsible for delivering Agreements functionality following a scheduled infrastructure maintenance activity. The affected services in the Australia East Production environment did not recover correctly after the maintenance activity, resulting in application-level errors and the unavailability of Agreements functionality. Contributing Factors * Service recovery: The affected services did not successfully re-establish communication with their dependent services following the maintenance activity. * Application-level error visibility: Although the affected services appeared healthy from an infrastructure perspective, underlying application-level errors were recorded, making the issue less apparent through standard infrastructure health checks. * Environment-specific behaviour: The issue was isolated to the Australia East Production environment. Other production environments and the development and QA environments were not affected. ‌ **Remediation Actions** Our teams performed the below actions to restore the services to normalcy: * The affected Agreements services and their associated backend services were restarted. * Service communication was restored following the restart. * Validation was completed across multiple customer tenants to confirm that Agreements data was displaying correctly. * Custom Agreement Types and other previously affected functionality were confirmed to be operating normally. * The incident was declared resolved following successful validation. ‌ **Future Preventative Measures** The following actions have been identified and are being worked on to reduce the likelihood of recurrence and improve service resilience: * Service resilience: Review and improve the resilience of Agreements services to ensure they recover correctly following infrastructure maintenance and messaging service restarts. * Application monitoring: Improve visibility into application-level errors to identify service degradation even when infrastructure health checks indicate that services are running normally. * Maintenance validation: Strengthen post-maintenance validation to confirm that dependent application services have successfully recovered and are functioning as expected.

Read the full incident report →

Started Oct 07, 2026, 08:27 PM UTC· resolved Oct 08, 2026, 02:24 AM UTC

1. investigating Oct 07, 2026, 08:27 PM UTC

   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.

2. investigating Oct 07, 2026, 10:23 PM UTC

   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.

3. investigating Oct 08, 2026, 12:03 AM UTC

   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.

4. monitoring Oct 08, 2026, 12:04 AM UTC

   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.

5. resolved Oct 08, 2026, 02:24 AM UTC

   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.

6. postmortem Oct 20, 2026, 05:50 PM UTC

   **Description:** Spot Ocean - Kubernetes - Intermittent Controller Connectivity Issues **Timeframe:** October 7, 2026, 11:20 AM PDT - 12:30 PM PDT **Incident Summary** On Wednesday, October 7, 2026, at 11:20 AM PDT, multiple Spot Ocean for Kubernetes environments experienced intermittent controller connectivity alerts. During the incident, the platform temporarily interpreted controller heartbeat information as outdated and suspended scaling operations for affected clusters as a safety measure. The affected controllers continued to report heartbeat information during the incident. However, the timestamp used to validate controller connectivity became outdated within a database component, causing active controllers to appear temporarily unresponsive. The behavior was intermittent, and current heartbeat information subsequently became available without manual intervention, allowing normal scaling operations to resume. Technical teams reviewed the controller heartbeat processing path, database behavior, service telemetry, and related infrastructure signals to determine why valid heartbeat activity was being interpreted as stale. No additional occurrences were observed after the incident window. Following continued monitoring and validation of service stability, the incident was considered resolved. **Root Cause** The incident was caused by an older controller heartbeat timestamp overwriting a more recent valid timestamp within a database component. Although the affected controllers continued reporting heartbeats normally, the outdated timestamp made the most recently stored heartbeat appear older than it was. When the platform evaluated this timestamp, it exceeded the configured heartbeat threshold and triggered a safety mechanism that temporarily suspended scaling operations for the affected clusters. The specific condition that delayed the older database update has not been conclusively established. However, the database update process did not contain a safeguard to prevent an older heartbeat timestamp from replacing a newer valid timestamp. This allowed delayed heartbeat information to create the appearance that actively reporting controllers were unresponsive. **Remediation Actions** The following actions were taken during the incident response: 1. Customer Reports and Service Behavior Reviewed: Technical teams reviewed reported examples to confirm the behavior, establish the impact window, and determine whether the issue was isolated or affecting multiple environments. 2. Controller Heartbeat Activity Validated: Controller activity was reviewed to determine whether the affected controllers had stopped reporting. The investigation confirmed that heartbeat information continued to be sent during the incident. 3. Heartbeat Processing Path Investigated: Technical teams traced how heartbeat information was generated, stored, and evaluated to identify where current heartbeat activity was being interpreted as outdated. 4. Database and Service Health Assessed: Relevant database performance, service behavior, and infrastructure telemetry were reviewed to evaluate potential processing delays and rule out broader platform instability. 5. Timestamp Regression Identified: The investigation determined that an older heartbeat timestamp had overwritten a newer valid timestamp, causing the platform to temporarily interpret the heartbeat as stale. 6. Service Stability Validated: Technical teams continued monitoring following recovery. No additional occurrences were observed, and scaling operations remained stable before the incident was closed. **Future Preventative Measures** The following improvements are planned to strengthen heartbeat processing and improve detection of similar conditions: 1. Heartbeat Timestamp Protection: The database update process will be modified to prevent an older heartbeat timestamp from overwriting a more recent valid timestamp. 2. Improved Diagnostic Logging: Additional logging will be introduced around heartbeat updates to capture the source of each update, relevant request context, previous and new timestamp values, and the source of the timestamp. 3. Monitoring and Alerting: New monitoring and alerting will be developed using the additional diagnostic information to identify timestamp regressions and similar heartbeat-processing conditions more quickly. 4. Database Access Review: Database access patterns associated with heartbeat processing will be reviewed to identify opportunities to reduce processing delays and optimize performance under elevated load.

Read the full incident report →

Started Sep 29, 2026, 11:08 AM UTC· resolved Sep 29, 2026, 11:53 AM UTC

1. investigating Sep 29, 2026, 11:08 AM UTC

   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.

2. resolved Sep 29, 2026, 11:53 AM UTC

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

3. postmortem Oct 13, 2026, 04:42 AM UTC

   **Description:** Spot by Flexera - Event Notification Processing Errors **Timeframe:** September 29, 2026, 2:06 AM PDT - 4:51 AM PDT **Incident Summary** On September 29, 2026, Flexera identified elevated application errors within a notification processing component responsible for handling certain event notification workflows. Automated monitoring detected increased error activity, prompting an investigation to determine whether customer-facing notifications were affected. During the investigation, technical teams identified failures occurring within a notification processing path and performed a detailed assessment of the affected events, notification workflows, and potential customer impact. Initial analysis suggested the issue could potentially affect notification processing more broadly, and a Major Incident was declared while the scope and impact were being validated. Further impact assessment confirmed that the affected notifications were not intended to be published to customers. Event information continued to be successfully recorded and remained available through the platform throughout the investigation. No customer-facing functionality was disrupted, no event data was lost, and no customer impact was identified as a result of this issue. Based on the results of the impact assessment, the incident priority was downgraded and the investigation was concluded after validation confirmed that customer-facing services remained unaffected. **Root Cause** Investigation determined that a notification processing workflow encountered an application exception while handling a subset of internally generated events. These events were configured such that they were not intended for customer notification delivery. Although the exceptions generated elevated application errors and warranted investigation, subsequent analysis confirmed that the affected notifications were not expected to be distributed to customers. As a result, customer-facing notification delivery, platform functionality, and access to event information were not adversely impacted. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Investigation Initiated: Technical teams investigated elevated application errors detected through automated monitoring and assessed potential customer impact. 2. Notification Processing Analysis Performed: The affected notification workflow was reviewed to identify the source of the application exceptions and determine the scope of the issue. 3. Customer Impact Assessment Completed: Technical teams validated the affected notification types, reviewed event publication behavior, and confirmed that the notifications involved were not intended for customer delivery. 4. System Validation and Monitoring Conducted: Error trends, service behavior, and notification processing were monitored to confirm stable operation and validate that customer-facing services remained unaffected. 5. Incident Reclassification Completed: Following confirmation that no customer impact existed, the incident priority was downgraded and the incident was formally resolved. **Future Preventative Measures** Following this investigation, we identified opportunities to improve the speed and accuracy of impact assessment when operational alerts involve internal processing workflows. 1. Improved Impact Assessment: Review internal notification classifications and investigation procedures to accelerate determination of whether an issue affects customer-facing functionality during future incidents. 2. Enhanced Notification Workflow Visibility: Improve operational visibility into customer-facing and non-customer-facing notification processing paths to support faster impact validation and incident response activities.

Read the full incident report →

Started Sep 28, 2026, 09:10 AM UTC· resolved Sep 28, 2026, 09:26 AM UTC

1. investigating Sep 28, 2026, 09:10 AM UTC

   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.

2. resolved Sep 28, 2026, 09:26 AM UTC

   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.

3. postmortem Oct 26, 2026, 12:10 PM UTC

   **Description:** Flexera One- IT Visibility- APAC - Reporting dashboards unavailable **Timeframe:** September 28, 2026, 1:38 AM PDT to September 28, 2026, 2:15 AM PDT ‌ **Incident Summary** ‌ On Monday, 28 September 2026, at 1:38 AM PDT, Flexera identified an issue affecting access to Power BI reporting dashboards for customers in the APAC region. Our technical teams were promptly engaged and the the initial investigation confirmed that the impact was limited to APAC, while the other regions remained responsive. Further investigation determined that configuration changes associated with a planned identity and access management migration had affected the connection settings required by the reporting services. During the application of these changes, the reporting services' connection settings were reset to values that did not contain the complete service addresses required for successful communication. Consequently, the affected services failed to start correctly, resulting in the unavailability of Power BI reporting dashboards for APAC customers. To restore service, the technical team manually corrected the affected connection settings in the APAC environment. This restored communication between the reporting and authentication services, allowing the affected services to recover. Following restoration, validation confirmed that the Power BI reporting dashboards were accessible and operating normally at approximately 2:15 AM PDT. ‌ **Root Cause** ‌ The incident was caused by incorrect connection settings applied to the APAC environment during a configuration change associated with the identity and access management migration. The change reset the reporting services' connection addresses to values that did not contain the complete addresses required for successful communication with the authentication services. As a result, the affected reporting services failed to start correctly, making Power BI reporting dashboards unavailable to customers in the APAC region. Contributing Factors * Configuration inconsistency: The required connection addresses had previously been updated directly in the environment but were not reflected in the deployment configuration. Consequently, the subsequent configuration change reintroduced the incorrect values. * Deployment validation gap: The deployment process did not identify the incorrect connection settings before they affected service availability. * Change Coordination and Dependency Validation: The migration process did not fully account for the configuration requirements of all dependent services, resulting in endpoint changes being applied without prior validation across the affected service dependencies. ‌ **Remediation Actions** Our teams performed the below actions to restore the services to normalcy: * The affected connection settings were corrected to restore communication between the reporting and authentication services. * The affected services recovered, and validation confirmed that Power BI reporting dashboards were accessible and operating normally. * The configuration was subsequently corrected to ensure the required connection settings are maintained consistently for future deployments. ‌ **Future Preventative Measures** ‌ The following actions have been identified and are being worked on to reduce the likelihood of recurrence and improve service resilience: * Configuration management: Ensure service configuration changes are managed consistently to prevent discrepancies between deployed settings and maintained configurations. * Deployment validation: Review planned configuration changes before deployment to verify that required service connection settings remain correct. * Configuration consistency: Ensure critical connection settings are maintained in the appropriate configuration sources and do not depend on manual changes to individual environments. * Change coordination: Improve coordination for planned migrations and configuration changes, including validation of the requirements and dependencies of affected services. * Deployment safeguards: Strengthen pre-deployment checks to identify incorrect configuration settings before they cause service failures.

Read the full incident report →

Started Sep 25, 2026, 11:18 PM UTC· resolved Sep 28, 2026, 05:14 PM UTC

1. investigating Sep 25, 2026, 11:18 PM UTC

   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.

2. identified Sep 26, 2026, 05:31 AM UTC

   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.

3. monitoring Sep 26, 2026, 12:30 PM UTC

   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.

4. monitoring Sep 27, 2026, 05:39 AM UTC

   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.

5. resolved Sep 28, 2026, 05:14 PM UTC

   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.

6. postmortem Oct 08, 2026, 11:25 AM UTC

   **Description:** Flexera One – IT Asset Management – All Regions – App Portal Errors and API Request Failures **Timeframe:** September 24, 2026, 12:12 PM PDT – September 26, 2026, 4:38 AM PDT **Incident Summary** Beginning September 24, 2026, at approximately 12:12 PM PDT, customers using API-based integrations with Flexera One IT Asset Management \(ITAM\) experienced authentication failures that returned HTTP 401 Unauthorized responses. App Portal users also encountered errors when submitting requests, and integrations such as App Broker and Business Adapter that rely on these APIs were affected. Impact was observed across the North America, Europe, and Asia-Pacific regions. Technical teams investigated and confirmed that the failures were not related to customer credentials or customer configuration. Application logs showed that the components required to authenticate these requests were failing to initialize. Further investigation determined that the behavior was introduced by a hotfix deployed as a preventative measure during the response to the earlier ITAM menu loading incident on September 24. Technical teams reproduced the behavior in testing, developed a corrective fix, and validated it. During deployment validation, a secondary component-loading issue was identified and addressed through an updated hotfix. Following deployment of the updated hotfix to Production, technical teams verified that API functionality was operating as expected, and service was restored on September 26 at approximately 4:38 AM PDT. The incident then moved to extended monitoring while customer confirmation was obtained, and confirmation was received on September 28. Following the restoration of service, isolated intermittent authentication failures were reported and investigated separately from the main incident. Technical teams identified additional connection-handling and environment-specific configuration conditions and deployed further hotfixes, which were validated through September 30. Continued monitoring and customer review through October 1 confirmed that the issue could no longer be reproduced and that no further occurrences had been observed. **Root Cause** The incident was caused by a defect in a hotfix that was deployed as a preventative measure during the response to the earlier ITAM menu loading incident on September 24. The hotfix removed a dependency from the application's authentication components and changed how the application reads the configuration it uses to connect to authentication services. The required settings were present in the deployed configuration. However, the application attempted to read them using a method that is not supported for configuration loaded at runtime. As a result, the components required for authentication could not be initialized, and requests that required authentication were rejected as unauthorized. This produced the API errors and App Portal request failures that customers experienced. The same behavior occurred in the pre-production validation environment when the hotfix was applied there. It was not identified before the hotfix reached Production because the affected APIs are not actively used in that environment, and specific error alerting was not yet in place for them. The initial fix addressed the primary configuration defect. During subsequent validation and monitoring, additional component-loading, connection-handling, and environment-specific configuration conditions were identified and required further hotfixes before sustained stability could be confirmed. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Response Initiated: Technical teams began investigating after customers reported authentication failures and API errors. 2. Scope and Customer Configuration Assessed: Technical teams confirmed that the failures were not related to customer credentials or configuration, and confirmed that impact extended to multiple regions. 3. Underlying Condition Identified: Technical teams determined that the required authentication settings were present but could not be read at runtime, and reproduced the behavior in testing. 4. Corrective Fix Developed and Validated: The application code was updated to read the settings using a supported method. Validation testing confirmed that the authentication errors no longer occurred. 5. Corrective Fix Deployed and Service Restored: A secondary component-loading issue identified during deployment validation was addressed through an updated hotfix. After the updated hotfix was deployed to Production, technical teams verified that API functionality was operating as expected. 6. Extended Monitoring and Customer Validation: Technical teams monitored service behavior through the weekend and obtained confirmation from an affected customer. 7. Post-Incident Remediation: After isolated intermittent failures were reported following the restoration of service, technical teams deployed further hotfixes and validated them through September 30. Monitoring and customer review continued through October 1 to confirm that the issue no longer occurred. **Future Preventative Measures** Following the incident, we conducted a retrospective to review the technical cause, hotfix validation process, monitoring capabilities, and factors that contributed to the customer impact. The following measures have been completed or are being implemented: 1. Runtime Configuration Correction: The application has been corrected to read its authentication configuration using a supported method, and additional hotfixes have been deployed and validated across production environments. 2. API Monitoring and Alerting: Error-rate alerting is being added for the affected APIs so that authentication failures are detected in both pre-production and Production environments, even when the service is not actively used. 3. Hotfix Validation Process: We are evaluating additional checks of dependent services, such as API integrations and App Portal functionality, as part of hotfix validation before changes are approved for Production.

Read the full incident report →

Started Sep 25, 2026, 04:19 PM UTC· resolved Sep 26, 2026, 07:13 AM UTC

1. investigating Sep 25, 2026, 04:19 PM UTC

   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.

2. identified Sep 25, 2026, 06:50 PM UTC

   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.

3. identified Sep 25, 2026, 09:22 PM UTC

   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.

4. identified Sep 26, 2026, 12:55 AM UTC

   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.

5. monitoring Sep 26, 2026, 05:25 AM UTC

   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.

6. resolved Sep 26, 2026, 07:13 AM UTC

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

Read the full incident report →

Started Sep 24, 2026, 09:43 PM UTC· resolved Sep 24, 2026, 10:16 PM UTC

1. identified Sep 24, 2026, 09:43 PM UTC

   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.

2. resolved Sep 24, 2026, 10:16 PM UTC

   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.

3. postmortem Oct 09, 2026, 06:33 AM UTC

   **Description:** Spot Ocean for AWS – Instance Provisioning Failures **Timeframe:** September 24, 2026, 12:00 PM PDT to September 24, 2026, 2:54 PM PDT ‌ **Incident Summary** ‌ On September 24, 2026, Spot Ocean for AWS experienced an issue that prevented some customers from launching new instances. As a result, affected clusters were unable to scale as expected when additional compute capacity was required. Existing instances and workloads remained operational throughout the incident. The impact was limited to new instance provisioning and cluster scale-up operations. The technical team identified that a recent software change introduced unexpected behavior during the instance provisioning process. The change was rolled back, which cleared the provisioning errors and restored normal service operation. Following the rollback, the underlying software issue was identified and corrected. The updated functionality has undergone additional validation to ensure the issue is fully addressed before it is reintroduced into the production environment. Technical teams validated successful instance launches following the rollback, and customer validation confirmed that new instance provisioning was functioning as expected. The incident was resolved at 2:54 PM PDT on September 24, 2026. ‌ **Root Cause** ‌ The incident was caused by a recent software change that introduced unintended behavior during AWS instance provisioning. The change affected how certain cluster configuration information was processed, resulting in provisioning failures for some scale-up operations. While the change was designed to support tagging for specific AWS resources, its behavior also affected other supported cluster configurations. Under certain conditions, the updated tagging logic resulted in duplicate tag information being submitted as part of the instance provisioning request. AWS rejected these requests because the tag information did not meet the expected requirements. As a result, Spot Ocean was unable to successfully complete the provisioning of some new instances. This primarily affected new instance launches and cluster scale-up operations. Existing instances had already been successfully provisioned and therefore continued to operate normally throughout the incident. The underlying functionality has since been corrected, and additional validation is being performed to ensure the updated behavior works consistently across the supported AWS cluster configurations before it is returned to production. ‌ ‌ **Remediation Actions** Our teams performed the below actions to restore the services to normalcy: * Rolled back the software change, restoring normal instance provisioning. * Identified and corrected the underlying issue in the affected functionality. * Performed additional validation of the corrected functionality. * Introduced additional safeguards to allow the updated functionality to be rolled out in a controlled manner. * Validated that new instance provisioning and cluster scaling operations were functioning as expected following the rollback. ‌ **Future Preventative Measures** * Expand automated testing for instance provisioning and cluster scaling scenarios. * Increase regression testing across supported AWS cluster configurations. * Expand end-to-end testing for scaling workflows. * Improve monitoring and alerting for provisioning and scaling failures. * Strengthen validation of changes before production deployment. * Introduce additional safeguards for controlled rollout of changes that affect provisioning behavior. * Increase testing coverage for edge cases and error-handling scenarios.

Read the full incident report →

Started Sep 24, 2026, 02:08 PM UTC· resolved Sep 24, 2026, 08:33 PM UTC

1. investigating Sep 24, 2026, 02:08 PM UTC

   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.

2. investigating Sep 24, 2026, 03:44 PM UTC

   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.

3. investigating Sep 24, 2026, 05:48 PM UTC

   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.

4. monitoring Sep 24, 2026, 06:39 PM UTC

   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.

5. resolved Sep 24, 2026, 08:33 PM UTC

   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.

6. postmortem Oct 08, 2026, 11:23 AM UTC

   **Description:** Flexera One – IT Asset Management – NAM – Menu Items Not Loading **Timeframe:** September 24, 2026, 5:27 AM PDT – September 24, 2026, 10:48 AM PDT **Incident Summary** On September 24, 2026, customers using Flexera One IT Asset Management \(ITAM\) in the North America region experienced intermittent issues loading application menu items and accessing portions of ITAM functionality. Some customers encountered partially loaded or missing menus, error messages, and inconsistent application behavior. Technical teams investigated the issue across the application and supporting services and identified abnormal connection utilization within components supporting ITAM functionality. As available connection capacity became exhausted, some application requests could no longer complete successfully, resulting in authentication-related failures and preventing portions of ITAM functionality from loading. Service began recovering at approximately 10:46 AM PDT, before deployment of the corrective hotfix was completed. The last related application errors were recorded at 10:48 AM PDT. Technical teams continued investigating the underlying cause while monitoring the environment and validating customer functionality. Post-incident analysis indicated that application services on the affected servers had restarted, releasing accumulated connections and allowing new connections to be established. The corrective hotfix was subsequently deployed as a preventative measure to address the connection-handling behavior while investigation into the underlying cause continued. Following continued monitoring and customer validation, technical teams confirmed that ITAM functionality had returned to normal operation. **Root Cause** The incident was caused by a connection-management issue introduced during the ITAM 2026 R1.3 production release. A change to the application authentication flow caused new service connections to be created repeatedly rather than reusing existing connections. Over time, these connections accumulated and exhausted the available connection capacity within affected application components. Once that capacity was exhausted, new application requests could not be established successfully. This resulted in authentication-related failures and prevented portions of ITAM functionality from loading, causing missing menu items, error messages, and intermittent loss of access for affected customers. A hotfix correcting this behavior had already been created and was included in the release deployment plan before the Production deployment. The hotfix had initially been designated for the validation environment because Production had not yet been upgraded. It was intended to be applied to Production as part of the R1.3 release, but it was not applied during the Production deployment. As a result, the connection-management correction was not in place when the release went live. **Remediation Actions** 1. Incident Investigation Initiated: Technical teams investigated the application errors and intermittent loss of ITAM functionality to determine the scope and underlying cause. 2. Connection Saturation Identified: Analysis of affected application components identified abnormal connection accumulation that was exhausting available connection capacity and preventing new application requests from completing successfully. 3. Corrective Hotfix Confirmed: Technical teams identified the existing hotfix that corrected the connection-handling behavior by reusing service connections rather than creating new connections for each request. 4. Corrective Hotfix Deployed: The hotfix was deployed to Production as a preventative measure to address the connection-management issue and prevent further connection accumulation. 5. Service Recovery Validated: Technical teams continued monitoring application behavior and validating customer functionality after recovery to confirm that ITAM services had returned to normal operation. **Future Preventative Measures** Following the incident, we conducted a retrospective to review the technical cause, release and hotfix deployment process, monitoring capabilities, and factors that contributed to the customer impact. The following measures have been completed or are being implemented: 1. Connection Management Correction: The corrective change has been implemented to ensure service connections are appropriately reused and to prevent connection accumulation from exhausting available application resources. 2. Production Deployment Validation: The connection-management correction has been deployed and validated across all production regions to ensure consistent implementation. 3. Release and Hotfix Process Improvements: Release procedures are being strengthened so that hotfixes included in release deployment plans are consistently designated for Production deployment, including hotfixes initially created or validated before the Production environment is upgraded. 4. Hotfix Process Review: We are evaluating improvements to the overall hotfix process to reduce reliance on production hotfixes and further reduce the risk of required corrective changes not being included in future production releases. 5. Enhanced Application Monitoring: Additional application-level monitoring and alerting are being implemented to improve early detection of intermittent failures and abnormal error conditions before they result in broader customer impact.

Read the full incident report →

Started Sep 24, 2026, 10:11 AM UTC· resolved Sep 25, 2026, 01:28 PM UTC

1. investigating Sep 24, 2026, 10:11 AM UTC

   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.

2. investigating Sep 24, 2026, 12:27 PM UTC

   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.

3. monitoring Sep 24, 2026, 02:32 PM UTC

   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.

4. monitoring Sep 24, 2026, 06:42 PM UTC

   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.

5. resolved Sep 24, 2026, 08:32 PM UTC

   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.

6. postmortem Oct 23, 2026, 05:25 PM UTC

   **Description:** Flexera One - IT Asset Management - NAM - Inventory Processing Delays Following Production Release Activity **Timeframe:** September 22, 2026, 7:05 PM PDT - September 25, 2026, 5:30 AM PDT **Incident Summary** On September 24, 2026, technical teams began investigating reports of delayed inventory updates affecting a subset of customers using Flexera One IT Asset Management \(ITAM\) in the North America \(NAM\) region. Although inventory files were being successfully uploaded and remained available, some customers experienced delays in processing these files, preventing the latest inventory information from being reflected in the application. Beacon status information displayed in ITAM could also have been outdated for affected customers. Inventory processing continued normally for other customers. The issue occurred following the ITAM 2026R1.3 production release activity on September 22, 2026. Investigation identified an interruption in the process responsible for transferring uploaded inventory files to the ITAM inventory-processing services. While the affected files remained available in storage, they were not being forwarded for processing. Technical teams also observed elevated application errors during the investigation, although these errors were not conclusively established as the cause of the interruption. Technical teams performed a targeted restart of the affected service component, restoring the transfer of inventory files and allowing processing to resume for previously affected customers. Additional diagnostic logging was enabled to support further investigation. However, a significant backlog of inventory files had accumulated during the interruption and required additional time to process. Following restoration of processing, technical teams continued monitoring inventory activity and the accumulated backlog. By Friday, September 25, 2026, at approximately 5:30 AM PDT, the incident-related backlog had returned to normal operating levels, confirming recovery of inventory processing. **Root Cause** The incident was caused by an interruption in the inventory-processing workflow following the ITAM 2026R1.3 production release activity in the NAM region. Although inventory files were successfully uploaded and remained available in storage, the component responsible for forwarding these files to ITAM processing stopped transferring inventory data for a subset of customers. As a result, affected inventory files were not processed, delaying inventory updates. The issue did not affect all customers, as inventory processing continued normally for other organizations. Investigation identified elevated application errors and behavior indicating that the affected processing component was not recovering as expected. The precise technical condition responsible for the partial interruption remains under investigation. A targeted restart of the affected service component restored inventory processing for impacted customers. The accumulated backlog was subsequently processed, allowing inventory updates to return to normal levels. **Remediation Actions** The following actions were taken during the incident response: 1. **Incident Investigation Initiated:** Technical teams investigated reports of delayed inventory updates affecting a subset of customers in the NAM region and reviewed the inventory-processing workflow to determine the scope of the issue. 2. **Inventory Processing Interruption Identified:** Investigation confirmed that uploaded inventory files were available in storage but were not being forwarded to the processing services for affected customers. 3. **Affected Service Component Restarted:** A targeted restart of the affected service component restored the transfer of inventory files and allowed processing to resume for previously affected customers. 4. **Additional Diagnostic Logging Enabled:** Additional logging was enabled to capture further technical information and support continued investigation into the underlying processing interruption. 5. **Inventory Backlog Recovery Monitored:** Technical teams monitored the accumulated inventory backlog following restoration of processing and confirmed that inventory files were being processed successfully. 6. **Service Recovery Validated:** Technical teams confirmed that the incident-related backlog had returned to normal operating levels by September 25 and that inventory processing remained stable. **Future Preventative Measures** Following the incident, we conducted a retrospective to review the partial inventory-processing failure, the existing inventory-delivery architecture, available diagnostic information, and opportunities to improve processing reliability and failure visibility. The following corrective actions and improvement activities are underway: 1. **Inventory Processing Architecture Improvement:** Work is planned to simplify the inventory-processing integration by enabling ITAM to retrieve uploaded inventory files directly from the storage layer rather than relying on the existing intermediate forwarding service. This change will remove an additional dependency from the processing path and provide greater control over processing, backlog management, capacity, and recovery. 2. **Improved Failure Diagnostics:** The diagnostic logging and telemetry required to capture the relevant service state during a partial inventory-processing failure will be assessed and enhanced as appropriate. This will provide improved technical information to support root-cause determination if a similar condition recurs.

Read the full incident report →

Started Sep 23, 2026, 10:05 AM UTC· resolved Sep 23, 2026, 11:43 AM UTC

1. investigating Sep 23, 2026, 10:05 AM UTC

   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.

2. monitoring Sep 23, 2026, 10:24 AM UTC

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

3. resolved Sep 23, 2026, 11:43 AM UTC

   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.

4. postmortem Oct 26, 2026, 10:40 AM UTC

   **Description:** Flexera One - EU - Access unavailable **Timeframe:** * September 24, 2026, 2:51 AM PDT to September 24, 2026, 3:18 AM PDT * September 25, 2026, 3:50 AM to September 25, 2026, 4:30 AM PDT ‌ **Incident Summary** ‌ On 24 September 2026 at 2:51 AM PDT, customers experienced login failures when attempting to access the Flexera One EU Production environment. Investigation confirmed degradation of the EU Identity and Access Management services, which prevented customers from accessing the platform. The investigation identified a significant increase in database connections associated with elevated traffic from a single organisation. Further analysis determined that repeated downstream requests generated by other services also contributed to the increased load on the authentication and access-control services. At 3:18 AM PDT, customer login functionality was restored without direct technical intervention, and the platform returned to normal operation. On 25 September 2026 at approximately 3:50 AM PDT, another increase in database connections was observed, associated with elevated traffic from the same organisation. The increased load continued for approximately 40 minutes. In response, autoscaling was enabled for the resource management service to increase capacity and improve platform stability.. ‌ **Root Cause** ‌ The incident was caused by an unexpected increase in traffic that placed excessive demand on the EU authentication services and associated database connections. The increased load affected the services responsible for processing authentication requests, resulting in customer login failures within the EU Production environment. Repeated requests from other services to the authentication and access-control services further contributed to the elevated load. In addition, automatic scaling was not enabled for the resource management service, limiting its ability to dynamically increase capacity in response to higher demand. Gaps in proactive monitoring and alerting also limited the ability to identify the degradation before customers experienced access failures. ‌ **Remediation Actions** ‌ Our teams performed the below actions to restore the services to normalcy: * The September 24 incident resolved without direct engineering intervention, and customer login functionality was restored at 3:18 AM PDT. * On 25 September, autoscaling was enabled for the resource management service to increase capacity in response to elevated demand. * The team continued monitoring database connections and service health to assess platform stability. ‌ **Future Preventative Measures** ‌ The following actions have been identified and are being worked on to reduce the likelihood of recurrence and improve service resilience: * Automatic scaling: Review autoscaling configuration for the resource management service across all production regions, to ensure capacity adjusts to changes in workload. * Database capacity management: Review database connection pool settings and ensure that service scaling remains within the database's available connection capacity. * Proactive monitoring and alerting: Review and introduce alerts for abnormal database connection growth, connection pool saturation, service latency, error rates, and resource utilization. * Traffic monitoring: Improve visibility into organization-level traffic patterns to identify unusual request spikes before they affect other customers. * Traffic management: Evaluate appropriate rate-limiting and throttling controls to prevent excessive traffic from a single organization from affecting platform-wide availability. * Load and capacity testing: Conduct load testing using traffic patterns representative of the incident to validate service performance and database capacity under elevated demand.

Read the full incident report →

Started Sep 23, 2026, 06:51 AM UTC· resolved Sep 23, 2026, 03:57 PM UTC

1. investigating Sep 23, 2026, 06:51 AM UTC

   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.

2. investigating Sep 23, 2026, 09:15 AM UTC

   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.

3. monitoring Sep 23, 2026, 11:47 AM UTC

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

4. monitoring Sep 23, 2026, 01:02 PM UTC

   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.

5. resolved Sep 23, 2026, 03:57 PM UTC

   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.

6. postmortem Sep 30, 2026, 04:02 PM UTC

   **Description:** Flexera One – IT Asset Management – North America – Service Unavailability Following 2026R1.3 Maintenance **Timeframe:** September 22, 2026, 9:00 PM PDT – September 23, 2026, 5:47 AM PDT **Incident Summary** On September 22, 2026, Flexera conducted the planned 2026R1.3 production release for Flexera One IT Asset Management in the North America region. The upgrade progressed successfully across the vast majority of databases within the environment. However, when the scheduled maintenance window concluded at 9:00 PM PDT, a required database migration operation remained in progress. Because the production environment could not be restored until the migration completed, IT Asset Management remained unavailable beyond the scheduled maintenance period. The remaining migration required a large database index rebuild involving a significant volume of data. The operation became the critical path for completing the release and took substantially longer than anticipated. After the initial index-processing stage completed, the database still needed to perform additional sorting and index-creation activities. This work continued for several hours and extended the overall duration of the migration. During the investigation, technical teams evaluated available recovery options, including whether the affected database could be temporarily separated from the migration path to allow the remainder of the environment to return to service. Due to the stage of the deployment and the additional recovery work this approach would have required, the most reliable recovery path was to allow the database operation to complete before restoring the environment. Once the database migration completed, technical teams began restoring application and supporting services. During startup, an additional service-recovery issue was encountered that required manual intervention before restoration could continue. Following remediation, the remaining application and platform services were successfully restored. Technical teams then completed validation activities, confirmed customer access, and performed extended monitoring to verify service stability. Customer impact ended on September 23, 2026, at 5:47 AM PDT. **Root Cause** The outage was caused by a database index configuration discrepancy that was identified during the 2026R1.3 migration, resulting in a large index rebuild operation that substantially exceeded the planned maintenance window. Post-incident investigation determined that an index within the affected database did not match the database structure expected by the current release. The index had previously been recreated using an older definition that did not incorporate a subsequent database design change. During the 2026R1.3 deployment, the migration process identified this difference and initiated the database operation required to bring the index into alignment with the current database definition. Because of the exceptionally large size of the dataset involved, the resulting rebuild became a long-running and resource-intensive operation that significantly exceeded the planned maintenance window. Once the rebuild was underway, the remaining processing duration could not be reliably predicted, which made it difficult to provide an accurate completion estimate while the operation continued. **Remediation Actions** The following actions were taken during the incident response: * Index Rebuild Monitored: The index rebuild and remaining database upgrade activities were continuously monitored through completion. * Recovery Options Evaluated: Available restoration approaches were assessed to determine the safest and most reliable path for returning the production environment to service. * Database Upgrade Completed: The index rebuild and remaining database upgrade activities were completed before application restoration began. * Application and Supporting Services Restored: Application and supporting services were restored. Targeted recovery actions were performed when an additional service-startup issue was encountered. * Service Recovery Validated: Customer access and application functionality were confirmed, remaining background processing was reviewed, and extended monitoring was completed to verify stable operation. **Future Preventative Measures** Flexera recognizes the significance and duration of this outage and the impact it had on customers in the North America region. A full root cause analysis and cross-functional retrospective have been completed, and the following preventative measures have been identified as part of the ongoing improvement effort: 1. Database Procedure Validation: Technical teams are assessing how database remediation procedures are reviewed and maintained to ensure they remain aligned with current product requirements as the platform evolves. 2. Pre-Deployment Verification: Release-validation processes are being evaluated to determine how unexpected database configuration differences can be identified and assessed before production maintenance begins. 3. High-Impact Operation Assessment: Technical teams are assessing how potentially long-running or resource-intensive database operations can be identified during release preparation so their expected duration and operational impact can be better understood before deployment. 4. Release Readiness and Recovery Planning: Release-readiness and recovery-planning practices are being reviewed to improve visibility into activities that may significantly affect deployment duration and service-restoration timelines. Providing reliable and resilient services remains a priority. The findings from the completed root cause analysis and retrospective are being incorporated into technical and operational improvements intended to reduce the likelihood of recurrence and strengthen the planning and execution of future maintenance activities.

Read the full incident report →