Query performance degradation in Azure Westeurope

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 1h 52m it lasted.

  Anything that failed between 2026-08-25 13:49 UTC and 2026-08-25 15:41 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 4

1. identifiedAug 25, 2026, 1:49 PM UTC

   The issue has been identified and a fix is being implemented.

   provider

2. monitoringAug 25, 2026, 2:29 PM UTC

   A fix has been implemented and we are monitoring the results.

   provider

3. resolvedAug 25, 2026, 3:41 PM UTC

   This incident has been resolved.

   provider

4. postmortemSep 28, 2026, 1:00 PM UTC

   # **Root Cause Analysis: Query Latency on August 25, 2026** Region: Azure West Europe Cluster: prod01-eu-west-1 ## **Summary and impact** On August 25, 2026, some customers in Azure West Europe experienced increased query latency and query timeouts. Additional query capacity helped reduce the initial queue, but full recovery required a manual restart of a stalled storage partition. Query latency returned to normal at 15:35 UTC. ## **Cause** A surge in query volume triggered scaling that quickly exhausted available resources. Shortly after the initial trigger, a storage partition did not complete startup successfully. Although additional capacity brought the query queue back to a nominal state, customer latency signals showed that recovery was incomplete. We discovered the stalled partition required manual intervention to complete initialization. One half of the partition remained online to serve queries and writes while its companion half was impaired. The underlying reason for the partition startup failure remains under investigation. ## **Recovery actions** The team allocated additional query resources, then manually inspected and restarted the impaired partition after identifying the incomplete recovery. The partition fully recovered at 15:32 UTC, and query latency returned to normal at 15:35 UTC. ## **Timeline** All times are UTC. Time Event 13:13 - Scaling alerts triggered; incident opened. 13:33 - Additional resources were added and consumed. 13:35 - Query queue returned to a nominal state. 14:11 - Impaired partition attempted a self-repair restart. 14:40 - Customer latency signals indicated incomplete recovery; investigation resumed. 15:24 - Impaired partition was manually inspected and restarted. 15:32 - Impaired partition fully recovered. 15:35 - Query latency returned to normal. ## **Future Mitigations** Improvements to the partition management workflow are in progress to strengthen resilience and automate recovery. Investigation into the startup failure continues. These improvements are ongoing work, rather than completed preventive fixes. We continue to strive for a healthy platform for all customers on our cloud infrastructure.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.