Latency on Reporting 2.0 - UK SL2 swimlane

Update timeline

1. investigating Oct 06, 2026, 01:13 PM UTC

   The UK SL2 swim lane is experiencing latency issues around Reporting 2.0. Clients with portals in this swim lane may experience delays or issues accessing Analytics reports in the application. This is our top priority and we are working to resolve the problem as soon as possible. Please check back periodically for additional updates, which will be posted as they become available.

2. monitoring Oct 06, 2026, 01:47 PM UTC

   We have implemented a fix, and the latency has been resolved. We are closely monitoring the environment to ensure performance remains stable and the issue does not recur.

3. investigating Oct 06, 2026, 02:44 PM UTC

   It appears the issue has resurfaced, and CSOD technical teams are working to resolve it with top priority. More information will be shared as it becomes available.

4. monitoring Oct 06, 2026, 04:30 PM UTC

   Engineering has implemented an additional solution. Reporting functionality has returned to normal operations following the change. We will keep the status of this issue in Monitoring for a couple of hours to ensure there isn't a reoccurrence.

5. resolved Oct 06, 2026, 06:48 PM UTC

   After a period of monitoring with no recurrence of the issue, we consider this incident resolved.

6. postmortem Oct 20, 2026, 07:30 AM UTC

   **Root Cause Analysis** **Incident Summary:** On October 6th, 2026, High CPU utilization was observed in the UK SL2 Production environment, resulting in significant performance degradation in Reporting 2.0 and Dashboards. **Impact:** Users experienced delays in loading and refreshing dashboards, slower report generation, and intermittent failures when exporting reports to Excel. Performance degradation was observed during the incident until mitigation measures were applied. **Root Cause:** The incident was caused by high database resource utilization due to multiple resource-intensive analytics and reporting operations running concurrently. This placed significant pressure on available memory and processing capacity, affecting overall database performance. Additionally, Reporting 2.0 throttling capacity had been reduced the previous night, limiting the system's ability to handle concurrent reporting requests. The combined impact contributed to high CPU utilization and prolonged response times. **Resolution:** The DBA team applied corrective measures to address the database performance spikes. Reporting 2.0 throttling capacity was restored to its previous level. Following these actions, dashboard refresh times improved to expected levels. **Preventive Measures:** * Review database performance and resource utilization during periods of high concurrent workload * Review Reporting 2.0 throttling capacity changes to ensure sufficient capacity is maintained for expected demand