- Level
- confirmed
- Worst impact
- Degraded
- Components
- API Queries
- Regions
- eu, eu-west-1
What to do
Check whether you use InfluxDB Cloud API Queries in eu, eu-west-1. Check your stack
Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.Confirm your retries, queues and scheduled jobs caught up after the 5h 52m it lasted.
Anything that failed between 2026-09-07 10:11 UTC and 2026-09-07 16:03 UTC may need a replay.Subscribe to InfluxDB Cloud's feed to hear about the next one first. RSS feed
https://down.guide/feed?provider=influxdata works in Slack (/feed subscribe), Discord feed bots and any RSS reader.
Updates from InfluxDB Cloud 7
- identified
The issue has been identified and a fix is being implemented.
provider
- identified
We are continuing to work on a fix for this issue.
provider
- identified
We are continuing to work on a fix for this issue.
provider
- identified
We are continuing to work on a fix for this issue.
provider
- monitoring
A fix has been implemented and we are monitoring the results.
provider
- resolved
This incident has been resolved.
provider
- 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.
provider
Reports count in aggregate; nothing about you is shown.
Corrections
None so far.
Something wrong on this page? Report an error or send us a note. Every fix is listed here.
Questions about DWN-b14ee7cbe9
Is InfluxDB Cloud still down?
No, this incident was resolved 2026-09-07 16:03 UTC. For InfluxDB Cloud's live state, see https://down.guide/influxdata.
How long did it last?
5h 52m, from 2026-09-07 10:11 UTC to 2026-09-07 16:03 UTC, by the times InfluxDB Cloud posted.
What was affected?
InfluxDB Cloud named API Queries in eu, eu-west-1.
What caused it?
InfluxDB Cloud hasn't published a root cause. If it does, it shows here.
Where does this come from?
InfluxDB Cloud's official status page, https://status.influxdata.com, quoted verbatim. down.guide's own probes, reports and social counts are labeled as ours.