Flexera Status

The issue affecting Snow Atlas in the West Europe region has been resolved, and service is currently operating normally. Our technical teams have mitigated the underlying service instability and continue to monitor closely to ensure sustained stability. We will provide a detailed post-incident report outlining the root cause and preventative measures in the coming days.

This issue has been resolved. Data Explorer functionality in the APAC region has been fully restored following the identification and rollback of a recent service change that was impacting service communication. All services have been validated and are operating as expected. A full post-incident report, including detailed root cause and preventative measures, will be shared in the coming days.

The issue was traced to a recent configuration change that had been implemented to improve service performance. The change has been rolled back, and service functionality has been fully restored. This issue has been resolved. Our teams will continue to monitor the environment to ensure ongoing stability. Additional details, including the root cause analysis and preventative measures, will be shared in a post-mortem report.

**Description:** Snow Atlas – APAC – Login Failures and HTTP 500 Errors **Timeframe:** May 28, 2026, 20:57 PDT to May 29, 2026, 03:32 PDT ‌ **Incident Summary** ‌ On Thursday, May 28, 2026, at 20:57 PDT, an incident was identified impacting a subset of Snow Atlas customers in the APAC production environment. Affected users were unable to access the platform or experienced degraded application functionality. This included HTTP 500 and 404 errors, as well as instances where pages loaded incompletely with no data before ultimately returning service unavailability messages. Technical teams engaged immediately and identified degraded performance within a core routing component responsible for handling traffic. As the issue progressed, backend services were unable to communicate reliably, leading to increased request failures and overall application instability for impacted tenants. Initial mitigation actions, including targeted service restarts, successfully restored access for affected customers. Teams continued to investigate the underlying cause while maintaining enhanced monitoring to validate platform stability. A subsequent controlled restart and recovery of the impacted routing services fully resolved the contention conditions. Following these actions, no further customer impact was observed. The platform remained stable throughout the monitoring period, and the incident was formally resolved after normal service operations were confirmed. ‌ **Root Cause** ‌ The incident was triggered by an automated infrastructure upgrade initiated by the cloud service provider. This upgrade resulted in a sequential restart of infrastructure nodes supporting the Snow Atlas platform, causing a large number of application services to restart within a compressed timeframe. During the recovery phase, a critical routing component responsible for service discovery and request routing became saturated due to the high volume of service registration activity. Consequently, routing information was intermittently unavailable to dependent services, leading to application errors, request failures, and overall service instability for a subset of APAC customers. Contributing Factors: * The provider-initiated infrastructure upgrade was unplanned from an application perspective and triggered a large-scale, simultaneous service restart across the environment. * The routing service had limited redundancy, increasing the potential for service disruption under certain conditions. * During recovery, the temporary unavailability of the routing service prevented dependent services from resolving required routes, resulting in HTTP 404 and HTTP 500 errors across multiple application functions. * Elevated recovery activity, combined with the lack of redundancy, amplified both the impact and duration of the incident. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Technical teams identified the affected routing component and performed targeted recovery actions to restore service. * Service restarts were completed to re-establish routing functionality and stabilize affected platform services. * A controlled restart procedure was executed to ensure clean recovery of the impacted components. * Enhanced monitoring was maintained throughout the recovery process to validate platform stability and detect any recurrence. * Root cause analysis was completed and corrective actions were implemented to address the underlying infrastructure and resiliency gaps. ‌ **Future Preventative Measures** ‌ * Controlled Infrastructure Maintenance - Automatic upgrades have been disabled for the affected environment. Future infrastructure upgrades will be performed through planned maintenance activities with appropriate scheduling, oversight, and validation. * Increased Service Redundancy - The routing service has been scaled up to run multiple replicas across separate infrastructure nodes. * Improved Platform Resiliency - Platform resiliency controls have been reviewed and enhanced to better handle large-scale service restart events and reduce the risk of service discovery or routing bottlenecks during recovery operations. * Enhanced Monitoring and Early Detection - Additional monitoring and alerting have been implemented to provide earlier visibility into service degradation and infrastructure events that could impact platform availability.

**Description:** Flexera One - IT Asset Management - All Regions - Third-Party Inventory Import Issues **Timeframe:** June 4, 2026, 1:45 PM PDT to June 08, 2026, 00:47 PDT ‌ **Incident Summary** ‌ On Thursday, June 4, 2026, at 1:45 PM PDT, our teams identified an issue affecting third-party inventory imports in IT Asset Management caused some inventory uploads to time out, fail, or remain in progress longer than expected. The issue impacted the processing of certain third-party inventory sources and resulted in delays to inventory data availability for affected customers. Investigation determined that, following a recent platform change, a subset of third-party inventory imports encountered issues during the transfer of inventory data into IT Asset Management. The issue was initially identified through a combination of customer reports and internal monitoring. Further investigation confirmed that while inventory data was successfully generated and processed through earlier stages of the workflow, certain uploads failed to complete successfully, resulting in import processing delays and failures. Due to the nature of the response received during these failures, the underlying cause was not immediately apparent, which extended the time required for diagnosis. Technical teams performed a detailed analysis of the processing workflow and identified that certain larger inventory uploads were not being handled as expected under specific conditions. A solution was implemented to improve how these larger data transfers are managed. The corrective update was validated in a controlled environment, followed by comprehensive end‑to‑end testing, and then deployed to production. Following deployment, inventory processing returned to expected behaviour by Jun 06, 2026 , 01:03 PDT. Continued monitoring confirmed stable performance, and no further recurrence of the issue was observed. After extended monitoring, the incident was declared as resolved on Jun 08, 2026 at 00:47 PDT. ‌ **Root Cause** ‌ The issue was caused by limitations encountered during the transfer of larger inventory data sets between platform services following the production change. Under specific conditions, larger inventory uploads were not processed successfully, leading to incomplete or delayed processing. When these uploads failed, the receiving service returned a generic client error response rather than an error specifically indicating a file size limitation. As a result, the sending service interpreted the response as a capability or configuration issue rather than an upload failure, preventing the true cause from being immediately identified. Contributing Factors * The response returned during failure scenarios did not clearly indicate the underlying condition. * This response behaviour initially led to misinterpretation of the failure, extending diagnosis time. * Pre release validation included large data scenarios; however, production conditions introduced additional variability not fully represented during testing. * Platform configuration indicated support for larger data handling, which made the practical limitation difficult to anticipate during design and validation. ‌ **Remediation Actions** ‌ * The processing workflow was analysed to identify the point of failure within the inventory transfer process. * Data transfer behaviour between platform components was reviewed and validated. * A revised approach was implemented to transfer larger data sets in smaller segments. The solution was validated through staging and end to end testing to ensure data integrity and processing completion. * The validated fix was deployed to production environments. * Enhanced monitoring was maintained throughout rollout and validation to confirm successful processing and overall stability. ‌ **Future Preventative Measures** ‌ * Improved Data Transfer Handling - Large inventory data transfers configuration has been updated, improving reliability and reducing dependency on single transaction limits. * Enhanced Error Reporting - Improvements will be made to ensure that system responses more clearly reflect the underlying cause of failures, enabling faster and more accurate diagnosis. * Expanded Validation Scenarios - Additional testing scenarios involving larger and more complex data sets will be incorporated to better reflect real world conditions prior to release. * Stronger Integration Validation - Future changes will include deeper validation of interactions between platform components to identify and mitigate potential constraints earlier. * Monitoring and Detection Enhancements - Monitoring and alerting capabilities will be further enhanced to provide earlier visibility into processing delays or failures, helping to reduce time to detection and resolution.

Our technical team has confirmed that batch processing has recovered and is operating as expected. Earlier delays have been addressed, and queued work is now processing normally. We will keep monitoring the environment to ensure stability, and this incident is now resolved.

**Description:** Snow Atlas - West EU - Service Disruption **Timeframe:** June 3, 2026, 06:33 AM PDT to June 3, 2026, 07:28 AM PDT ‌ **Incident Summary** ‌ On Wednesday, June 3, 2026 at 06:33 AM PDT, customers in the West EU production environment experienced a service disruption that prevented access to Snow Atlas through snowsoftware.io. Affected users were unable to log in to the platform and, in some cases, encountered service availability errors during authentication attempts. Upon investigation, our teams determined that a critical identity and authentication service within the West EU environment became unavailable during infrastructure maintenance activities being performed in a separate region. As a result, authentication requests could not be processed successfully, preventing customers from accessing the platform. Once the issue was identified, the affected service was promptly restored, and normal authentication functionality resumed. Following restoration, technical teams conducted validation activities and continued enhanced monitoring to confirm platform stability and verify that customer access had been fully restored. ‌ **Root Cause** The issue was caused by an operational error during planned maintenance activities. While performing maintenance preparations in a separate production region, an action intended for that environment was inadvertently executed against the West EU environment. This resulted in a critical identity and authentication service being unintentionally scaled down, causing authentication failures and preventing customer access to Snow Atlas. ‌ **Contributing Factors** ‌ * A delay in updating the active management session resulted in commands being executed against the unintended environment. * The affected authentication service represented a critical dependency for customer login and platform access. * Existing monitoring and alerting did not provide timely notification to the responsible engineering team when the authentication service became unavailable, extending the time required to identify and remediate the issue. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * The affected authentication service was restored, re-establishing customer access to the platform. * Technical teams validated service functionality and confirmed successful customer authentication following recovery. * Engineering teams reviewed maintenance procedures and execution logs to identify the sequence of events that led to the incident. * Monitoring was maintained following restoration to verify continued platform stability and service availability. ‌ **Future Preventative Measures** * Enhanced Change Controls - Maintenance procedures will be updated to include additional safeguards and verification steps before executing operational actions across production environments. * Strengthened Monitoring and Alerting - Monitoring and alerting coverage for critical authentication services will be enhanced to ensure responsible teams receive immediate notification of service degradation or outages. * Operational Process Improvements - The lessons learned from this incident have been incorporated into our maintenance and change management practices. These improvements will further strengthen operational controls, reduce the likelihood of similar events, and improve our ability to detect and respond to service disruptions.

**Description:** Snow Atlas - Australia - Service Unavailable **Timeframe:** June 02, 2026, 5:30 AM PDT to June 02, 2026, 9:18 AM PDT ‌ **Incident Summary** ‌ On Tuesday, June 02, 2026, 5:30 AM PDT, A service disruption affected Snow Atlas customers in the Australia region following a scheduled maintenance activity. As part of a planned infrastructure maintenance activity, our teams performed a migration between Australia South East and Australia East. The maintenance was expected to be completed within the scheduled window; however, the activity extended beyond the planned duration due to unexpected delays encountered during execution. Throughout the issue, customers retained access to the Snow Atlas application and were able to view and browse existing data. The impact was limited to data ingestion and data export functionality. New ingestion requests and export requests were queued while maintenance activities remained in progress. During the maintenance execution, technical teams encountered delays related to deployment synchronization activities and infrastructure management tooling, which extended the overall duration of the migration. Once the migration was completed and services were re-enabled, queued ingestion and export requests resumed processing normally by 9:18 AM PDT. ‌ **Root Cause** ‌ The issue was caused by a scheduled infrastructure migration that exceeded its planned maintenance window. The migration required multiple coordinated deployment, configuration, and application management activities, each dependent on successful completion of the previous step. During execution, several deployment and synchronization operations took significantly longer than anticipated based on testing and pre-maintenance validation. These delays extended the maintenance activity beyond the expected timeframe, resulting in a longer-than-planned interruption to data ingestion and export services. Contributing Factors * The migration involved multiple interdependent deployment and configuration changes that required sequential execution. * Deployment synchronization activities experienced intermittent delays and required additional time to complete. * Certain deployment operations required manual intervention when synchronization did not complete as expected. * The duration of these activities was longer than observed during pre-production testing, resulting in an inaccurate estimate of the total maintenance execution time. ‌ **Remediation Actions** ‌ The following remediation steps were implemented to restore service functionality: * Technical teams completed the migration between Australia South East and Australia East. * Deployment and synchronization issues encountered during the migration were investigated and resolved. * Data ingestion services were re-enabled following successful completion of the migration activities. * Queued ingestion and export requests were allowed to process normally once services were restored. * The environment was closely monitored following restoration to verify platform stability and successful processing of queued requests. ‌ **Future Preventative Measures** * Improved Maintenance Planning - Future migration activities will be further segmented where possible to reduce the number of changes performed within a single maintenance window and improve execution predictability. * Enhanced Maintenance Duration Estimation - Maintenance planning processes will be updated to better account for deployment synchronization times, infrastructure dependencies, and potential manual intervention requirements when estimating maintenance windows. * Lessons Learned Review - The maintenance execution process and associated dependencies will be reviewed to identify additional opportunities to streamline migration activities, reduce operational complexity, and minimize the risk of maintenance overruns in future events.

The platform remains stable, and incoming imports are processing within expected timeframes. Any remaining import-related issues are being investigated separately as isolated cases . Based on the successful recovery and sustained platform stability, this incident has now been declared resolved. A post-mortem report containing additional details, including the root cause, remediation activities, and preventative measures, will be shared once the investigation is complete.

**Description:** Flexera One – IT Asset Management and IT Visibility – APAC – Beacon Configuration and Reconfiguration Errors **Timeframe:** June 1, 2026, 7:41 PM PDT – June 2, 2026, 12:58 PM PDT **Incident Summary** On Monday, June 1, 2026, at approximately 7:41 PM PDT, an issue was identified affecting Beacon configuration and reconfiguration workflows in the APAC Production environment for Flexera One IT Asset Management and IT Visibility. During the affected period, customers attempting to access affected Beacon-related pages may have encountered a red bar error or server-side application error. Technical teams investigated the impacted workflows and backend service dependencies. The investigation confirmed that affected requests were returning server-side errors and that the issue was associated with the backend service supporting Beacon-related workflows. The issue was resolved by updating the affected Beacon API service in APAC Production. Following the update, the affected Beacon pages were confirmed accessible again. By Tuesday, June 2, 2026, at approximately 12:58 PM PDT, service was confirmed restored and the incident was considered resolved. **Root Cause** The incident was caused by a compatibility issue between the deployed Beacon API service version in APAC Production and recent IT Asset Management database changes. A required related Beacon API service update was not completed in APAC Production as part of the related release activity, which caused some Beacon configuration and reconfiguration workflows to return backend errors. These backend errors were surfaced in the UI as red bar errors when customers attempted to access affected Beacon-related pages. **Remediation Actions** The following actions were taken during the incident response: * **Impact Assessment:** Technical teams confirmed the issue was affecting Beacon configuration and reconfiguration workflows in APAC Production. * **Backend Error Isolation:** Investigation confirmed that affected requests were returning server-side errors from backend service dependencies. * **Service Compatibility Review:** Technical teams identified a compatibility issue between the deployed Beacon API service version and recent IT Asset Management database changes. * **Corrective Service Update:** The Beacon API service was updated in APAC Production to restore the affected workflows. * **Service Restoration Validation:** Following the update, technical teams validated that the affected Beacon pages were accessible and functioning as expected. **Future Preventative Measures** The following follow-up actions were identified: * **Strengthened Deployment Procedures:** We are strengthening deployment dependency checks and cross-team release coordination to ensure required service updates are clearly identified, tracked, and completed when related database or platform changes are released. * **Regional Version Alignment:** Related Beacon API service updates were completed across additional regions, including EU and NAM, to maintain version consistency and reduce the risk of similar compatibility issues occurring elsewhere. * **Expanded Post-Release Validation:** We are expanding post-release validation for critical Beacon configuration and reconfiguration workflows, especially when backend service or database changes are involved.

Flexera will be performing updates on Flexera One IT Visibility in the NAM region. During this maintenance users may notice unexpected behaviour and errors throughout the Flexera One website: logins, navigation, reports etc. Scheduled Maintenance Window: PDT : June 25 12:00 am - 02:00 am CDT : June 25 02:00 am - 04:00 am CEST: June 25 09:00 am - 11:00 am AEST: June 25 05:00 pm - 07:00 pm UTC : June 25 07:00 am - 09:00 am EDT : June 25 03:00 am - 05:00 am IST : June 25 12:30 pm - 02:30 pm

Maintenance will be performed on Snow Atlas production cluster across Australia-hosted environments as part of the migration activity. Impact: Users may experience temporary unavailability for impacted applications during the migration and application restart activities. Reason: To support migration activities, infrastructure modernization, and platform resiliency improvements. Dates/Times: IST: June 24th, 6:00 PM to 8:00 PM UTC: June 24th, 12:30 PM to 2:30 PM UK Time (BST): June 24th, 1:30 PM to 3:30 PM Sweden Time (CEST): June 24th, 2:30 PM to 4:30 PM AEST: June 24th, 10:00 PM to June 25th, 12:00 AM PDT: June 24, 2026, 5:00 AM → 7:00 AM PDT

Flexera will be performing updates on Flexera One IT Visibility in the EU region. During this maintenance users may notice unexpected behaviour and errors throughout the Flexera One website: logins, navigation, reports etc. Scheduled Maintenance Window: PDT : June 23 09:15 am - 11:15 am CDT : June 23 11:15 am - 01:15 pm CEST: June 23 06:15 pm - 08:15 pm AEST: June 24 02:15 am - 04:15 am UTC : June 23 04:15 pm - 06:15 pm EDT : June 23 12:15 pm - 02:15 pm IST : June 23 09:45 pm - 11:45 pm

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.