Flexera System Status Dashboard Status Page

May 29, 2026 · resolved May 29

Our teams continue to monitor the environment closely. No ongoing customer-facing impact had been reported, and systems remain stable with the current workaround in place. Root cause investigation efforts are still ongoing, and technical teams continue to validate a permanent fix to prevent recurrence. Further updates will be shared via a post-mortem report.

May 27, 2026 · resolved May 27

Following the hotfix deployment, no additional customer reconcile failures have been observed. After an extended monitoring period and validation of platform behavior, the issue is now being declared as resolved.

May 26, 2026 · resolved May 27

Our investigation and mitigation efforts have been completed, and the issue has now been resolved. Services are operating as expected, and impacted functionality has been restored. Our technical teams will continue to closely monitor the platform to ensure ongoing stability and validate continued healthy system behavior.

May 15, 2026 · resolved May 26

Our investigation has been completed, and the issue has now been declared resolved based on current system behavior and validation results. Platform activity and processing have returned to expected levels, and our teams have confirmed stability across the broader environment. Based on current observations and available data, a small number of customers continue to experience isolated processing slowness. These cases appear to be limited in scope and are being tracked separately by the relevant technical teams, who are actively working toward resolution. At this time, no broader impact has been identified, and monitoring activities will continue to ensure ongoing platform stability.

May 11, 2026 · resolved May 15

**Description:** Flexera One- IT Visibility- US Prod - Degraded performance **Timeframe:** May 10, 2026, 8:12 PM PDT to May 14, 2026, 07:25 PM PDT ‌ **Incident Summary** ‌ On Sunday, May 10 , 2026, at 8:12 PM PDT , our teams detected an issue impacting IT Visibility \(ITV\) services in the US region where the affected customers experienced delays in normalized inventory processing and delivery to ITV UIs and APIs. The issue originated within the normalization persistence layer, where the service encountered repeated failures while initializing streaming clients used for communication. During initialization, the service generated a large number of API requests in a short period of time, which exceeded account throttling limits. As a result, the service repeatedly restarted and was unable to consistently process and persist normalized inventory data. Our technical teams identified the contributing factors, implemented mitigation measures, and deployed code improvements designed to reduce API request spikes and improve service resiliency during startup and recovery conditions. Following deployment of the fixes, services stabilized and backlog processing was initiated in a controlled manner to avoid downstream system impact. Recovery progressed steadily, and all backlog processing was successfully completed by May 14, 2026, at 07:25 PM PDT. ‌ **Root Cause** ‌ * The incident was caused by excessive API requests generated during streaming client initialization within the normalization writer service. The request volume exceeded throttling limits, preventing successful initialization and causing the service to repeatedly restart. Contributing Factors: * The production US environment had significantly scaled up, increasing the number of streaming clients initialized during service startup. * Separate streaming clients were created per organization across multiple collections, resulting in unexpectedly high API calls during each pod restart. * Failure handling logic caused the service to terminate immediately instead of retrying gracefully, amplifying restart frequency and additional request spikes. ‌ **Remediation Actions** ‌ The following remediation activities were completed to restore service stability: * Implemented staggered streaming client initialization to reduce API request spikes during service startup. * Added retry logic with exponential backoff around streaming client creation and authentication requests. * Replaced failure handling with graceful recovery and retry mechanisms. * Stabilized normalization services and resumed backlog processing in a controlled manner. * Closely monitored recovery activities to ensure downstream platform stability during backlog replay. ‌ **Future Preventative Measures** * Introduce rate limiting controls for external dependency initialization workflows. * Enhance resiliency standards for service startup and dependency authentication handling. * Improve observability and alerting around throttling conditions. * Review scalability assumptions and startup behavior for high-scale growth scenarios. * Conduct additional resiliency testing focused on restart and dependency throttling conditions.