Flexera One - IT Asset Management - NAM - Intermittent 500 errors

Update timeline

1. resolved Apr 14, 2026, 12:15 PM UTC

   Incident Description: Our teams previously identified an issue impacting the IT Asset Management service in the NAM region, affecting a subset of customers. The issue began on April 12 and was fully resolved on April 13 at 2:21 AM PDT. While the platform remained accessible throughout, some customers experienced intermittent failures when their beacons attempted to communicate with the Flexera One platform. During this time, certain requests returned internal server errors. As a result, impacted customers may have encountered delays or failures in data retrieval processes that rely on beacon connectivity. Priority: P3 Restoration Activity: Our teams identified the underlying cause of the intermittent internal server errors as a resource constraint on a server. Corrective actions were implemented to restore system stability and ensure adequate capacity. Following these actions, beacon communications returned to normal operation. The platform continues to be closely monitored to confirm sustained stability, and additional safeguards are being evaluated to reduce the recurence of similar issues in the future.

2. postmortem May 12, 2026, 09:16 AM UTC

   **Description:** Flexera One - IT Asset Management - NAM - Intermittent 500 error **Timeframe:** April 13, 2026, 1:46 AM PST to Apr 13, 2026, 2:27 AM PST ‌ **Incident Summary** ‌ On Monday, April 13, 2026, at 1:46 AM PST , our teams identified an issue affecting beacon communications for a subset of customers in the NAM region. During the incident window, customers may have experienced intermittent failures when communicating with the Flexera One platform through beacon services, including inventory uploads, downloads, and data import operations. Affected requests returned HTTP 500 \(Internal Server Error\) responses. Our teams also identified that some customers might have experienced the issue intermittently upto a few days before issue detection. The issue was traced to disk space exhaustion on shared storage utilized by the beacon processing infrastructure. Once the available disk capacity was exhausted, the affected services were unable to successfully process beacon-related requests, resulting in intermittent failures. Our technical teams quickly identified the storage exhaustion condition and restored service by expanding disk capacity on the affected infrastructure. Following remediation, beacon communications returned to normal operation and the environment was closely monitored to ensure continued stability. ‌ **Root Cause** ‌ The incident was caused by disk space exhaustion on shared storage used by the beacon processing component. Once the storage became full, beacon processing requests began failing and returning HTTP 500 responses. Contributing Factors * Existing cleanup mechanisms did not fully remove all temporary or residual data generated during processing activities. * Under certain application failure or unexpected processing scenarios, files were retained longer than intended, contributing to accelerated disk utilization growth. * Storage utilization alerts did not trigger as expected due to a recent update introduced on the alerting mechanism. **Remediation Actions** ‌ The following remediation actions were completed during the incident response: * Expanded disk capacity on the affected shared storage infrastructure. * Removed the problematic configuration on the alert notification mechanism to restore alert delivery functionality. * Validated restoration of beacon communications and successful processing of requests. * Monitored the environment following recovery to confirm service stability. ‌ **Future Preventative Measures** ‌ * To reduce the likelihood of recurrence, the following preventative measures are being implemented: * Enhance cleanup and retention mechanisms to ensure all relevant temporary and residual processing files are automatically removed. * Improve storage utilization monitoring and alerting coverage across shared processing infrastructure. * Validate alert delivery configurations after infrastructure changes.