Flexera Outage History

Started Mar 18, 2026, 03:36 PM UTC· resolved Mar 18, 2026, 03:43 PM UTC

1. investigating Mar 18, 2026, 03:36 PM UTC

   Incident Description: We experienced an issue affecting access to the Flexera One UI across North America (NA), Europe (EU), and Asia-Pacific (APAC) regions. During this time, customers attempting to start new sessions or log in to the UI may have encountered access errors. Customers who already had an active session open may have continued to access the UI, while new login attempts could fail. As a result, some users may have been unable to access the UI during the incident window. Priority: P1 Incident Start Time: March 18, 2026, 02:39 AM CT Incident End Time: March 18, 2026, 04:35 AM CT Incident Duration: 1 hour 56 minutes Restoration Activity: Our technical teams investigated the issue and identified a configuration change affecting UI access controls. The change was reverted, restoring normal access to the Flexera One UI across NA, EU, and APAC. The service has been operating normally since the fix was applied, and we continue to monitor the environment.

2. resolved Mar 18, 2026, 03:43 PM UTC

   The issue affecting access to the Flexera One UI across NA, EU, and APAC has been resolved. The service has been operating normally since the fix was implemented, and we continue to monitor the environment.

3. postmortem Mar 31, 2026, 06:34 AM UTC

   **Description:** Flexera One – UI – All Regions – Access Disruption \(HTTP 403 Errors\) **Timeframe:** March 18, 2026, 2:39 AM PDT – March 18, 2026, 4:35 AM PDT **Incident Summary** On March 18, 2026, at approximately 2:39 AM PDT, an issue was identified affecting access to the Flexera One UI across North America \(NA\), Europe \(EU\), and Asia-Pacific \(APAC\). During this period, customers attempting to start new sessions or log in to the UI may have encountered HTTP 403 errors when attempting to access the service. Customers who already had an active session open may have continued to access the UI, while new login attempts could fail. As a result, some users may have been unable to access the UI during the incident window. Technical teams began investigating immediately and confirmed that the issue was related to a recently introduced security control change that affected legitimate access requests more broadly than intended. By March 18, 2026, at approximately 4:35 AM PDT, the change had been reverted and access to the Flexera One UI was restored across all affected regions. Following validation that login and access behavior had returned to expected operation, the incident was considered resolved. **Root Cause** The incident was caused by a recently introduced security control change that behaved more broadly than intended and unintentionally blocked valid customer access requests. This prevented some customers from successfully starting new sessions or logging in to the Flexera One UI and resulted in HTTP 403 errors during the incident window. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Detection and Response Initiated: Technical teams were notified of the access issue and began investigating the disruption affecting the Flexera One UI across all regions. 2. Impact Isolation: It was confirmed that the issue was affecting new login attempts and session initiation, while some existing active sessions could continue operating during the incident window. 3. Change Review and Validation: The recently introduced control change was reviewed to determine why legitimate customer access requests were being blocked. 4. Corrective Change Applied: The change responsible for the unintended blocking behavior was reverted to restore normal access. 5. Service Restoration Verification: Following the corrective action, access to the Flexera One UI was validated across affected regions and confirmed to be functioning normally. **Future Preventative Measures** This incident highlighted the importance of strong validation, coordination, and monitoring when implementing access-related control changes within a centralized configuration. Based on this experience, the following measures are being applied: 1. Change Validation and Deployment Controls: We are strengthening review, validation, and staged deployment practices for access-related control changes before they are applied more broadly. 2. Rollback and Communication Readiness: We are reinforcing rollback preparedness, stakeholder communication, and post-change monitoring to reduce the likelihood and duration of similar issues. 3. Alerting Sensitivity Review: We are reviewing alerting sensitivity to help identify unintended access disruptions sooner following similar changes.

Read the full incident report →

Started Mar 17, 2026, 04:56 AM UTC· resolved Mar 17, 2026, 08:11 AM UTC

1. identified Mar 17, 2026, 04:56 AM UTC

   Incident Description: We are currently investigating an issue affecting inventory ingestion within Flexera One – IT Visibility (ITV) in the EU production environment. The service is experiencing a processing backlog, which may result in delays in inventory updates from third-party data sources. ITV user interfaces and APIs remain fully accessible, and core functionality is not impacted. Priority: P3 Restoration Activity: Our technical teams have identified the likely cause as resource constraints in a managed caching service. We have increased capacity and are actively evaluating system recovery while working to clear the backlog. We are closely monitoring the situation and will provide further updates as progress is made.

2. resolved Mar 17, 2026, 08:11 AM UTC

   Inventory ingestion has been fully restored, and data processing is operating normally. We are proactively replaying customer third-party data to ensure completeness and prevent any missed updates. All other third-party data sources are already up to date and processing as expected

3. postmortem Apr 01, 2026, 04:38 AM UTC

   **Description:** Flexera One – IT Visibility – EU – Delayed Inventory Updates from Third-Party Data Sources **Timeframe:** March 16, 2026, 7:40 PM PDT – March 17, 2026, 1:30 AM PDT **Incident Summary** On March 16, 2026, at approximately 7:40 PM PDT, an issue was identified affecting inventory ingestion within the Flexera One IT Visibility service in the EU production environment. During this period, inventory data received from certain third-party data sources was delayed in processing, resulting in backlogged inventory updates for some customers. Throughout the incident, the IT Visibility user interface and APIs remained accessible. The impact was limited to delays in the processing and reflection of inventory updates from third-party integrations. Technical teams began investigating immediately and implemented corrective actions to restore processing and recover the affected backlog. As part of the recovery effort, processing capacity was increased and affected third-party data was replayed to ensure that no updates were missed. Processing subsequently resumed and the backlog was cleared. By March 17, 2026, at approximately 1:30 AM PDT, recovery had been confirmed and the incident was considered resolved. **Root Cause** The incident was associated with resource constraints affecting the inventory ingestion flow, which resulted in processing delays and backlog growth for inventory data received from third-party data sources in the EU region. At the time of writing, further internal review is continuing to determine the precise underlying cause of the condition that led the service into this state. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Investigation Initiated: Technical teams began investigating the delayed processing affecting third-party inventory ingestion in the EU region. 2. Capacity Increase Applied: Processing capacity was increased to relieve the constraint contributing to the backlog. 3. Processing Recovery Monitored: Processing behavior was monitored to confirm that data flow had resumed successfully. 4. Data Replay Performed: Third-party data was replayed as part of recovery to ensure that delayed updates were processed completely. 5. Service Restoration Validated: Technical teams confirmed that backlog processing had caught up and that inventory ingestion had returned to expected operation. **Future Preventative Measures** This incident highlighted the importance of continued review of ingestion performance conditions and earlier detection of backlog-related degradation affecting third-party inventory processing. Based on the current information available, the following follow-up activities are being pursued: 1. Underlying Cause Review: Complete a deeper review to determine the precise underlying cause of the processing constraint that led to the backlog condition. 2. Alerting and Detection Improvements: Review and improve alerting and detection thresholds to help identify similar ingestion slowdowns sooner. 3. Recovery Process Review: Review the additional issues identified during incident response that affected the resolution effort and determine whether any follow-up improvements are needed.

Read the full incident report →

Started Mar 16, 2026, 04:06 AM UTC· resolved Mar 16, 2026, 06:17 AM UTC

1. investigating Mar 16, 2026, 04:06 AM UTC

   Incident Description: We are currently investigating an issue affecting inventory upload status reporting within Flexera One – IT Visibility (ITV) for customers in the APAC region. Inventory ingestion is processing successfully; however, the system responsible for reporting upload processing status is failing. As a result, inventory uploads may incorrectly appear as “Timed Out” even though the underlying data ingestion may have completed successfully. Priority: P3 Restoration Activity: Our technical teams are actively investigating the issue impacting upload status reporting and are working to identify the underlying cause. We are monitoring the situation closely and will provide further updates as progress is made.

2. resolved Mar 16, 2026, 06:17 AM UTC

   Our teams identified the issue as an incorrect routing configuration and implemented the necessary updates to correct it. Following the change, routing behavior, traffic flow, and overall service health were validated, and all components are now confirmed to be operating normally.

3. postmortem Mar 30, 2026, 03:41 AM UTC

   **Description:** Flexera One – IT Visibility – APAC – Inventory Upload Status Reporting Failure **Timeframe:** March 15, 2026, 8:20 PM PDT – March 15, 2026, 11:08 PM PDT **Incident Summary** On March 15, 2026, at approximately 8:20 PM PDT, technical teams identified an issue affecting inventory upload status reporting in the APAC region. During this period, inventory uploads continued to be ingested and processed, but the status reporting associated with those uploads did not update correctly. As a result, affected uploads could appear as timed out within the application even though processing was continuing successfully. Technical teams immediately began investigating the issue and worked to isolate the source of the reporting failure. The investigation confirmed that the issue was limited to the APAC region and was specific to the status reporting path rather than the underlying inventory upload processing itself. By March 15, 2026, at approximately 11:08 PM PDT, the underlying issue had been corrected and service behavior was validated as functioning normally. Following verification that traffic flow and status reporting had returned to expected behavior, the incident was considered resolved. **Root Cause** The incident was caused by an incorrect routing configuration within the service communication path used for inventory upload status reporting. This prevented status-related requests from reaching the intended service endpoint, which caused status reporting to fail even though the underlying upload processing continued to operate normally. Further investigation determined that the deployed configuration did not match the intended configuration. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Detection and Response Initiated: Technical teams were notified of the issue and began investigating the failure affecting inventory upload status reporting in APAC. 2. Impact Isolation: It was confirmed that the issue was limited to the APAC region and that inventory uploads were continuing to process successfully while status reporting was not updating correctly. 3. Configuration Review and Validation: The relevant service configuration was reviewed to identify where status-related requests were not reaching the intended endpoint. 4. Corrective Configuration Update: A corrective routing change was applied to direct traffic to the proper service endpoint used for status communication. 5. Service Restoration Verification: Following the corrective update, service traffic and status reporting behavior were verified as functioning as expected. **Future Preventative Measures** This incident highlighted the importance of ensuring configuration consistency and correct service communication paths within the platform. Based on this experience, the following measures are being applied: 1. Configuration Consistency Controls: We are reviewing controls to ensure deployed configurations remain aligned with intended configuration standards. 2. Post-Change Validation: We are evaluating validation steps following configuration changes to ensure service communication paths are functioning as expected.

Read the full incident report →

Started Mar 07, 2026, 05:07 PM UTC· resolved Mar 08, 2026, 03:35 AM UTC

1. investigating Mar 07, 2026, 05:07 PM UTC

   Incident Description: We are currently investigating an issue affecting export functionality within Flexera One – IT Visibility for customers in the North America (NAM), Europe (EU), and Asia-Pacific (APAC) regions. As a result, customers may experience failures when attempting to generate or download exports. Priority: P2 Restoration Activity: Our technical teams have been engaged and are actively working to identify the underlying cause and implement remediation to restore normal export functionality. We are monitoring the situation closely and will provide further updates as progress is made.

2. identified Mar 07, 2026, 06:39 PM UTC

   Our technical teams continue to investigate the issue. A fix has been identified and is currently undergoing testing. We will provide further updates as progress is made.

3. identified Mar 07, 2026, 08:56 PM UTC

   Our technical teams have deployed a fix to address the export failures. Early validation indicates that export functionality has improved in some regions, and we are continuing to monitor as the changes propagate across all regions. Further updates will be provided as validation progresses.

4. resolved Mar 08, 2026, 03:35 AM UTC

   Our technical teams have implemented corrective measures to address the issue affecting export functionality within Flexera One – IT Visibility. Post-deployment validation confirms that exports and related query services are operating normally across all regions. This incident has now been resolved. A detailed root cause analysis report will be shared in the coming days.

5. postmortem Apr 06, 2026, 11:57 AM UTC

   **Description:** Flexera One – IT Visibility – All Regions – Export Failures **Timeframe:** March 7, 2026, 8:52 AM PST to March 7, 2026, 5:13 PM PST ‌ **Incident Summary** On Saturday, 7 Mar 2026, at 8:52 AM PST, our teams identified an issue affecting Flexera One – IT Visibility in all regions where monitoring alerts and customer reports indicated failures in export functionality. Our technical teams were promptly engaged and the issue was isolated to a query, where export requests were failing during execution. Initial investigation determined that the failures were caused by a recent deployment that had successfully passed staging validation; however, the behavior in production unexpectedly differed, resulting in errors when customers attempted to generate or download export files. Our technical teams identified a flaw in the query design and developed a fix to refine the query logic, significantly improving execution reliability. The fix was validated in staging and then deployed in a phased manner across regions. APAC was restored first, confirming the effectiveness of the solution. Deployment to EU followed and completed successfully, while NAM required additional time for full propagation before export operations returned to normal. Continuous monitoring after deployment confirmed that export functionality was fully restored across all regions by 5:13 PM PST. ‌ **Root Cause** The issue was introduced during a planned deployment where a query behavior change, although validated in staging, did not function as expected in the production environment, resulting in export failures. Contributing Factors: * A discrepancy between staging and production environments led to differences in query execution behavior. * The query design required adjustments to align with production data handling patterns. * Pre-deployment validation did not fully capture this variation in behavior. ‌ **Remediation Actions** The following remediation steps were implemented to restore service functionality: * Refined the query logic to align with expected production behavior and ensure consistent execution. * Validated the updated query in a controlled staging environment prior to release. * Deployed the fix in a phased manner across APAC, EU, and NAM regions to ensure stability. * Performed post-deployment validation to confirm successful export functionality across all regions. * Continued monitoring to ensure sustained stability and expected system behavior. ‌ **Future Preventative Measures** * Production-Scale Validation Enhancement - Improve pre-release validation to better simulate real-world production data volumes and usage patterns. * Query Performance & Scalability Testing Improvements - Introduce stricter performance benchmarks and scalability testing for queries used in high-volume operations such as exports. * Enhanced Monitoring & Proactive Alerting - Expand monitoring coverage and implement proactive alerting for export failures to reduce detection and response time.

Read the full incident report →

Started Mar 02, 2026, 08:46 PM UTC· resolved Mar 03, 2026, 05:29 PM UTC

1. monitoring Mar 02, 2026, 08:46 PM UTC

   Incident Description: Our teams have identified and are actively investigating an issue impacting SaaS inventory imports across all regions. Affected customers may experience import failures and timeouts while processing uploads. Priority: P2 Restoration Activity: Our teams identified the root cause as an issue with the authentication service and implemented a configuration update to resolve it. The service has now returned to normal operation, and our teams are closely monitoring the environment to ensure continued stability.

2. investigating Mar 03, 2026, 10:30 AM UTC

   After an extended period of monitoring, our teams have observed that FSM imports continue to fail . The issue remains under active investigation, with technical teams fully engaged to identify and address the underlying cause. We will share further updates as more information becomes available.

3. investigating Mar 03, 2026, 10:30 AM UTC

   We are continuing to investigate this issue.

4. monitoring Mar 03, 2026, 11:40 AM UTC

   Our teams team dentified that an associated service had not been updated. As a result, traffic was not being routed to the cluster. The required service updates have now been completed across all regions and environments, and traffic routing has been restored accordingly. We will continue to monitor the services to ensure stability.

5. resolved Mar 03, 2026, 05:29 PM UTC

   The issue affecting Flexera SaaS Manager and related inventory import processes has been resolved. Our team identified and corrected a service configuration issue that impacted authentication requests required for certain import and reconciliation jobs. The affected service has been restored across all regions. Validation confirms that inventory imports are executing successfully, and no further impact has been observed. We will continue to monitor the environment closely as a precaution. A detailed review is underway to ensure additional safeguards are in place to prevent recurrence.

6. postmortem Mar 16, 2026, 07:26 PM UTC

   **Description:** Flexera One – SaaS Manager – All Regions – Inventory Import Failures **Timeframe:** March 2, 2026, 1:09 AM PST – March 3, 2026, 9:05 AM PST **Incident Summary** On March 2, 2026, at 1:09 AM PST, reports were received indicating that Flexera SaaS Manager inventory imports were failing for multiple customers. During this period, affected imports were unable to complete successfully and returned an error indicating that the system was unable to obtain an access token required for processing the import workflow. The issue affected customers across multiple regions and resulted in scheduled SaaS Manager imports failing to execute as expected. Other Flexera platform functionality remained available during this time. Technical teams engaged to investigate the issue and identified that the failures were related to a service responsible for issuing authentication tokens used during the SaaS Manager import process. Recovery activities were initiated to restore normal service behavior and ensure the affected service was functioning correctly across all environments. Following the corrective actions, successful SaaS Manager imports were observed across multiple regions, confirming that the issue had been resolved. Additional monitoring and validation were performed to ensure that the service continued operating as expected. By March 3, 2026, at 9:05 AM PST, successful imports had been confirmed across regions and the incident was formally closed. **Root Cause** The disruption occurred due to a configuration issue affecting the service responsible for issuing authentication tokens used during the SaaS Manager import process. As a result, the service was unable to provide the required access tokens needed for import processing. Because SaaS Manager imports depend on this authentication service, import jobs were unable to obtain the required access token and therefore failed after retry attempts were exhausted. **Remediation Actions** 1. Service Configuration Correction: The configuration affecting the authentication service was corrected to restore its ability to issue access tokens required by SaaS Manager imports. 2. Service Update Across Environments: The service responsible for authentication was updated across all regions and environments to ensure consistent operation. 3. Infrastructure Validation: After the update, the authentication service was verified to be running correctly across environments. 4. Functional Verification: Successful SaaS Manager imports were confirmed across multiple regions following the fix, verifying that the import process was functioning normally. 5. Post-Restoration Monitoring: Additional monitoring and validation activities were performed to ensure imports continued to succeed after the service update. **Future Preventative Measures** This incident highlighted the importance of monitoring and resilience for services responsible for authentication and import processing within the platform. Based on this experience, the following measures are being applied: 1. Monitoring and Alerting Improvements: Additional alerting and monitoring capabilities are being introduced to help detect similar service disruptions earlier and enable faster remediation. 2. Configuration Safeguards: The service configuration has been updated to prevent the behavior that caused the authentication service disruption observed during this incident.

Read the full incident report →

Started Feb 24, 2026, 03:33 PM UTC· resolved Feb 25, 2026, 06:53 AM UTC

1. investigating Feb 24, 2026, 03:33 PM UTC

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

2. investigating Feb 24, 2026, 04:08 PM UTC

   Our technical teams continue investigating the login access issue affecting Flexera One in the APAC region. Ongoing analysis has identified service request failures impacting the login process, and additional diagnostic measures have been enabled to assist with remediation efforts. Investigation and stabilization activities remain in progress as teams work to restore normal access. We continue to monitor service health closely and will provide further updates as additional progress is made.

3. investigating Feb 24, 2026, 07:09 PM UTC

   Our technical teams continue to investigate the login access issue affecting Flexera One in the APAC region. Diagnostic and stabilization activities remain ongoing as teams work to identify the underlying cause and restore normal access. We are closely monitoring service health and will provide further updates as soon as additional information becomes available.

4. investigating Feb 24, 2026, 08:48 PM UTC

   Our technical teams continue investigating the login access issue affecting Flexera One in the APAC region. Ongoing analysis has identified service communication issues impacting requests required for successful login. Configuration adjustments have been applied, and validation activities are currently in progress as teams work toward restoring consistent access. Some service responses have begun recovering; however, customers may still experience intermittent login errors while stabilization efforts continue. We remain actively engaged in remediation and monitoring service health closely. Further updates will be provided as progress continues.

5. monitoring Feb 24, 2026, 09:40 PM UTC

   Remediation activities for the login access issue affecting Flexera One in the APAC region have been implemented, and service recovery has been observed. Customers may now be able to access the Flexera One UI. Some functionality may continue to experience intermittent errors while final stabilization and validation activities continue across affected services. Our technical teams remain engaged and are monitoring the environment closely. Further updates will be provided as restoration efforts progress.

6. monitoring Feb 25, 2026, 12:35 AM UTC

   Service access has been restored for customers accessing the Flexera One platform in the APAC region. We are continuing to investigate an issue affecting certain backend services. Customers may still experience intermittent errors when navigating within the platform, loading reports or dashboards, or accessing some functionality. We remain actively engaged and are working toward full restoration. Further updates will be provided as progress continues.

7. monitoring Feb 25, 2026, 05:30 AM UTC

   Our technical teams continue to investigate the issue impacting certain backend services in the APAC region. Customers may still encounter intermittent errors while navigating the platform, loading custom reports or dashboards, or accessing specific functionality. Investigation and stabilization efforts remain actively in progress as we work toward full service restoration. We will continue to provide updates as additional progress is made.

8. resolved Feb 25, 2026, 06:53 AM UTC

   We have successfully implemented corrective measures to address the service disruption impacting customers in the APAC region. As part of the resolution, our teams made configuration changes to ensure proper upstream service accessibility. Post-validation confirms that services have returned to normal operation. We will conduct a detailed retrospective analysis to determine the underlying root cause. A comprehensive post-mortem report outlining our findings and preventive actions will be shared once the review is complete.

9. postmortem Mar 16, 2026, 10:02 AM UTC

   **Description:** Flexera One – APAC – Login Issue **Timeframe:** February 24, 2026, 07:33 AM PST to February 24, 2026, 10:50 PM PST ‌ **Incident Summary** ‌ On Tuesday, February 24, 2026, at 07:33 AM PST , our teams identified login failures affecting customers attempting to access Flexera One in the APAC region. The affected users encountered authentication errors during login, preventing access to the platform and associated workflows. Initial investigation confirmed that the core authentication infrastructure and identity services were operating as expected. Further analysis isolated the issue to the API gateway layer, where requests were failing due to connection issues affecting specific backend services. As a result, authentication calls and dependent APIs returned errors when routed through the gateway. Our technical teams reviewed the gateway routing configuration and discovered that the affected APAC services were using a specialized gateway path configured with a non-standard port. Traffic using this configuration encountered handshake failures at the gateway layer. To restore service, configuration updates were applied to the API gateway, and the impacted service endpoints were migrated to standard HTTPS communication over the recommended port. After the updated routing configuration was deployed and validated, authentication requests and dependent APIs returned to normal operation. Login access to Flexera One was fully restored, and the incident was closed following confirmation of platform stability. ‌ **Root Cause** ‌ The incident was caused by a gateway routing configuration that failed to properly handle secure service communication for certain APAC endpoints. Some APAC services were configured to communicate through the API gateway using a non-standard port. Requests routed through this configuration experienced handshake failures within the gateway layer, which prevented authentication-related API calls from completing successfully. As a result, login attempts and certain backend service calls failed. Contributing Factors * Non-Standard Port Dependency - Certain APAC services relied on communication through a non-standard gateway port, which introduced additional complexity and region-specific failure conditions. * Regional Gateway Configuration Differences - Gateway routing behavior and configurations differed slightly across regions, making the issue isolated to APAC and increasing diagnostic complexity. * Gateway-Only Failure Condition - The issue occurred only when requests were routed through the API gateway, while direct service communication remained healthy, which initially complicated root cause isolation. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Gateway Configuration Updates - Updated API gateway routing and mapping configurations within the APAC environment. * Endpoint Migration to Standard HTTPS - Migrated affected services from the non-standard port configuration to standard HTTPS communication over the designated port . * End-to-End Service Validation - Performed validation of authentication flows and dependent API services to ensure normal operation following configuration changes. * Post-Deployment Stability Monitoring - Monitored system behavior and login activity to confirm platform stability after the remediation was deployed. ‌ **Future Preventative Measures** ‌ * Regional Configuration Standardization - Standardize API gateway routing and service communication patterns across all regions. * Reduction of Non-Standard Port Usage - Review and eliminate dependencies on non-standard service communication ports where possible. * Improved Gateway Observability - Enhance monitoring and alerting for gateway-level handshake failures and routing issues. * Post-Incident Retrospective Review - Conduct a retrospective review of the incident to identify additional improvements in platform reliability and operational processes.

Read the full incident report →

Started Feb 20, 2026, 04:59 PM UTC· resolved Feb 24, 2026, 01:44 PM UTC

1. identified Feb 20, 2026, 04:59 PM UTC

   Incident Description: We are currently investigating an issue in Flexera One impacting capability updates . The issue affects a subset of our customers across all regions intermittently. Affected customers may observe missing Dashboards in the Flexera One UI. Customers whose capabilities are active and not expired are not affected. Priority: P2 Restoration Activity: Our teams are actively investigating the issue, which has been identified as a defect. Our technical teams are actively working toward implementing a permanent resolution. A temporary workaround is available. Where necessary, our teams can manually apply corrections in the backend. For urgent requests, please raise an SQ (Service Request), and our support teams will prioritize assistance accordingly. We will continue to provide updates as more information becomes available.

2. identified Feb 21, 2026, 07:23 AM UTC

   Our technical teams are progressing toward a permanent fix. Given the complexity of the defect, full resolution may take additional time. We will share further updates as progress continues. A temporary workaround is in place, with backend corrections applied manually where required.

3. identified Feb 23, 2026, 09:23 AM UTC

   We are continuing to work on restoring full health to the capability update process. Our immediate priority was to stabilize customers known to be impacted. This was achieved by manually correcting configurations to return those environments to a healthy state. While our teams continue to make steady progress towards a more permanent solution, the automated onboarding process remains partially impacted. We appreciate your patience and will provide further updates as progress continues.

4. identified Feb 24, 2026, 12:37 AM UTC

   We continue investigating this issue and are implementing a targeted fix. Customers with existing active capabilities are not expected to be impacted. A subset of customers performing capability updates or new organization onboarding may experience intermittent issues, including missing Dashboards within the Flexera One UI. Our technical teams have identified a potential root cause and are currently validating a remediation approach while stabilization efforts continue across environments. Work remains ongoing to restore full reliability of the automated onboarding process. We will provide further updates as progress continues.

5. identified Feb 24, 2026, 07:15 AM UTC

   Onboarding has been fully restored in NAM and APAC, with no known issues at this time. For the EU region, our teams have devised a fix, and deployment and validation activities are currently in progress. Our teams continue to work toward implementing a permanent resolution and will share further updates as progress is made.

6. resolved Feb 24, 2026, 01:44 PM UTC

   Our teams have successfully applied the fix across all regions. Following post-deployment validations, we have confirmed that services have been fully restored and are operating normally.

7. postmortem Mar 10, 2026, 02:01 PM UTC

   **Description:** Flexera One - All regions - Missing Dashboards and Tabular View Reports **Timeframe:** February 20, 2025, 7:02 AM PST to February 20, 2025, 5:30 AM PST ‌ **Incident Summary** On February 19, 2026, at 7:02 AM PST, our teams identified an issue impacting capability provisioning and onboarding workflows within Flexera One.The issue affected a subset of customers across multiple regions and resulted in intermittent failures during capability updates and new organization creation initiated through Salesforce order management processes. As a result, impacted customers would experience missing dashboards or unavailable functionality in the Flexera One interface. The issue affected only a subset of customers whose capabilities were being created or updated during the incident window. Customers with already active capabilities were not impacted. During the investigation, technical teams identified a defect within an internal onboarding component responsible for processing capability updates. A code fix addressing this issue was deployed across regions on February 23, 2026, which resolved the issue for North America and APAC environments. Following this deployment, onboarding workflows in the EU region continued to experience intermittent failures. Further analysis revealed a separate, region-specific infrastructure issue in the EU environment that was preventing certain provisioning workflows from completing successfully. Our technical teams implemented a configuration change to restore service connectivity in the EU environment. After deployment of this fix and completion of validation testing, services were confirmed to be operating normally across all regions. During the incident, Flexera teams also performed manual backend remediation for affected customers requiring urgent capability updates to restore access while permanent fixes were being implemented. All regions were confirmed healthy following completion of remediation and validation activities. ‌ **Root Cause** Root Cause #1 – Defect in Capability Provisioning Logic \(All Regions\) A defect in an internal backend component responsible for processing capability provisioning caused intermittent failures during onboarding and capability update workflows. The issue affected a service responsible for managing capability state updates triggered by Salesforce order events. When this defect was encountered, the provisioning workflow could fail before completing the capability update process, resulting in missing dashboards or inaccessible features for affected organizations. Root Cause #2 – Network Connectivity Issue in EU Environment \(EU Region Only\) A separate infrastructure issue existed within the EU environment where an IAM service cluster was unable to establish reliable connectivity with an internal audit service cluster. The communication path relied on a service configuration that experienced network communication errors. This prevented certain capability provisioning workflows from completing successfully within the EU region even after the initial code fix was deployed. Contributing Factors: * The failures were intermittent, making the issue difficult to reproduce during early investigation. * Two independent issues occurred simultaneously, which extended the investigation timeline. * The EU infrastructure issue masked the effectiveness of the initial code fix until further regional validation was performed. ‌ **Remediation Actions** Following actions were taken to restore the service to normalcy: * Code Fix Deployment: Corrected the defect in the capability provisioning logic used during onboarding workflows. * Infrastructure Configuration Update: Restored internal service connectivity in the EU environment. * Customer Remediation: Performed manual backend capability corrections for impacted customers requiring urgent access. * Service Validation: Conducted cross-region testing to verify onboarding and capability provisioning were functioning normally. ‌ **Future Preventative Measures** To help prevent similar issues in the future, our teams are working on the following improvements: * Improved Capability Provisioning Validation: Introduce automated checks to detect provisioning failures earlier. * Enhanced Monitoring and Alerting: Expand monitoring coverage for onboarding and capability lifecycle workflows. * Infrastructure Connectivity Monitoring: Implement additional alerts for regional service communication failures. * Expand Testing: Increase automated testing coverage for capability lifecycle and onboarding workflows.

Read the full incident report →

Started Feb 19, 2026, 06:08 PM UTC· resolved Feb 19, 2026, 08:57 PM UTC

1. investigating Feb 19, 2026, 06:08 PM UTC

   Incident Description: We are investigating an issue affecting access to Custom Reports within IT Visibility in the NAM region. Customers may experience errors when attempting to access Custom Reports. At this time: • Out-of-the-box reports remain available • EU and APAC regions are not impacted • The issue is isolated to Custom Reports functionality Priority: P2 Restoration Activity: Our technical teams are actively investigating to determine the scope and root cause. We will provide further updates as more information becomes available.

2. identified Feb 19, 2026, 07:07 PM UTC

   Our investigation has identified a behavior affecting access controls for Custom Reports in the NAM region. This condition is preventing reports from loading for certain organizations. We are actively testing a targeted adjustment to validate the behavior and are working toward resolution. We will provide another update once validation is complete.

3. identified Feb 19, 2026, 07:27 PM UTC

   Our investigation has identified the cause of the issue impacting Custom Reports in the NAM region. The behavior is related to how report access is being evaluated for certain organizations. We have validated a corrective action and are working to implement a broader resolution. We will provide another update once the permanent fix is confirmed.

4. resolved Feb 19, 2026, 08:57 PM UTC

   The issue impacting access to Custom Reports within IT Visibility in the NAM region has been resolved. A corrective update has been deployed, and validation confirms that reports are loading as expected. We will continue to monitor the environment to ensure stability. A formal post-mortem report outlining the detailed root cause, corrective actions, and future preventative measures will be published in the coming days.

5. postmortem Mar 06, 2026, 05:32 AM UTC

   **Description:** Flexera One – IT Visibility – NAM – Custom Reports Access Issue **Timeframe:** February 19, 2026, 9:00 AM PST to February 19, 2026, 12:30 PM PST ‌ **Incident Summary** On Thursday, February 19, 2026, at 9:00 AM PST, we identified an issue affecting customers in the NAM region who encountered errors when accessing Custom Reports within IT Visibility. Impacted users were unable to load Custom Reports through the application interface, while out-of-the-box reports remained available and customers in the EU and APAC regions were not affected. Investigation confirmed that backend services were operating normally, isolating the problem to loading the Custom Reports page. The issue was traced to application capability validation logic combined with an unexpected expiration of a capability associated with the reporting feature due to a defect. When the application evaluated this state, the validation logic incorrectly blocked the Custom Reports interface from loading. To restore functionality, the affected capability state was corrected and a fix was implemented to adjust the UI capability validation logic, ensuring the Custom Reports page could load correctly for entitled organizations. The change was deployed to production and validated across impacted organizations. After deployment, Custom Reports loaded successfully and affected customers confirmed that functionality was restored. The issue was fully resolved at 12:30 PM PST after post-deployment validation and monitoring confirmed that normal operation had been restored. ‌ ‌ **Root Cause** During the investigation, our engineering teams determined that the incident was caused by an unexpected capability expiration resulting from a defect in an internal automation process responsible for managing organization capability states. Due to this defect, a reporting-related capability was incorrectly marked as expired for certain organizations. When users attempted to access Custom Reports, the application evaluated the organization’s capability state during page initialization. Because the capability appeared expired, the page-level validation logic incorrectly prevented the Custom Reports interface from loading, resulting in the errors experienced by customers. Contributing Factors * Automation Defect: A bug in the internal process incorrectly updated the capability state for certain organizations. * Page-Level Validation Behavior: The validation logic did not correctly handle certain organization configuration conditions during access evaluation. * Handling of Validation Outcome: When the condition was triggered, the application blocked the page from loading rather than allowing the interface to render . ‌ **Remediation Actions** • Investigation and Pattern Identification: Our technical teams analyzed impacted organizations and identified the configuration pattern triggering the access issue. • Validation Testing: Targeted testing on affected organizations confirmed that adjusting the configuration restored access to Custom Reports and helped isolate the root cause. • Configuration Update: A corrective update was implemented to adjust how page-level validation is performed when loading Custom Reports. • Production Deployment and Verification: The update was deployed to production and validated across impacted organizations to confirm successful report access. • Customer Confirmation: Confirmation was received from the impacted customers that Custom Reports functionality had been restored. ‌ **Future Preventative Measures** • Capability Validation Review: Perform a comprehensive review of checks to ensure they produce consistent, predictable behavior across the application. • Configuration State Handling Improvements: Refine how organization configuration states are handled during access validation to avoid unintentionally blocking user interface pages. • Monitoring and Safeguards: Identify and implement additional measures to detect and prevent similar validation issues going forward. · Defect Investigation: Conduct a detailed RCA to identify and fix the root cause for the defect.

Read the full incident report →

Started Jan 14, 2026, 11:42 AM UTC· resolved Jan 14, 2026, 02:04 PM UTC

1. identified Jan 14, 2026, 11:42 AM UTC

   Incident Description: We have identified a service disruption impacting Flexera One IT Visibility (ITV) in the EU region. Customers may experience issues accessing certain reports, with report outputs appearing as blank. Priority: P2 Restoration Activity: Technical teams are actively investigating the issue and working to restore full reporting functionality. A probable root cause has been identified, and efforts are underway to implement and release a fix. The situation is being closely monitored, and additional updates will be shared as more information becomes available.

2. resolved Jan 14, 2026, 02:04 PM UTC

   The update has been successfully rolled out to all affected organizations, and report visibility has been confirmed as restored. The issue is now fully resolved.

3. postmortem Jan 28, 2026, 12:34 PM UTC

   **Description:** Flexera One – IT Visibility - EU – Reports Displaying as Blank **Timeframe:** 14 January 2026, 12:00 AM PST to 14 January 2026, 05:30 AM PST ‌ **Incident Summary** On Wednesday, 14 January 2026, at 12:00 AM PST, monitoring alerts and customer reports identified an issue impacting IT Visibility \(ITV\) Power BI reports in the EU region, where reports were loading without any data. While customers were able to access the Power BI reporting interface, both current and historical data appeared blank, resulting in a temporary loss of reporting visibility. Upon identification, technical teams promptly initiated an investigation and determined that the issue occurred during a scheduled system update. During this activity, the reporting platform experienced temporary resource constraints, which prevented report data refresh processes from completing successfully. As a result, reports were displayed without data until the refresh operations could resume and complete. To mitigate customer impact while the investigation was ongoing, manual dataset refreshes were initiated for urgent cases, enabling earlier restoration of reporting visibility for those customers. Once system resource utilization stabilized following the deployment and all remaining refresh processes completed successfully, full reporting functionality was restored for all EU customers by 05:30 PST. ‌ **Root Cause** The incident occurred during an ongoing maintenance that did not require scheduled downtime. During this maintenance activity, the reporting system experienced temporary capacity limitations, which delayed the refresh of report data. Until the refresh processes completed successfully, reports were displayed without data. ‌ **Remediation Actions** * Manual dataset refreshes were performed for urgent customer cases to reduce impact. * System resources stabilized following the maintenance. * Automated dataset refresh processes completed successfully. * ITV report visibility was fully restored for all EU customers. ‌ **Future Preventative Measures** Short-Term Actions: * System capacity adjustments during deployments: Our teams will implement controlled, temporary increases in system capacity during deployment activities to better accommodate short-term load increases. This approach is intended to ensure that report data refresh processes continue to run reliably while updates are being applied. * Improvements to refresh processing behavior: The report data refresh process is being refined to reduce system strain during updates. This includes optimizing how refresh activities are triggered and executed so that data updates are processed more efficiently and do not overwhelm system resources during deployment windows. Long-Term Improvement: * Our teams are working on an enhancement to improve how report data is refreshed during deployments, making the process more dynamic and efficient.

Read the full incident report →

Started Jan 09, 2026, 09:06 AM UTC· resolved Feb 23, 2026, 08:25 PM UTC

1. investigating Jan 09, 2026, 09:06 AM UTC

   Incident Description: We have identified an issue affecting Flexera One IT Asset Management in the APAC, EU and NAM regions. The issue is preventing scheduled reports from being delivered as expected, which may result in customers not receiving automated reports during the impacted period. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and working to restore scheduled report delivery. Initial remediation actions did not resolve the issue. The teams are now working closely with the service provider to further investigate the root cause and implement a permanent fix.

2. investigating Jan 09, 2026, 06:36 PM UTC

   We are continuing to investigate an issue affecting the delivery of scheduled Cognos reports in the EU and NAM regions. While scheduled reports are running as expected, some customers may experience delays or non-delivery of report emails. Our teams are actively working to identify the cause and restore normal email delivery. At this time, there is no impact to accessing reports directly within the application. We will provide further updates as more information becomes available.

3. investigating Jan 09, 2026, 11:05 PM UTC

   We are continuing remediation efforts and have implemented configuration changes as part of the recovery process. Additional follow-up work is currently in progress to restore scheduled report email delivery. Some customers may continue to experience delays or non-delivery of scheduled report emails during this time. We will provide further updates as work continues.

4. investigating Jan 10, 2026, 08:38 AM UTC

   We are diligently pursuing remediation efforts. The configuration changes implemented as part of the recovery process are currently in effect, and we are continuing with additional follow-up actions to resolve the issue impacting scheduled report email delivery. Our teams are actively investigating the root cause and validating the necessary next steps to restore full functionality. We will provide further updates as progress is made.

5. identified Jan 10, 2026, 09:02 PM UTC

   Our teams remain engaged, and the next remediation step is planned following recent configuration changes. Further updates will be shared once the next step has been executed.

6. identified Jan 12, 2026, 07:22 AM UTC

   Our teams applied the suggested configuration changes in the staging environment, but the issue persists. We are actively working with our service provider to continue the investigation and implement further remediation actions.

7. identified Jan 12, 2026, 09:31 PM UTC

   We have observed improvement following recent remediation steps; however, automated scheduled report delivery is not yet fully restored due to a separate execution issue identified during processing. Users can continue to access the application and run reports manually. Further updates will be shared as remediation efforts continue.

8. identified Jan 13, 2026, 07:23 PM UTC

   We continue to work with our service provider as part of the ongoing remediation. Additional diagnostic information has been shared to support further investigation, and follow-up steps are being reviewed. Automated scheduled report delivery is still not fully restored. Users can continue to access the application and run reports manually. We will share further updates as more information becomes available.

9. identified Jan 14, 2026, 06:35 PM UTC

   Recent remediation steps have resolved an issue that was causing scheduled reports to remain stuck in a waiting state. Scheduled reports are now progressing past the queue stage; however, a separate execution-related issue is preventing automated report emails from being delivered successfully. Investigation into this remaining issue is ongoing with the service provider. We will share further updates as progress continues.

10. identified Jan 14, 2026, 11:30 PM UTC

    Additional diagnostic traces and logs have been collected and shared as part of the ongoing investigation with our service provider. Work is continuing to identify and address the remaining issue affecting automated scheduled report delivery.

11. investigating Jan 15, 2026, 08:29 PM UTC

    We continue to work closely with our service provider following additional review and testing. At this time, there is no immediate resolution, and investigation into the remaining issue affecting automated scheduled report delivery is ongoing. Reports remain accessible through the application when run manually. Further updates will be shared as more information becomes available.

12. investigating Jan 16, 2026, 09:46 PM UTC

    Additional review and testing with our service provider are ongoing. In the meantime, reports remain accessible through the application and can be run manually while automated scheduled delivery continues to be investigated. Updates will be shared as meaningful progress or new guidance becomes available.

13. investigating Jan 17, 2026, 12:17 PM UTC

    Our teams remain engaged with our service provider and are progressing through additional review and testing. We will provide updates as soon as there is meaningful progress or new information to share.

14. investigating Jan 19, 2026, 03:58 PM UTC

    Our teams are continuing to work with the service provider as part of the ongoing investigation. Additional diagnostic steps are being performed to support further analysis. We will provide further updates as soon as there is meaningful progress or new information is available.

15. investigating Jan 20, 2026, 07:37 PM UTC

    We are continuing testing and validation and are actively coordinating with our service provider as part of the ongoing investigation. Recent work has helped narrow the investigation to a specific scheduled execution path, and further analysis is underway to determine the appropriate resolution. We recognize the importance of scheduled reporting for customers and appreciate your patience as this investigation continues. Additional updates will be shared once there is a meaningful change or new guidance to communicate.

16. investigating Jan 21, 2026, 07:24 AM UTC

    Our technical teams completed additional configuration testing and restarted the Cognos services in the US production environment. Despite these efforts, access to the reporting portal remains unavailable at this time, and users may be unable to log in to the Cognos portal. A high-priority support case has been raised with the service provider for further investigation. Further updates will be shared as more information becomes available.

17. investigating Jan 21, 2026, 02:15 PM UTC

    Our teams worked closely with the service provider to resolve the accessibility issue. The US PROD environments are now accessible, and our teams have successfully verified access to reports and dashboards.

18. investigating Jan 21, 2026, 05:09 PM UTC

    Following the restoration of access, we continue to work closely with our service provider on the remaining scheduled report execution issue. Earlier remediation and validation efforts helped narrow the investigation to a specific scheduled execution scenario, and further analysis is ongoing to determine the appropriate resolution. The environment is being actively monitored, and any regression will be addressed promptly.

19. investigating Jan 22, 2026, 08:55 PM UTC

    Over the past several days, we have completed multiple rounds of remediation, testing, and validation in coordination with our service provider to address issues affecting scheduled Cognos reports. Initial work resolved an earlier condition where scheduled reports were remaining stuck in a waiting state. Subsequent investigation confirmed that reports and dashboards continue to function correctly when run directly within the application. However, scheduled executions follow a different processing path, and failures are isolated to that scheduled execution flow. Recent testing has focused on validating configuration, execution behavior, and data source resolution during scheduled runs. Additional diagnostic logging and traces have been enabled and reviewed to further narrow the cause, and testing continues based on guidance from the service provider. Access to the reporting portal is available, and the environment is being actively monitored while this investigation progresses. We understand the importance of scheduled reporting and will continue to provide updates as further findings or remediation guidance becomes available.

20. identified Jan 23, 2026, 08:18 PM UTC

    Recent testing in coordination with our service provider has helped identify the underlying cause of the scheduled report delivery issue. As part of this work, a configuration change was applied and validated during controlled testing, resulting in successful scheduled report email delivery. Further testing and validation are currently underway to ensure the fix behaves as expected before broader rollout. We will continue to monitor closely and share updates as this work progresses.

21. identified Jan 24, 2026, 07:18 AM UTC

    Our teams continue to validate the fix and have identified some issues during testing. We are working closely with our service provider tto address these findings and refine the fix and restore the service to normalcy.

22. identified Jan 25, 2026, 11:49 PM UTC

    We continue to monitor the environment closely while working with our service provider on the remaining scheduled report delivery issue. Recent validation efforts have highlighted consistent behavior across test environments, and additional data has been shared with the service provider to support further analysis.

23. identified Jan 26, 2026, 08:26 PM UTC

    Recent testing has helped narrow the issue to the way scheduled reports are processed, which differs from reports run directly within the application. While reports continue to function when run manually, scheduled executions rely on additional system interactions that are not completing successfully. Based on testing across environments and guidance from our service provider, the investigation is currently focused on how email connectivity is handled during scheduled report delivery, rather than the report content or underlying data. Changes applied in controlled environments have produced positive results, and further validation is ongoing before broader rollout. Access to the reporting portal remains available, and teams are actively monitoring the environment and coordinating next steps to ensure a stable resolution.

24. identified Jan 27, 2026, 07:22 AM UTC

    The investigation continues to be focused on the email connectivity mechanism used during scheduled report delivery. Additional testing has helped narrow down the likely root cause, and our teams are actively collaborating with the service provider to identify and implement an appropriate fix. The issue has been escalated with the service provider for prioritized attention. Access to the reporting portal remains available, and our teams continue to closely monitor the environment while coordinating next steps to ensure a stable and sustainable resolution.

25. identified Jan 27, 2026, 09:49 PM UTC

    We are continuing focused testing and validation in coordination with our service provider. Work is underway to apply updated configuration and verify behavior in a controlled manner before proceeding more broadly. Access through the reporting portal remains available, and the environment is being actively monitored while this work continues. Further updates will be shared as progress is confirmed.

26. identified Jan 28, 2026, 05:08 PM UTC

    Our teams are continuing to work on the remediation efforts. Recent testing and analysis are ongoing as part of this work, and updated configuration changes are being reviewed and validated in a controlled manner. Further updates will be shared as progress is confirmed.

27. identified Jan 29, 2026, 07:03 AM UTC

    Our teams continue to work closely with the service provider to investigate the issue and identify a permanent solution. While reports are running successfully when executed on demand, scheduled executions continue to fail. The business impact has been reiterated, as the issue has delayed production propagation and is now past due. The service provider has acknowledged this impact and is treating the issue as critical. Our teams are continuing coordinated testing with the service provider to isolate the underlying root cause and implement a fix. Further updates will be shared as they become available.

28. identified Jan 29, 2026, 09:29 PM UTC

    Our teams have made progress as part of the ongoing remediation work. Recent testing has confirmed that scheduled report delivery is functioning as expected in a controlled test environment after applying updated configuration changes. We are now proceeding with the same approach in additional environments, with focused testing underway to ensure consistent behavior before moving forward more broadly. Reports continue to run successfully when accessed directly through the reporting portal, and access remains available. The environment is being actively monitored as this work continues. Further updates will be shared as progress is confirmed.

29. identified Jan 30, 2026, 08:28 PM UTC

    We are continuing remediation and validation work to address the issue affecting scheduled report delivery. Configuration updates are being applied to ensure a consistent setup across environments, and additional testing is underway as part of this effort. Our teams are actively monitoring results and coordinating next steps while further analysis continues. We will share another update once we have confirmed progress or received additional guidance.

30. identified Feb 02, 2026, 08:48 PM UTC

    Our teams continue to actively work on this issue and remain fully engaged in coordination to deliver a durable, long-term fix. This remains a high-priority focus. Ongoing investigation and testing have helped narrow the issue to the scheduled report execution path, which behaves differently from reports run directly within the application. Reports remain accessible through the portal, and validation work continues to ensure scheduled execution functions consistently across all environments. The environment is being actively monitored as remediation efforts progress, including continued testing and review to confirm stability before broader changes are applied. Further updates will be shared as progress is confirmed.

31. monitoring Feb 04, 2026, 12:32 AM UTC

    Recent remediation and testing efforts have resulted in scheduled reports running successfully across environments, with email notifications being delivered as expected. Our teams continue to monitor the platform closely to ensure this behavior remains consistent. While core scheduled reporting functionality is currently operating as intended, we are maintaining a heightened monitoring state to watch for any recurrence and to complete follow-up analysis with our partners.

32. monitoring Feb 04, 2026, 08:05 PM UTC

    We have observed continued improvement and scheduled report delivery is now working as expected across environments. Some customers may still see intermittent failures when running one-time scheduled reports or background executions. As a mitigation, users may need to renew their credentials so the system can pick up the updated authentication details for scheduled execution. Our teams are actively coordinating with IBM to address this remaining behavior and confirm a long-term fix. We will continue monitoring closely and provide further updates as more information becomes available.

33. monitoring Feb 06, 2026, 12:24 AM UTC

    We continue to work through the remaining scheduled reporting issue and are actively coordinating with our service provider to drive a permanent resolution. At this time, recurring scheduled report delivery is functioning as expected, and reports remain accessible through the portal when run manually. Investigation is still ongoing into a specific execution path affecting “Run Once” and background-style report runs.

34. monitoring Feb 07, 2026, 02:11 AM UTC

    We are continuing focused investigation and testing in coordination with our service provider to address the remaining scheduling behavior. As part of the next troubleshooting phase, additional diagnostic tracing has been enabled and testing is currently in progress to capture deeper execution details for review. These results will be used to support further analysis and drive a long-term resolution. Access through the reporting portal remains available, and the environment continues to be actively monitored. Further updates will be shared as progress is confirmed.

35. monitoring Feb 09, 2026, 08:38 PM UTC

    We are continuing focused testing and validation as part of the ongoing remediation effort. The latest round of tracing and diagnostic testing has been completed, and the results have been shared with our service provider for further review. We are currently awaiting their feedback and next steps based on the findings. Access through the reporting portal remains available, and we will continue to monitor closely and provide further updates as progress is confirmed.

36. monitoring Feb 11, 2026, 01:26 AM UTC

    We are continuing to work closely with our service provider as investigation continues into the remaining report execution behavior. Recent validation confirms that recurring scheduled report delivery and email notifications are functioning as expected. However, additional testing has identified a remaining issue affecting “Run Once” and “Run in Background” report executions, which follow a different batch processing path. Enhanced tracing has been enabled to support deeper analysis, and our teams are actively coordinating with the service provider to identify the underlying cause and implement a long-term resolution. Further updates will be shared as progress is confirmed.

37. monitoring Feb 12, 2026, 12:05 AM UTC

    Scheduled report delivery configured on a recurring schedule has been functioning as expected following recent remediation and validation efforts. The remaining issue is isolated to “Run Once” schedules and “Run in Background” executions, which may fail due to the way credentials are handled during one-time batch processing. As a workaround, customers using “Run Once” or “Run in Background” are advised to create a standard recurring schedule to deliver report output by email or save it to the portal. Investigation into the remaining behavior is ongoing, and further updates will be shared as additional findings become available.

38. monitoring Feb 13, 2026, 07:16 PM UTC

    Our teams continue to work through the remaining scheduled report execution issue and are actively coordinating with the service provider to drive a long-term fix. Recurring scheduled report delivery is functioning as expected. However, certain execution modes such as “Run Once” and “Run in Background” may still fail in some cases. Customers are advised to configure reports using a standard recurring schedule for delivery by email or saving output to the portal as a temporary mitigation.

39. monitoring Feb 17, 2026, 06:09 PM UTC

    We remain actively engaged in ongoing investigation and remediation efforts to address the remaining scheduled report execution issue. Our teams are continuing to coordinate closely with the service provider to validate next steps and drive a long-term resolution. Scheduled reports continue to function through standard recurring schedules, and reports remain accessible through the application. Further updates will be shared as additional findings become available.

40. monitoring Feb 19, 2026, 08:16 PM UTC

    We continue to work closely with the service provider to address the remaining scheduled report execution issue. Based on recent log analysis, the behavior appears to be related to authentication handling during certain one-time report execution scenarios. Additional diagnostic logging is currently being implemented to further isolate the issue. Recurring scheduled reports continue to function as expected. Further updates will be provided as additional findings are confirmed.

41. monitoring Feb 21, 2026, 07:21 AM UTC

    We are actively collaborating with the service provider to resolve the remaining issue impacting scheduled report executions. Recurring scheduled reports are functioning as expected. Additional updates will be shared as new findings are confirmed.

42. resolved Feb 23, 2026, 08:25 PM UTC

    Scheduled reporting functionality has been operating as expected following the remediation actions completed earlier. The original issue for which this incident was opened, recurring scheduled reports not being delivered, has been resolved, and scheduled report execution and email delivery are functioning normally across environments. Our teams continue to work in collaboration with our service provider to review a specific report execution scenario observed when reports are triggered using certain on-demand execution options. This behavior does not impact standard scheduled report delivery or normal interactive report usage. Given that core scheduled reporting services are functioning as intended, this incident will now be marked as Resolved. We will continue to monitor the service closely and incorporate findings from this investigation as part of ongoing long-term platform improvements to help ensure continued reliability.

43. postmortem Mar 10, 2026, 03:28 AM UTC

    **Description:** Flexera One – ITAM – All Regions – Cognos Scheduled Reporting Execution Failure **Timeframe:** January 8, 2026, 1:50 AM PST – February 3, 2026, 3:30 PM PST **Incident Summary** On Tuesday, January 8, 2026, at 1:50 AM PST, Flexera’s technical teams identified an issue affecting recurring scheduled Cognos reports in the EU, North America, and APAC regions. During this period, scheduled reports did not execute as expected, and scheduled report emails were not delivered to recipients. While scheduled delivery was impacted, customers continued to have full access to Cognos. Reports could still be viewed, executed manually, and downloaded directly within the application throughout the incident. Flexera’s technical teams immediately initiated investigation and coordinated closely with the service provider to isolate the failure within the scheduled report execution path. Multiple troubleshooting sessions, log reviews, and validation cycles were conducted across environments to identify the underlying behavior and confirm corrective actions. By Tuesday, February 3, 2026 at approximately 3:30 PM PST, recurring scheduled reports were executing successfully again and email delivery for scheduled reports was confirmed to be functioning as expected across environments. With the original service functionality restored and validated, the incident was considered resolved at that time. **Root Cause** The incident was triggered by a change in the upstream email service that began requiring encrypted Simple Mail Transfer Protocol \(SMTP\) connections using SSL/TLS for outbound email delivery. At the time of the change, the reporting platform was not configured to use encrypted SMTP connections, which prevented scheduled report emails and notification messages from being delivered successfully. After encrypted SMTP connectivity was enabled to restore communication with the email service, an additional condition was identified where existing authentication credentials associated with certain reporting service accounts required renewal before email delivery could resume. Once encrypted SMTP connectivity was configured and authentication credentials were renewed for the affected reporting accounts, scheduled report email delivery resumed normal operation. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Detection and Response Initiated: Our technical teams were notified of the issue and, following internal validation confirming the scheduled reporting failure, our Major Incident response procedures were initiated. 2. Cross-Environment Testing and Validation: Technical teams conducted repeated testing across multiple environments to validate behavior differences between interactive report execution and scheduled report processing. 3. Joint Investigation with Service Provider: Flexera collaborated closely with the service provider through troubleshooting sessions, log analysis, and trace reviews to isolate the failure within the scheduled execution path. 4. Secure Email Configuration Update: Encrypted SMTP connectivity \(SSL/TLS\) was configured to align with the updated requirements of the upstream email service. 5. Corrective Action Implementation: Configuration and execution path adjustments were implemented and validated to restore successful recurring scheduled report execution. 6. Service Restoration Verification: Following remediation, recurring scheduled reports were successfully executed across environments and scheduled report emails were confirmed to be delivered normally. 7. Customer Impact Confirmation: Flexera verified restoration with impacted customers and confirmed that scheduled reporting functionality had returned to expected behavior **Future Preventative Measures** Flexera’s teams responded quickly to identify the issue and worked closely with the service provider to restore scheduled reporting functionality. As part of ongoing improvement efforts, the following actions are being taken to strengthen platform reliability: 1. Problem Management Follow-Up: Additional execution scenarios identified during the investigation, specifically report execution through “Run Once” and “Run in Background,” are being reviewed through standard problem management processes to ensure long-term stability of the reporting platform. 2. Continued Collaboration with Service Provider: Flexera continues to work closely with the service provider to further review execution flows and strengthen reliability of scheduled reporting services. 3. Post-Incident Review: A retrospective review will be conducted to capture lessons learned and identify improvements to detection, escalation, and troubleshooting processes for similar incidents. 4. Platform Reliability Improvements: Findings from this incident will be incorporated into ongoing platform improvement initiatives to support consistent scheduled reporting performance and long-term service resilience.

Read the full incident report →

Started Dec 17, 2025, 05:09 PM UTC· resolved Dec 17, 2025, 05:09 PM UTC

1. resolved Dec 17, 2025, 05:09 PM UTC

   Incident Description: A service outage impacted Flexera One SaaS Manager in the North America region. During the impact window, the application may have been unavailable, affecting access to Managed SaaS Applications. Priority: P1 Impact Start Time: December 17, 2025, 5:16 AM PST Impact End Time: December 17, 2025, 6:48 AM PST Restoration Activity: The disruption was caused by an unexpected backlog of internal processing activity that increased load on the service, resulting in temporary unavailability. Technical teams restored the service and adjusted system capacity to safely process the backlog. The application has been fully restored, and monitoring remains in place to ensure continued stability.

2. postmortem Dec 30, 2025, 10:21 AM UTC

   **Description:** Flexera One – SaaS Manager – NA – Service Disruption **Timeframe:** December 17, 2025, 5:16 AM PST to December 17, 2025, 6:48 AM PST ‌ **Incident Summary** On Wednesday, December 17, 2025, at 5:16 AM PST, our teams detected a service outage affecting Flexera One SaaS Manager in the North America region. During this period, customers may have experienced service unavailability and reduced performance when accessing Managed SaaS Applications. Prior to the outage, the issue had been observed intermittently with low impact, but it later escalated into a complete service disruption. Upon identification of the issue, our technical teams swiftly began investigating the cause. They determined that the outage resulted from a significant backlog of message volume following a previous service disruption. This accumulation placed an excessive load on the SaaS Manager service component and its underlying cloud compute resources, ultimately leading to an unhealthy service state. The issue was resolved after we provisioned additional capacity to handle the accumulated message load. By 6:48 AM PST, full service functionality was restored and confirmed once the capacity stabilized. ‌ **Root Cause** The issue arose from a substantial buildup of messages following an earlier service disruption. This backlog placed a persistent strain on the SaaS Manager service component and its underlying cloud compute resources. As message volume continued to increase, the affected service component became resource-constrained and entered an unhealthy state, ultimately leading to a production outage. The service was unable to recover automatically due to insufficient capacity to process the accumulated workload. ‌ **Remediation Actions** · Our teams scaled the cloud compute capacity to process the accumulated message backlog and restored the impacted SaaS Manager service component. · Verified successful message processing and service health post-restoration. · Confirmed full recovery through monitoring and customer validation. ‌ **Future Preventative Measures** · Auto-Scaling Enablement - Auto-scaling has been enabled for the affected service component to dynamically adjust capacity during sudden increases in message volume. This will allow the service to recover automatically under similar load conditions in the future. · Enhanced Monitoring and Early Detection - Monitoring improvements are being implemented to detect abnormal message accumulation and service degradation earlier. Alert thresholds are being refined to trigger proactive intervention before service health is impacted.

Read the full incident report →

Started Dec 17, 2025, 02:14 PM UTC· resolved Dec 18, 2025, 03:47 AM UTC

1. investigating Dec 17, 2025, 02:14 PM UTC

   Incident Description: We have identified a service disruption impacting Flexera One IT Visibility (ITV) and Cloud License Management (CLM) across all regions. Customers may experience difficulty accessing certain reports at this time. Priority: P2 Restoration Activity: Our technical teams are actively investigating the issue and working to restore reporting availability. Progress is being closely monitored, and further updates will be provided as additional information becomes available.

2. identified Dec 17, 2025, 04:33 PM UTC

   We have identified that this issue is related to a recent change affecting reporting functionality for Flexera One IT Visibility (ITV) and Cloud License Management (CLM). Our teams are actively implementing corrective updates across regions to restore access to reports. Recovery is progressing region by region, and customers may begin to see reports restored as updates complete. We will continue to monitor progress closely and provide further updates as restoration continues.

3. identified Dec 17, 2025, 07:49 PM UTC

   Corrective actions have been implemented for NA and APAC, and reporting functionality is showing signs of recovery in these regions as validation continues. Work is still underway in the EU region, and teams remain actively focused on implementing remaining measures and confirming full restoration. We will continue to monitor closely and provide further updates as recovery progresses.

4. identified Dec 17, 2025, 08:12 PM UTC

   Reporting functionality has been restored for customers in NAM and APAC following completion and validation of recent updates. Work is still ongoing in EU, where reporting access continues to be addressed. Our teams remain actively engaged and focused on completing restoration in EU. We will continue to monitor closely and provide further updates as EU recovery progresses.

5. identified Dec 17, 2025, 10:31 PM UTC

   NAM and APAC remain operational following completion and validation of recent updates. Work is still ongoing in EU due to regional configuration differences. Additional updates are in progress, and validation will resume once those changes complete.

6. resolved Dec 18, 2025, 03:47 AM UTC

   Reporting functionality has been fully restored across all regions, and validation has confirmed stable operation. This issue was related to a recent change affecting reporting, which has now been fully addressed. Our teams have completed the required updates and verified successful recovery.

7. postmortem Jan 06, 2026, 02:01 AM UTC

   **Description:** Flexera One IT Visibility and Cloud License Management – Power BI Reporting Unavailable Across All Regions **Timeframe:** December 17, 2025, 5:54 AM PST – 6:46 PM PST **Incident Summary** On Wednesday, December 17, 2025, at 5:54 AM PST, we received reports of customers experiencing issues accessing out-of-the-box Power BI reports within Flexera One IT Visibility \(ITV\) and Cloud License Management \(CLM\). During this period, affected reports failed to load in production environments, preventing customers from accessing reporting insights. Other ITV and CLM functionality remained accessible during this time. The issue occurred following a production deployment related to reporting updates. As part of this change, multiple components required for report availability were updated. Customer impact was not anticipated at the time of deployment, and the resulting behavior caused reporting to become unavailable across all regions. Technical teams engaged immediately and coordinated recovery efforts across regions. Restoration progressed incrementally as deployment and validation activities completed. North America \(NAM\) and Asia-Pacific \(APAC\) were restored first after consistent successful behavior was confirmed. The Europe \(EU\) region required additional time due to configuration differences and the need to complete remaining deployment and validation steps. By December 17, 2025, at 6:46 PM PST, reporting functionality was fully restored across NAM, APAC, and EU. Post-restoration checks confirmed stable behavior, and no further customer impact was observed. **Root Cause** **Primary Root Cause** The disruption was caused by a production deployment related to Power BI reporting that required multiple components to be updated together for reports to remain available. At the time the deployment was executed, customer impact was not anticipated. As a result, reporting functionality became unavailable across production environments until the required deployment and validation steps were completed. **Contributing Factors** • The deployment involved coordinated updates across several components that needed to be applied together to restore reporting functionality. • Restoration and validation had to be completed carefully and consistently across all regions to avoid introducing further inconsistencies. • Regional configuration differences, particularly in the EU environment, required additional deployment steps and validation, which extended the overall recovery timeline. • A rollback or partial reversion was considered but not pursued, as completing the deployment end to end was assessed to be the safest and most reliable path to full restoration. **Remediation Actions** 1. Coordinated Deployment Completion: The reporting-related deployment was completed across all production regions to ensure consistency and restore report availability. 2. Region-by-Region Restoration and Validation: Reporting functionality was restored incrementally by region. North America and Asia-Pacific were validated first after consistent successful behavior was observed, followed by additional deployment and validation steps in Europe. 3. Functional Verification: Access to out-of-the-box Power BI reports was tested across multiple environments to confirm that reports were loading correctly and behaving as expected. 4. Extended Monitoring and Validation: Following extended monitoring and additional validation activities, full restoration of reporting functionality was confirmed at 6:46 PM PST. **Future Preventative Measures** This incident reinforced the importance of careful coordination when deploying changes that involve multiple dependent components. While customer impact was not anticipated in this case, the experience highlighted opportunities to further strengthen how similar updates are identified, planned, and executed to ensure predictable outcomes for customers. Based on this, the following measures are being applied: 1. Stronger Coordination for Multi-Component Updates: Updates that require front-end, back-end, and reporting components to be deployed together will be more closely coordinated to ensure readiness across regions and reduce the risk of unintended customer impact. 2. Execution Planning and Communication Readiness: Similar changes will continue to be planned with appropriate timing considerations, including execution within defined maintenance windows when applicable, and with communication readiness in place so customer notifications can be issued through StatusPage if impact is identified during planning or execution.

Read the full incident report →

Started Dec 15, 2025, 05:56 PM UTC· resolved Dec 15, 2025, 08:57 PM UTC

1. investigating Dec 15, 2025, 05:56 PM UTC

   Incident Description: We are currently investigating a service degradation affecting the CloudCheckr platform in the Federal region. Customers may experience issues accessing services at this time. Priority: P1 Restoration Activity: Our technical teams are engaged and working to determine the underlying cause and restore normal service. We are monitoring system behavior closely and will provide further updates as restoration work continues.

2. identified Dec 15, 2025, 06:23 PM UTC

   Our teams have confirmed that a core service responsible for managing application operations in the CloudCheckr Federal region is not responding as expected. This is preventing the region from operating normally. We are actively working with our service provider to resolve the issue and move toward restoration. We will provide further updates as they become available.

3. identified Dec 15, 2025, 08:27 PM UTC

   Our teams and our service provider continue to investigate the issue to determine the underlying cause and implement the necessary remediation. Additional diagnostic work is underway to further pinpoint the source of the problem and move toward restoration.

4. resolved Dec 15, 2025, 08:57 PM UTC

   The issue affecting the CloudCheckr Federal region has been resolved. Our teams identified a configuration issue within the service components responsible for managing application operations in this environment. The configuration has been corrected, and the region is now operating normally.

5. postmortem Dec 31, 2025, 03:56 AM UTC

   **Description:** CloudCheckr – Federal Region – Service Outage **Timeframe:** December 15, 2025, 9:00 AM PST – 12:30 PM PST **Incident Summary** On December 15, 2025, at approximately 9:00 AM PST, customers using the CloudCheckr Federal region experienced a service outage that prevented access to the environment. During this period, customers may have experienced unavailability when attempting to access the Federal region. All other CloudCheckr regions remained accessible. Technical teams began investigating the issue and performing diagnostics to determine the underlying cause. The focus was placed on the components responsible for bringing the Federal environment online, and a configuration-related issue was identified that was preventing required services from starting successfully. This blocked the environment from completing its normal startup sequence and resulted in customer-facing unavailability. Once the configuration was corrected, affected services were able to initialize properly, and access to the CloudCheckr Federal region was restored at 12:30 PM PST. The environment was monitored following restoration, and no further disruption was observed. **Root Cause** The outage was caused by a configuration issue in the CloudCheckr Federal environment that prevented required service components from starting successfully after a platform update was applied. Because these components were unable to initialize, the region could not complete its normal startup sequence, resulting in service unavailability for customers in the Federal environment. Once the configuration issue was identified and corrected, the affected services were able to start as expected, access was restored, and the environment returned to normal operation. **Remediation Actions** 1. Issue Isolation: Confirmed impact was limited to the Federal region and all other CloudCheckr environments remained operational. 2. Configuration Correction: A configuration dependency preventing service startup was corrected, allowing the environment to recover. 3. Service Validation: Startup progression and access behavior were validated to confirm that all required components were functioning normally. 4. Post-Restoration Monitoring: The environment was monitored for continued stability after restoration was completed at 12:30 PM PST. **Future Preventative Measures** A full retrospective was completed with the teams involved to review the incident, contributing factors, and the response timeline. While this behavior has not been typical in prior update cycles, the review identified opportunities to improve how similar situations are identified and coordinated in the future. Based on that discussion, the following measures are being considered: 1. Earlier Identification of Startup Issues: The teams are reviewing options to help identify configuration or initialization issues earlier in the startup sequence, with the goal of reducing investigation time if similar behavior occurs again. 2. Clearer Coordination Paths During Update Events: Internal guidance is being reinforced so that, when needed, support channels, including engagement with the service provider, can be leveraged to help support completion of similar updates, along with validation or escalation if issues arise during future update activities. These efforts are intended to support faster identification and more coordinated response efforts if this type of issue were to occur again, with the goal of maintaining reliability for customers using the CloudCheckr Federal environment.

Read the full incident report →

Started Dec 09, 2025, 10:10 PM UTC· resolved Dec 09, 2025, 11:02 PM UTC

1. investigating Dec 09, 2025, 10:10 PM UTC

   Issue Description: We are currently investigating a service degradation affecting the Flexera One platform in the North America region. Customers may experience issues accessing services at this time. Priority: P1 Restoration Activity: Our technical teams have been engaged and are working to identify the underlying cause and determine the scope of impact. Further updates will be shared as the investigation progresses.

2. monitoring Dec 09, 2025, 10:18 PM UTC

   Recent activity within the environment has resulted in improved responsiveness, and some users are now able to log in successfully. We are closely monitoring these improvements and will provide further updates as validation continues.

3. resolved Dec 09, 2025, 11:02 PM UTC

   The issue affecting access to Flexera One services in the North America region has been fully resolved. The platform has remained stable following recovery, and customers should now be able to access services without further interruption. Our investigation identified that a temporary disruption within one of the underlying service components caused requests to fail and led to the error messages some customers experienced. The affected component recovered after additional capacity became available and service responsiveness returned to normal. We are reviewing the factors that contributed to this disruption and will be implementing improvements to help reduce the likelihood of a similar event in the future.

4. postmortem Dec 23, 2025, 06:50 PM UTC

   **Description:** Flexera One – North America – Access Disruption **Timeframe:** December 9, 2025, 1:44 PM PST to December 9, 2025, 2:08 PM PST ‌ **Incident Summary** On Tuesday, December 9, 2025, at 1:44 PM PST, our teams detected an issue affecting a subset of customers in the North America \(NA\) region, which prevented successful access to the Flexera One platform. During the impact window, affected users encountered error pages when attempting to load the application, and certain Identity and Access Management-related calls returned internal server errors. The issue was promptly identified and investigated by the technical teams. The incident was traced to an unexpected surge in traffic that exceeded available capacity, causing multiple services to become overloaded and unresponsive. Our teams increased the capacity to restore the services. The platform returned to normal operation at 2:08 PM PST, and no residual customer impact was observed following recovery. Continued monitoring confirmed sustained platform stability. ‌ **Root Cause** The issue was caused by a failure within a service component that impacted authorization functionality. This failure was triggered by an unexpectedly high surge in traffic at the gateway responsible for managing and routing incoming service requests. The traffic volume exceeded previously observed and planned capacity thresholds, resulting in resource exhaustion at the entry point and a subsequent impact on downstream authentication services. Service functionality was restored automatically once additional infrastructure capacity was provisioned, allowing new instances of the authorization service to be brought online on healthy resources. ‌ **Remediation Actions** · **Issue Identification:** The teams identified elevated traffic as the primary contributor to the service disruption. · **Capacity Increase:** The technical teams ensured that additional capacity was made available to support the affected service. · **Service Recovery:** Confirmed that new instances of the affected service were successfully running on healthy resources. · **Validation of Access:** Validated successful authentication flows and confirmed that customer access to Flexera One was restored. · **Post-Recovery Monitoring:** Continued heightened monitoring during and after restoration to ensure platform stability. ‌ **Future Preventative Measures** ‌ · **Capacity Expansion:** The maximum supported traffic capacity has been permanently increased to a level significantly above the peak load observed during the incident, providing additional headroom to safely accommodate future traffic surges. · **Service Resiliency Enhancements:** Development efforts are already ongoing to improve the resiliency and operational behavior of the service. · **Enhanced Monitoring and Alerting:** Enhance monitoring and alerting for infrastructure availability impacting authentication and access services.

Read the full incident report →

Started Dec 09, 2025, 09:43 AM UTC· resolved Dec 09, 2025, 09:43 AM UTC

1. resolved Dec 09, 2025, 09:43 AM UTC

   Incident Description: Earlier today, our teams detected an issue impacting access to the Web UI for IT Asset Management in the EU region. Affected users may have encountered login error messages when attempting to access the service. Priority: P2 Restoration Activity: The impact lasted approximately 11 minutes before the issue auto-resolved. Our technical teams continue to investigate the underlying cause. Initial findings indicate that all backend services remained fully operational, and the disruption was isolated to the login servers.

2. postmortem Jan 20, 2026, 01:11 PM UTC

   **Description:** Flexera One - ITAM - EU - WebUI Access/Login Issues **Timeframe:** December 9, 2025, 12:57 AM PST to December 9, 2025, 1:08 AM ‌ **Incident Summary** On December 9, 2025, at approximately 12:57 AM, monitoring systems detected a disruption impacting access to the Web UI for IT Asset Management in the EU region. During the incident window, affected users encountered login error messages when attempting to access the service. Initial triage confirmed that the issue was isolated to the login layer, while all downstream and backend services remained fully operational. Further investigation identified repeated failures of liveness and readiness probes associated with the authentication service. These probe failures caused the relevant service components to restart continuously, preventing successful login requests. The disruption lasted approximately 11 minutes and auto-resolved once the restarts stabilized and the services returned to a healthy state. Although the incident self-recovered, our teams continued root cause analysis to understand the underlying load conditions that triggered the probe failures and to prevent recurrence. ‌ **Root Cause** Initial diagnostics indicated issues related Service components supporting authentication repeatedly failed liveness and readiness health checks due to sustained high CPU and load conditions. This resulted in continuous pod restarts, preventing successful login processing during the incident window. **Contributing Factors:** High Load Bursts * A recurring high-load pattern was observed coinciding with alert timestamps. * Load was likely driven by dependent services making frequent calls. Insufficient Resource Buffer * CPU utilization exceeded safe operating thresholds. * Service components continued to crash until load subsided and services stabilized. ‌ **Remediation Actions** · Automatic Recovery - The platform’s self-healing mechanisms resolved the issue without the need for manual intervention. · Service Stabilization - Affected service components stabilized once system load subsided, and restart activity ceased. · Authentication Health Restored - Authentication services returned to a healthy and stable operating state. · Full Service Availability Confirmed - Login functionality was fully restored and verified by 1:08 AM. ‌ **Future Preventative Measures** · Proactive Load & Failure Analysis - Conduct detailed analysis of service logs and metrics to identify recurring load patterns and conditions that lead to health-check probe failures, enabling earlier detection of risk scenarios. · Health Check Optimization - Review and tune liveness and readiness probe configurations, including timeout and threshold values, to ensure services can tolerate short-lived load spikes without unnecessary restarts. · Capacity & Resource Buffer Enhancement - Increase CPU and memory allocations for authentication-related services to provide sufficient headroom during sudden traffic surges and prevent resource exhaustion.

Read the full incident report →

Started Dec 05, 2025, 05:02 AM UTC· resolved Dec 05, 2025, 07:13 AM UTC

1. investigating Dec 05, 2025, 05:02 AM UTC

   Issue Description: We are currently investigating a service degradation affecting the Flexera One platform in the North America region. Customers may experience issues accessing services at this time. Priority: P1 Restoration Activity: Our technical teams have been engaged and are working to identify the affected service and determine the scope of impact. Further updates will be shared as the investigation progresses.

2. monitoring Dec 05, 2025, 05:51 AM UTC

   As part of the restoration efforts, our teams provisioned alternative infrastructure, which has returned services to normal operation. We will continue to investigate the root cause and share further details in a post-mortem report.

3. resolved Dec 05, 2025, 07:13 AM UTC

   After extended monitoring, we have confirmed that the issue has been resolved and services remain stable.

4. postmortem Jan 12, 2026, 11:43 AM UTC

   **Description:** Flexera One- NAM- Login failing **Timeframe:** December 4, 2025, 8:43 PM PST to December 4, 2025, 10:54 PM PST ‌ **Incident Summary** ‌ On Thursday, December 4, 2025, at 8:43 PM PST, the Flexera One platform encountered a service degradation in the North America \(NAM\) region, affecting login functionality. During this period, customers in the NAM region were unable to authenticate or access services, while the EU and APAC regions remained unaffected. Upon detection of the issue, our technical teams promptly launched an investigation and identified that the issue stemmed from an unexpected surge in traffic coupled with a configuration issue that hindered service auto-scaling. To address the situation, the teams provisioned alternative infrastructure and executed recovery actions, successfully restoring service functionality. After conducting extended monitoring to ensure stability, full service was restored and confirmed as stable by 10:54 PM PST. ‌ **Root Cause** After a thorough investigation, our teams have determined that the issue stemmed from a combination of unexpectedly high traffic, inadequate processing capacity, and gaps in the configuration of workload placement controls. During peak load conditions, the system components responsible for managing requests were unable to scale efficiently, resulting in resource exhaustion and subsequent service instability. ‌ **Remediation Actions** To restore service, our teams performed below restorative actions: * Environment Stabilization- Migrated services to a newly provisioned, stable environment * Capacity Enhancement- Increased system capacity to handle elevated traffic levels * Scaling Optimization- Adjusted scaling thresholds to better accommodate demand These actions successfully restored normal platform operations. ‌ **Future Preventative Measures** · **Improved Capacity Planning** - Capacity planning processes are being strengthened to better align with traffic patterns. · **Enhanced Monitoring and Alerting –** Our teams are working to improve monitoring to detect early signs of system pressure. · **Additional Stability Safeguards** - Additional controls are to be implemented to ensure critical services remain stable during traffic surges.

Read the full incident report →

Started Dec 03, 2025, 02:49 PM UTC· resolved Dec 03, 2025, 05:49 PM UTC

1. investigating Dec 03, 2025, 02:49 PM UTC

   Incident Description: We are evaluating reports of intermittent issues when accessing Flexera One in the North America region. Some customers may experience slow or unsuccessful login attempts, while access may continue to work normally for others. Priority: P2 Restoration Activity: Our technical teams are reviewing the behavior and working to determine the scope and underlying cause. Intermittent recovery has been observed, but login attempts may still fail for some users. We will continue to monitor closely and provide further updates as more information becomes available.

2. monitoring Dec 03, 2025, 05:02 PM UTC

   Our teams have completed an initial assessment and confirmed that the intermittent login issues observed earlier were related to an outage on our authentication provider’s side. Our services have been operating as expected, and no changes were required within the Flexera One environment. No further login issues have been observed at this time. However, as the provider-side outage is still ongoing, intermittent timeouts may still be possible. We are monitoring the situation closely and will provide additional updates as more information becomes available.

3. resolved Dec 03, 2025, 05:49 PM UTC

   Our service provider has resolved the outage that was contributing to intermittent login issues in the North America region. Access has been monitored for an extended period and continues to remain stable and functioning normally, with no further login failures or timeouts observed. This incident is now closed.

4. postmortem Dec 16, 2025, 11:10 PM UTC

   **Description:** Flexera One – North America – Intermittent Access/Login Issues **Timeframe:** December 3, 2025, 5:08 AM PST – December 3, 2025, 11:05 AM PST **Incident Summary** On December 3, 2025, at approximately 5:08 AM PST, our teams identified intermittent login behavior affecting the North America region. During this period, some customers may have experienced slow or unsuccessful login attempts, while subsequent retries often succeeded. Other regions were not affected. Internal monitoring showed intermittent timeouts and slowness beginning at around the same time an outage was reported by our external authentication service provider. Their disruption included elevated delays and timeouts within their North America infrastructure. The timing and nature of the behavior observed in Flexera One aligned closely with this provider-side instability. As the provider-side outage progressed, intermittent failures continued for some users, while login attempts succeeded for others. Technical teams confirmed that all Flexera services, including authentication workflows within our environment, were operating normally, and no changes or adjustments were required on our end. Login behavior stabilized as the provider’s outage began to clear. Once the provider confirmed full restoration of service, normal access patterns were observed, and no further issues were reported. The incident was fully resolved on December 3, 2025, at 11:05 AM PST. **Root Cause** The intermittent login behavior in the North America region was the result of instability at our external authentication service provider. During the incident window, the provider experienced elevated delays and timeouts within their North America infrastructure, which affected the completion of some authentication requests. All Flexera services, including authentication workflows, were operating normally during this time, and no adjustments were required on our end. Login behavior normalized once the provider restored their services. **Remediation Actions** 1. Incident Correlation and Assessment: Our teams reviewed authentication workflows and confirmed that all internal services were operating as expected. The intermittent behavior was correlated with the provider’s reported instability during the same time window. 2. Monitoring and Validation: Internal monitoring and health checks were used to track authentication behavior as the provider’s outage progressed and to validate when login attempts began succeeding consistently. 3. Customer Impact Observation: Health checks and internal tests showed that access often succeeded on retry and that the behavior was intermittent. No widespread or sustained login failures were observed. 4. Stability Confirmation and Incident Closure: Once the provider restored their services and authentication behavior remained stable without further issues, the incident was closed. **Future Preventative Measures** Operational Resilience During Provider Disruptions: This incident highlighted the importance of operational resilience during intermittent service provider disruptions. While the observed behavior was intermittent and limited in scope, Flexera’s monitoring systems detected the behavior, and multiple technical teams were mobilized promptly to assess the impact, validate internal service health, and correlate the observed behavior with external factors. These response and investigation practices will continue to be applied to ensure consistent handling of similar provider-side events.

Read the full incident report →

Started Dec 02, 2025, 08:20 PM UTC· resolved Dec 03, 2025, 01:40 AM UTC

1. investigating Dec 02, 2025, 08:20 PM UTC

   Incident Description: We are currently investigating an issue affecting inventory processing for Flexera One IT Asset Management in the NAM, EU, and APAC regions. While the application remains accessible, affected customers may experience delayed or missing inventory updates, and some beacon interfaces may appear as not connected even though uploads have occurred. Usage data continues to process normally at this time. Priority: P2 Restoration Activity: Our technical teams are actively engaged and are investigating a disruption in the flow of inventory data to the IT Asset Management service. Further updates will be provided as we work to identify the cause and restore full processing.

2. identified Dec 02, 2025, 09:14 PM UTC

   Our teams identified a recent change that required rollback. Following this action, data processing has resumed in the APAC and US regions. Processing in the EU region is still being restored, and customers in that region may continue to experience delays in inventory data updates. We are continuing to monitor progress across all regions and will provide further updates as restoration efforts continue.

3. monitoring Dec 02, 2025, 10:08 PM UTC

   Our teams have completed the rollback of the recent change, and data processing has resumed across all regions. Inventory data is now flowing again in APAC, US, and EU. Some customers may still see delayed updates while the remaining backlog is processed, but this is expected to clear as processing continues. We are actively monitoring the service to ensure full restoration and will provide further updates as needed.

4. resolved Dec 03, 2025, 01:40 AM UTC

   Data processing has remained stable across all regions following the rollback of the recent change. After extended monitoring, inventory data is flowing normally and no further issues have been observed. As all processing has returned to expected behavior, this incident is now considered resolved.

5. postmortem Dec 15, 2025, 08:31 PM UTC

   **Description:** Flexera One – IT Asset Management – All Regions – Inventory Processing Delays **Timeframe:** December 2, 2025, 9:00 AM PST – December 2, 2025, 1:20 PM PST **Incident Summary** On December 2, 2025, at 9:00 AM PST, inventory data processing for Flexera One – IT Asset Management \(ITAM\) was disrupted across the North America \(NAM\), Europe \(EU\), and Asia-Pacific \(APAC\) regions. While the ITAM application remained accessible, inventory files stopped being forwarded for processing, causing delays in updated inventory information. In some cases, beacon interfaces appeared disconnected even though beacon uploads had completed. Usage data continued to flow normally, indicating that the issue was isolated to the inventory routing pathway. The disruption began after a change was applied across all three production regions. Inventory files that were sent from beacons were not being forwarded successfully into ITAM, resulting in processing gaps across multiple regions. Internal monitoring and validation confirmed that no inventory files were reaching ITAM for several hours. A rollback of the earlier change was initiated across all production regions. Once the rollbacks were completed, inventory data began forwarding normally into ITAM again. Queued files were automatically sent through and processed, and ingestion behavior stabilized across all regions. The incident was fully resolved on December 2, 2025, at 1:20 PM PST. **Root Cause** The disruption was caused by a recent change deployed across all production regions that inadvertently prevented inventory files from being forwarded into ITAM. As a result, ingestion activity halted across all regions. Usage data continued to be processed because it follows a separate ingestion path that was not affected by this change. Rolling back the change restored normal routing behavior and allowed inventory data to reach ITAM again. **Remediation Actions** 1. Rollback of Recent Change: The change applied earlier in the day was rolled back across all three production regions, restoring the expected forwarding behavior for inventory data. 2. Restored Data Forwarding: Once the rollback was completed, inventory data began flowing normally into ITAM in APAC, NAM, and EU. 3. Backlog Clearance: The backlog created during the disruption was automatically forwarded and processed successfully. 4. Post-Recovery Monitoring: Teams monitored ingestion behavior across all regions to confirm stable processing and ensure no residual delays. **Future Preventative Measures** 1. Strengthened Change Evaluation: The update that led to the interruption is undergoing a targeted review to ensure that future changes affecting inventory data forwarding are validated more rigorously across all production regions before rollout. 2. Improved Monitoring Precision: Monitoring has been enhanced to ensure that any interruptions in inventory forwarding are surfaced more reliably, enabling faster detection and escalation if similar behavior occurs in the future.

Read the full incident report →

Started Nov 29, 2025, 06:25 AM UTC· resolved Dec 02, 2025, 05:16 AM UTC

1. investigating Nov 29, 2025, 06:25 AM UTC

   Incident Description: We are currently investigating an issue affecting inventory uploads for IT Asset Management in the NAM region. The impact is limited to a subset of our customers, and while the platform remains accessible, those affected may experience delays or failures in inventory data processing, along with related error messages. Reconciliation processes may also be impacted for these customers. Priority: P2 Restoration Activity: Our technical teams are actively engaged in investigating the inventory processing delays. Further updates will be provided as we continue to address the issue.

2. investigating Nov 29, 2025, 02:48 PM UTC

   Our teams are reviewing the specific stages involved in inventory processing to pinpoint the source of the delays observed by affected customers in the NAM region. Activity across impacted environments continues to be monitored closely while this analysis is underway. Further updates will be shared as soon as we have additional findings or observable changes in processing behavior.

3. investigating Nov 30, 2025, 01:08 AM UTC

   Our teams are continuing to review the workflow steps involved in inventory processing for customers in the NAM region. Interim measures are being applied to keep affected processing activity moving while deeper analysis continues. Validation work is underway to narrow down where processing behavior is slowing and to confirm the conditions affecting related scheduled activities. Monitoring remains active across the impacted customers as this work progresses.

4. investigating Nov 30, 2025, 10:07 AM UTC

   Our teams remain focused on reviewing the inventory processing workflow for affected NAM customers, working to pinpoint the source of the slowdown and verify conditions impacting scheduled activities and reconciliation. Monitoring continues, and engineering teams are actively collaborating on resolution efforts. We will provide additional updates as new details emerge.

5. investigating Nov 30, 2025, 10:41 PM UTC

   Our teams have identified a storage-related condition as a potential contributing factor and are expanding capacity as part of the ongoing work to address the delays affecting inventory processing. We are monitoring processing activity as this change is applied and will share further updates as we validate its impact.

6. monitoring Dec 01, 2025, 12:33 AM UTC

   Our teams have completed a storage capacity increase and applied additional adjustments to improve processing for the affected customers. Processing activity is now moving through the queue, and we are monitoring progression to confirm that all workflows are running as expected. We will provide another update once validation is complete.

7. monitoring Dec 01, 2025, 05:21 PM UTC

   Processing activity continues to improve following the recent database capacity increase. The remaining delayed inventory tasks are moving through the system, and recovery is progressing as expected. Some customers may notice slower than normal response times in areas that load larger datasets, and this is expected to ease as the remaining processing completes. We are monitoring progress closely and will provide further updates as recovery continues.

8. resolved Dec 02, 2025, 05:16 AM UTC

   After extended monitoring, our teams have confirmed that services are fully restored. Inventory processing has returned to normal, and the backlog has been completely cleared

9. postmortem Dec 16, 2025, 06:38 PM UTC

   **Description:** Flexera One - IT Asset management - NAM - batch processing tasks delays **Timeframe:** November 28, 2025, 9:31 PM PST to December 1, 2025, 9:12 PM PST ‌ **Incident Summary** ‌ On Friday, November 28, 2025, at 9:31 PM PST, our teams identified an issue affecting batch processing tasks for IT Asset Management \(ITAM\) in the NAM region, impacting a subset of our customers. Although the Flexera One platform remained accessible, the affected customers experienced delays and failures in batch processing tasks, along with related error messages. The disruption primarily impacted batch processing tasks, and license reconciliation workflows, resulting in tasks being stuck in an “In Process” state for an extended period. Upon investigation, our teams determined that the root cause was database storage exhaustion in the NA production environment. While clearing stuck jobs provided temporary relief, newly submitted jobs continued to face the same database constraints and failure patterns. To address this, we expanded the database storage capacity and implemented additional measures to clear the backlog and expedite inventory processing. By December 1, 2025, at 9:12 PM PST, all services had returned to normal. The technical teams confirmed that job execution was proceeding without issues, and no new stalls were observed. The incident was officially declared resolved at that time. ‌ **Root Cause** The investigation revealed that the issue stemmed from database storage exhaustion in the North America production environment. A critical internal function, intended to eliminate obsolete data, encountered a failure during execution due to a software bug. Consequently, database operations began to experience primary key conflicts and deadlock situations during inventory and reconciliation processing. These conflicts resulted in tasks repeatedly retrying without making progress, particularly when processing reached the license reconciliation stage. ‌ ‌ **Remediation Actions** · Database Storage Expansion- Expanded database storage capacity in the NA production environment to relieve immediate storage constraints. · Batch Processor Workload Rebalancing- Paused processing on older batch processor instances to allow stalled tasks to clear from the system. · Deployment of New Batch Processor Instances- New batch processor instances were started to take over workload processing. · Active Queue and Processing Monitoring- Actively monitored job queues and processing behavior to confirm forward progress. · Bug tracking- Logged the cleanup-function bug for further investigation and fix development. ‌ **Future Preventative Measures** · Stabilization of Data Cleanup Mechanisms - A permanent fix will be implemented for the identified bug to ensure it operates reliably under high system load or low database storage conditions. · Database Monitoring review - Enhanced monitoring and alerting will be reviewed and implemented for database storage utilization, with clearly defined thresholds and escalation paths. This will enable earlier detection of capacity risks and allow corrective action to be taken before storage exhaustion impacts production workloads.

Read the full incident report →

Started Nov 25, 2025, 04:22 PM UTC· resolved Nov 25, 2025, 08:26 PM UTC

1. investigating Nov 25, 2025, 04:22 PM UTC

   Incident Description: We are investigating an issue impacting inventory data uploads for IT Asset Management (ITAM) in the North America region. Affected customers may experience upload failures, timeouts, or delays as inventory files are not currently reaching the processing service. Priority: P2 Restoration Activity: Our technical teams are actively investigating the cause and working to restore normal upload processing. We are monitoring the environment closely and will continue to share updates as progress is made toward full restoration.

2. monitoring Nov 25, 2025, 05:28 PM UTC

   Our technical team has confirmed that the issue began after last night’s release and was caused by a configuration problem affecting inventory upload processing in the North America region. This configuration has now been corrected, and authentication and inventory data uploads are beginning to flow normally. We are monitoring closely to ensure processing remains stable and that any backlog continues to clear.

3. resolved Nov 25, 2025, 08:26 PM UTC

   Inventory upload processing in the North America region has been fully restored. All services are operating normally, and processing is back to expected levels. This incident is now resolved.

4. postmortem Dec 10, 2025, 03:10 AM UTC

   **Description:** Flexera One – IT Asset Management – NA – Inventory Uploads Not Processing **Timeframe:** November 24, 2025, 9:34 PM PST – November 25, 2025, 9:19 AM PST **Incident Summary** On November 24, 2025, customers in the North America region began experiencing issues with inventory data uploads and beacon communication within Flexera One – IT Asset Management \(ITAM\). Beacons were unable to successfully upload inventory files, and some customers observed repeated retries with errors such as timeouts or “405” responses. The issue began shortly after the nightly release process completed, when internal monitoring detected a sudden drop in incoming inventory files. Customer beacon logs confirmed that uploads were consistently failing. An investigation determined that a configuration setting in the backend service responsible for processing beacon uploads did not match the expected North America production configuration. This misalignment caused authentication requests to fail, resulting in inventory files accumulating on customer beacons instead of reaching the ITAM platform. Once the configuration was corrected, authentication requests began succeeding and inventory data immediately resumed flowing at normal volume. Queued uploads were cleared, and customers confirmed that their beacons were sending data normally. The incident was fully resolved on November 25, 2025, at 9:19 AM PST. **Root Cause** The disruption occurred because the service responsible for processing inventory uploads was configured to use an incorrect database endpoint following a recent update. This prevented the service from validating incoming upload requests, causing customer beacons to receive errors and accumulate pending inventory files. Once the correct configuration was applied, upload processing resumed normally. **Remediation Actions** 1. Corrected Configuration: The backend upload-processing service was updated to use the correct database endpoint for the North America production environment. 2. Restored Upload Processing: Once the correct configuration was applied, authentication succeeded, and inventory uploads immediately resumed. Backlogged files were then received and processed successfully. 3. Validation and Monitoring: Teams verified normal traffic and processing levels across multiple customers and continued monitoring until stable operation was confirmed. **Future Preventative Measures** To prevent recurrence, Flexera is implementing the following improvements: 1. Strengthen Configuration Alignment for Production Environments: The team is updating configuration practices to ensure backend services consistently resolve to the correct production database for the North America region. 2. Introduce a More Reliable Targeting Mechanism for Database Connections: A long-term improvement is being planned to ensure backend services automatically reference the correct database location, even if infrastructure changes occur in the future.

Read the full incident report →

Started Nov 20, 2025, 06:13 PM UTC· resolved Nov 20, 2025, 07:30 PM UTC

1. investigating Nov 20, 2025, 06:13 PM UTC

   Incident Description: We are investigating an issue impacting the IT Visibility GraphQL API across all regions. This is affecting a subset of customers. Affected customers may see 500 “Internal Server Error” responses when running GraphQL queries, integrations, and data extracts. Priority: P2 Restoration Activity: Our technical team has identified the underlying cause and is deploying a fix. We are monitoring closely as we continue to make progress and work toward full restoration. We will continue to provide updates as we make progress.

2. resolved Nov 20, 2025, 07:30 PM UTC

   The fix has been rolled out across APAC, EU, and NAM, and validation is complete. The technical team has confirmed GraphQL queries and related operations, including data extracts, are running successfully, and no further errors are being observed. This incident has been resolved.

3. postmortem Dec 04, 2025, 11:43 AM UTC

   **Description:** Flexera One - IT Visibility - All Regions - GraphQL API Errors **Timeframe:** November 20, 2025 , 6:32 AM PST to November 20, 2025 – 11:19 AM PST ‌ **Incident Summary** ‌ On Thursday, 20 November 2025 at 6:32 AM PST, our technical teams identified an issue impacting the IT Visibility GraphQL API across all regions. A subset of customers encountered failures while executing GraphQL queries, integrations, and data extracts, resulting in 500 “Internal Server Error” responses. During the investigation, our teams identified that prior to a recent production deployment, the GraphQL service had been operating normally. However, shortly after this deployment, telemetry data indicated a spike in error rates, and customers began reporting disruptions in their API-driven workflows. An initial investigation confirmed the issue was prevalent across APAC, EU, and NAM, although the impact was limited to a subset of our customers. The engineering teams swiftly pinpointed the root cause and began deploying a corrective fix. As the deployments progressed region by region, the teams closely monitored GraphQL error rates and validated recovery through telemetry data and customer feedback. By 11:19 AM PST, the fix had been fully implemented, with validation confirming that GraphQL queries, integrations, and data extracts were functioning correctly without any further errors. ‌ **Root Cause** ‌ The incident occurred due to an incomplete update propagation during a production deployment, which resulted in inconsistent data being used for schema generation. The deployment depended on a necessary dataset update that had not been fully promoted to the production environment. Consequently, an outdated field name remained in the dataset, while the application anticipated a newer version of that field. ‌ This discrepancy led to schema generation failures within the GraphQL service, resulting in the 500-level errors experienced by customers. The problem stemmed from a miscommunication that created a misalignment between deployment readiness and data readiness, which caused the GraphQL API to operate with inconsistent schema inputs. ‌ **Remediation Actions** ‌ · **Root Cause Identification** - The technical teams analyzed error patterns and logs, confirming that schema generation was failing due to an outdated field in the dataset. They identified that the dataset update required for the deployment had not been fully promoted. · **Promotion of Required Dataset Update** -Teams promoted the missing dataset update to align the field names with the application schema expectations, resolving the mismatched schema inputs. · **Rollout of Corrective Fix** - A targeted fix was developed and deployed progressively across APAC, EU, and NAM, ensuring minimal disruption. Deployment was monitored in real time to validate error-rate reduction. · **Validation and Customer Confirmation** – Our teams used real-time monitoring to confirm the drop in 500 errors. Customer-facing teams validated recovery by confirming successful GraphQL queries and extract operations with affected customers. · **Extended Monitoring Post-Fix** - Following deployment, all regions were monitored to ensure stability. No further schema generation errors or 500 responses were observed. ‌ **Future Preventative Measures** ‌ * Strengthened Dependency Validation Prior to Deployment – Review and update the SoP documentation to ensure all deployments requiring data or schema updates validate the presence and promotion status of dependent datasets before promotion to production. * Improved Cross-Team Communication - Enhance communication channels and approval workflows between deployment, data, and engineering teams to prevent misaligned go/no-go decisions. * Monitoring review - Review existing monitoring and validation checks to ensure early detection of issues.

Read the full incident report →

Started Nov 18, 2025, 11:03 AM UTC· resolved Nov 18, 2025, 05:03 PM UTC

1. investigating Nov 18, 2025, 11:03 AM UTC

   Incident Description: We are currently investigating an issue impacting inventory processing for IT Asset management in the NAM, APAC & EU regions. While the system remains accessible, the affected customers may experience delays in the ingestion and processing of inventory data and encounter error messages such as "Import Failed: Attempted all retries" Priority: P2 Restoration Activity: Our technical teams are actively engaged in investigating the inventory processing failures. Further updates will be provided as we continue to address the issue.

2. identified Nov 18, 2025, 12:57 PM UTC

   Our teams have traced the issue to a recent deployment and are actively working to roll back the changes to restore normal service.

3. monitoring Nov 18, 2025, 03:08 PM UTC

   Our technical teams have successfully rolled back the recent deployment as a corrective measure. We are already observing successful execution of inventory jobs. We will continue to monitor the services closely to ensure stability and will provide further updates as they become available.

4. monitoring Nov 18, 2025, 03:09 PM UTC

   We are continuing to monitor for any further issues.

5. resolved Nov 18, 2025, 05:03 PM UTC

   Processing has returned to normal, and updated inventory data is now flowing as expected. We monitored the service for an extended period following the restoration and have not observed any further impact. This incident has been resolved.

6. postmortem Dec 03, 2025, 04:30 AM UTC

   **Description:** Flexera One - IT Asset management - NAM , APAC & EU - Import Inventory job failures **Timeframe:** November 18, 2025, 1:54 AM PST to November 18, 2025, 6:56 AM PST ‌ **Incident Summary** ‌ On 18 November 2025 at 01:54 PST, our teams identified an issue affecting inventory ingestion and processing for IT Asset Management customers across the NAM, APAC, and EU regions. Although the system remained accessible, customers experienced delays in inventory ingestion and encountered errors such as “Import Failed: Attempted all retries.” Investigation revealed that FSM FNMS Import Inventory jobs were failing across all environments, preventing successful synchronization of inventory data between FSM and FNMS/ITAM systems. This resulted in customers seeing stale or incomplete asset information. The issue was traced to a recently deployed authentication service image that introduced a change incompatible with the FSM FNMS import inventory job scripts. The new authentication image required an explicit call that was not present in the existing FSM script, causing authentication failures during import operations. As an immediate corrective measure, engineering teams rolled back the authentication service deployment at 05:49 PST. After the rollback, successful inventory job execution resumed, and updated data began appearing in the UI. Extended monitoring confirmed continued stability with no further failures. The issue was declared fully resolved at 06:56 PST. ‌ **Root Cause** The issue was caused by incompatibility introduced by a newly deployed authentication service image. The updated image required an authentication call, which was absent in the existing FSM FNMS import inventory job scripts. This mismatch caused: * Authentication failures across FNMS import job flows, * Failed inventory ingestion and reconcile jobs, and * Halted synchronization between FSM and FNMS/ITAM systems. The incompatibility was not identified during pre-deployment testing, and the validation process did not surface any errors. The teams will further investigate the testing gaps that allowed this issue to go undetected. ‌ **Remediation Actions** · **Issue Confirmation and Impact Assessment** - Teams confirmed widespread import job failures across NAM, APAC, and EU and validated that inventory ingestion and reconcile processes were failing consistently. · **Authentication Service Analysis** - Recent deployments were reviewed, and the new authentication service image was identified as the likely source of failure. Error logs validated authentication call mismatches. · **Deployment Rollback** - At 05:49 PST, teams rolled back to the last stable authentication image, restoring compatibility with FSM FNMS import job scripts. · **Validation of Recovery** - Post-rollback testing showed successful execution of multiple inventory import and reconcile jobs. Updated inventory data became visible in the UI shortly afterward. · **Extended Monitoring** - Teams monitored several processing cycles to ensure system stability and confirmed that no further failures were observed before closing the incident. ‌ **Future Preventative Measures** · Strengthened Pre-Deployment Compatibility Testing - Enhance validation to include FSM FNMS inventory job flows, ensuring authentication service updates are tested end-to-end. · Backward-Compatibility Review – Update existing policies to mandate backward-compatibility checks for shared components, such as authentication services, that support multiple downstream systems. · Post-Deployment Monitoring Improvements - Implement targeted alerts for authentication issues within FSM FNMS import processes to accelerate detection of similar failures.

Read the full incident report →

Started Nov 18, 2025, 06:15 AM UTC· resolved Nov 18, 2025, 06:15 AM UTC

1. resolved Nov 18, 2025, 06:15 AM UTC

   Incident Description: On 17 November at 00:54 AM PST, our teams identified an issue impacting Flexera One in the NAM region. Affected customers were unable to access Flexera One using their credentials. Priority: P1 Restoration Activity: Our teams were immediately engaged and initiated an investigation. The root cause was traced to a recent release that, despite being successfully tested in staging and deployed in other production regions, inadvertently caused a service outage in NAM due to human error. Upon identifying the issue, the team promptly reverted the change to the last known good state, restoring services at 01:33 AM PST. A comprehensive root cause analysis will be conducted, and we will share the post-mortem report once it is available.

2. postmortem Dec 02, 2025, 12:51 PM UTC

   **Description:** Flexera One - Flexera One – NAM– Service degradation **Timeframe:** November 17, 2025, 12:54 AM PST to November 17, 2025, 01:33 AM PST ‌ **Incident Summary** # On 17 November 2025 at 00:54 AM PST, teams identified an issue preventing customers and internal users in the NAM region from accessing Flexera One. Users attempting to log in via SSO were unable to authenticate successfully, resulting in complete access disruption for affected customers. Other regions \(EU and APAC\) remained fully functional. Investigation determined that the outage began immediately following a recent application release deployed in NAM. This release had passed full staging validation and was already operating successfully in EU and APAC. However, although the deployment process completed without errors, the application in NAM began failing as soon as the new build was activated. Teams discovered that the failure was caused by a missing database field required by the new release. As part of the recent change, a new field was introduced in one of the database tables. The database migrations had been completed in EU and APAC, enabling successful deployments in those regions. However, the same migration had not been executed in NAM, resulting in a schema mismatch. When the new application code attempted to read from the missing field, it caused the service in NAM to fail, preventing all login traffic from completing successfully. The deployment was rolled back at 01:33 AM PST on 17 November 2025, after which user access returned to normal. Teams continued monitoring afterward and confirmed no further stability issues. ‌ **Root Cause** A database schema mismatch occurred in the NAM region during the deployment of a recent application release: · The release introduced a new field in one of the database tables, and this change was fully tested in staging and successfully deployed in the EU and APAC regions. · In regions except NAM, the required database migration had been completed, ensuring schema alignment with the new application code. · However, the corresponding migration was not yet executed in NAM, leaving the database schema out of sync with the deployed application. · The deployment process assumed all regions were aligned and proceeded without validating the NAM schema before deployment. · As a result, when the updated application attempted to access the missing database field, the server failed and triggered authentication and SSO access outages for all users in the NAM region. ‌ **Remediation Actions** · **Deployment Rollback** - Teams executed an immediate rollback of the release in the NAM region at 01:33 AM PST, restoring the previous stable version of the application and reestablishing access for both customers and internal users. · **Comprehensive System Validation** - Post-rollback, functional and authentication tests were performed to verify that Flexera One access, SSO workflows, and background services were operating correctly. Extended monitoring confirmed no additional failures. ‌ **Future Preventative Measures** ‌ · Pre-deployment Verification – SoP has been updated to include that teams will explicitly confirm that all required database migrations have been successfully executed in the target region before any deployment. Deployment will not proceed unless the necessary fields and schema changes are verified as present. · Stronger Coordination Between Application and Migration Teams - Communication and confirmation processes will be strengthened to ensure database migrations are fully completed before any release dependent on schema updates is deployed. · Enhanced Deployment Observability - Add monitoring and alerting to detect schema-related errors such as missing field access, invalid column references, or failed queries immediately upon deployment.

Read the full incident report →

Started Nov 15, 2025, 04:30 PM UTC· resolved Nov 18, 2025, 06:01 AM UTC

1. investigating Nov 15, 2025, 04:30 PM UTC

   Incident Description: We are currently investigating an issue affecting access to the Snow Software portal (https://www.snowsoftware.io/). Customers may experience the portal not loading as expected or becoming stuck on the sign-in screen. Priority: P1 Restoration Activity: Our teams are actively investigating and working to identify the source of the disruption. We will continue to monitor the situation closely and share further updates as more information becomes available.

2. identified Nov 15, 2025, 05:32 PM UTC

   Our teams have confirmed that a recent change is linked to the access issue affecting the Snow Software portal. An update is currently being deployed to address this. Once the deployment completes, we will revalidate portal access and continue to monitor the situation closely. We will provide the next update as soon as more information becomes available.

3. monitoring Nov 15, 2025, 05:59 PM UTC

   Access to the Snow Software portal has been restored. Our teams have reverted to the last successful deployment state and confirmed that the portal is now loading as expected. Some users may need to refresh their browser or clear cached data if they attempted to access the portal during the disruption.

4. monitoring Nov 15, 2025, 06:33 PM UTC

   Access to the Snow Software portal has been restored. Our teams reverted to the last known good deployment state and have confirmed that the portal is now loading as expected. Some users may need to refresh their browser or clear cached data if they attempted to access the portal during the disruption. We have monitored the service for an extended period to ensure continued stability and have completed all validations. This incident is now resolved.

5. resolved Nov 18, 2025, 06:01 AM UTC

   This incident has been resolved.

6. postmortem Dec 01, 2025, 04:32 PM UTC

   **Description:** Snow Software - All Regions - Portal Unavailable **Timeframe:** November 15, 2025, 1:08 AM PST to November 15, 2025, 9:49 AM PST ‌ **Incident Summary** # On 15 November 2025 at 1:08 AM PST, our teams detected an issue that rendered the Snow Software portal inaccessible for users attempting to log in via [www.snowsoftware.io](http://www.snowsoftware.io/). Users experienced a prolonged "signing in" screen, preventing them from completing authentication and accessing the application. Throughout this incident, all internal service components and the underlying cluster were reported as healthy. However, the public endpoint failed to respond correctly, leading to a functional outage for users, even though back-end systems appeared to be operating normally. The investigation quickly pinpointed a deployment on 14th November 2025 , which included changes aimed at resolving a pipeline issue. As a restorative measure, the change was reverted, and the environment was restored to the last successful deployment state. Following this rollback, the Snow Software portal became accessible again, and the sign-in process returned to normal by 9:49 AM PST. ‌ **Root Cause** The issue was triggered by a deployment change introduced recently, which was intended to fix a pipeline issue. The update resulted in an incorrect routing configuration, causing authentication requests to stall during sign-in despite application components being healthy. Rolling back to the previous stable deployment reversed the misconfiguration and restored normal portal access. ‌ **Remediation Actions** · **Incident Verification & Initial Diagnosis** - Confirmed user login failures and validated that the Snow cluster and service components were healthy. Determined that the issue was isolated to endpoint responsiveness. Mapped the impact timeline to a deployment the previous day. · **Rollback Execution** - Performed a controlled rollback to the last known stable deployment. Reverted the change and associated configuration to restore expected endpoint routing. · **Functional Validation & Portal Restoration** - Executed sign-in tests and monitored endpoint response to ensure authentication completed post-rollback successfully. Confirmed user access recovery across environments. · **User Cache Advisory & Access Normalization** - Identified that cached browser state could prevent immediate recovery for some users. Guided to refresh/clear the cache to ensure the updated routing was recognized. ‌ **Future Preventative Measures** · Strengthened Endpoint Health Monitoring – Review the alerts and checks targeting [www.snowsoftware.io](http://www.snowsoftware.io) to ensure reachability issues are detected faster and prioritized. · Formal Post-Incident Retrospective - Conduct a retrospective focusing on deployment risk, detection latency, and routing behavior.

Read the full incident report →

Started Nov 15, 2025, 08:04 AM UTC· resolved Nov 15, 2025, 08:28 AM UTC

1. investigating Nov 15, 2025, 08:04 AM UTC

   Incident Description: We are investigating an issue impacting beacon connectivity in the North America region. The affected customers may experience errors when attempting to upload or download data through beacon endpoints, including messages indicating “502 error (Bad Gateway).” Priority: P2 Restoration Activity: Our teams are actively investigating reports of connection failures. Initial findings indicate that certain beacon endpoints are returning errors when processing requests. Technical teams are reviewing routing and endpoint configurations to identify the cause and restore normal operation.

2. resolved Nov 15, 2025, 08:28 AM UTC

   Our teams identified that the issue was caused by a recent configuration change and successfully deployed a fix. All related errors have cleared, and services have been restored to normal operation.

3. postmortem Dec 01, 2025, 08:35 PM UTC

   **Description:** Flexera One – IT Asset Management – North America – Beacon Communication Errors **Timeframe:** November 14, 2025, 10:40 PM PST – November 15, 2025, 12:05 AM PST **Incident Summary** On November 14, 2025, starting at 10:40 PM PST, customers in the North America region may have experienced issues when attempting to upload or download data through their IT Asset Management \(ITAM\) beacons. The disruption resulted in “502 Bad Gateway” errors when beacons attempted to communicate with the beacon endpoint. Inventory data uploads continued to function, but adapters, policies, and other configuration downloads were impacted. The issue was identified shortly after it began and was traced to a configuration change introduced during a recent update. The change was intended for a later software version and was not compatible with the current production release. This caused newly scaled backend service instances to start in an incomplete configuration state, preventing them from successfully serving beacon requests. A correction was deployed to adjust the configuration logic for the current production version. Once applied, beacon communication was restored, and backend services resumed normal operation. Full recovery was confirmed at 12:05 AM PST. **Root Cause** The disruption occurred because a configuration change associated with an upcoming software version was unintentionally applied in the production environment, which is running an earlier release. This caused new backend service instances to initialize without required configuration components, resulting in failed responses to beacon download and communication requests. Once the correct version-specific configuration logic was applied, all beacon endpoint services returned to normal function. **Remediation Actions** 1. Configuration Correction Applied: The configuration logic was updated to ensure that only applicable steps execute for the current production release. 2. Beacon Endpoint Services Restored: All backend service instances were corrected and returned to a healthy operational state. 3. Traffic Recovery Confirmed: Beacon connectivity was fully restored, with “502 Bad Gateway” errors no longer observed. 4. Validation Performed: Post-restoration validation confirmed that upload and download operations were functioning as expected. **Future Preventative Measures** To prevent recurrence, Flexera is implementing the following improvements: • Strengthening version-specific safeguards for configuration changes to ensure new components or logic do not apply prematurely in production. • Enhancing validation steps during deployment to confirm all backend service instances start in a fully healthy configuration state.

Read the full incident report →