Is Flexera down?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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