Flexera incident

Flexera One IT Asset Management - App Portal Errors and API Request Failures

Resolved after 2 days 17 hours, affecting IT Asset Management - US Restful APIs and IT Asset Management - APAC Restful APIs and 1 more, on September 25, 2026.

postmortem Oct 08, 2026, 11:25 AM UTC

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

Started
Sep 25, 2026, 11:18 PM UTC
Resolved
Sep 28, 2026, 05:14 PM UTC
Duration
2d 17h
Detected by Pingoru
Sep 25, 2026, 11:18 PM UTC

Affected components

IT Asset Management - US Restful APIsIT Asset Management - APAC Restful APIsIT Asset Management - EU Restful APIs

Update timeline

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

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

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

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

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

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

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

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

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

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

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

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

Your product runs on more than Flexera

Add the vendors you depend on and get one message when any of them reports trouble. Free for 3 vendors, no card.

Add your stack →