CompaniesInfluxData (InfluxDB Cloud)Incidents
InfluxData (InfluxDB Cloud): Query performance degradation in Azure West Europe
Affected components: API QueriesCloud Serverless: Azure, W. Europe - API Queries
Timeline of updates
- identified
The issue has been identified and a fix is being implemented.
- identified
We are continuing to work on a fix for this issue.
- identified
We are continuing to work on a fix for this issue.
- identified
We are continuing to work on a fix for this issue.
- monitoring
A fix has been implemented and we are monitoring the results.
- resolved
This incident has been resolved.
- postmortem
# **Root Cause Analysis: Query Latency on September 7, 2026** Region: Azure West Europe Cluster: prod01-eu-west-1 ## **Summary and impact** On September 7, 2026, some customers in Azure West Europe experienced increased query latency. Query success rates and write operations were not affected. Three storage replicas fell behind after increased delete activity coincided with scheduled retention processing. Recovery required staged restarts and changes to compaction and retention processing. Query latency returned to normal at 15:50 UTC, and the incident was resolved at 16:16 UTC. ## **Cause** A sudden burst of delete requests from one organization coincided with a scheduled retention pass on three storage replicas. The combined load exhausted their compaction capacity, causing them to fall behind in processing incoming data. The replicas did not recover on their own after the delete burst stopped. Each retention pass began immediately after the preceding pass finished, leaving no window to clear the backlog. A steady stream of delete requests from a second organization also contributed to the slow recovery. ## **Recovery actions** The team contacted the organization issuing the delete burst, and the burst stopped at 10:10 UTC. The affected replicas were restarted in stages, and compaction was temporarily paused to prioritize clearing the backlog. The retention schedule was also lengthened to give replicas recovery time between passes. Backlogs subsequently decreased across all affected replicas, and query latency returned to normal. ## **Timeline** All times are UTC. Time Event 09:40 - Delete burst began; storage replicas fell behind. 10:01 - Alerts triggered; incident opened. 10:04 - Cause identified; originating organization contacted; status page published. 10:10 - Delete burst stopped. 10:15 - Staged restart of affected replicas began. 11:14 - First replica fully recovered; the other two continued clearing their backlogs. 12:11 - Compaction was paused on the most-affected replica. 14:29 - Retention schedule was lengthened to allow recovery between passes. 15:29 - Backlogs were decreasing on all affected replicas; status page moved to monitoring. 15:50 - Query latency returned to normal. 16:16 - Incident resolved. ## **Follow-up work and Mitigations** The retention scheduling change was applied during the incident response. Additional work described in the investigation includes: * Continued investigation into why the affected replicas did not self-recover after the load was removed. * Evaluation of scheduling changes to prevent consecutive retention passes while a replica is behind. * Consideration of per-organization delete-rate limits, in addition to existing circuit-breaker controls. The scheduling safeguards and rate limits remain under evaluation; they are not described as completed fixes; however, we continue to look for ways to provide a healthy and stable environment.
Impact, status and times are the vendor’s own, as last archived. View on stspg.io (opens in new tab).
InfluxData (InfluxDB Cloud) profileRecent InfluxData (InfluxDB Cloud) incidentsMarkdownJSON