Is InfluxData down?

We are currently investigating an issue affecting query performance in Azure West Europe.

We are continuing to investigate this issue and will provide further updates as soon as available.

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

We are continuing to work on a fix for this issue.

We are continuing work to remediate immediate query performance degradation, and investigating actions for a permanent fix.

Query performance has returned to normal levels. Planned stabilisation work is still ongoing, and we are monitoring closely.

Query performance remains stable, and we continue to monitor closely. Additional mitigation and stabilization work is ongoing.

Query performance remains stable, and we continue to monitor closely as traffic increases. We will continue to assess performance and provide updates.

We are working on resolving the ongoing intermittent query performance. During peak usage periods, large or complex queries may run slower than normal. Writes and data durability are not affected at this time. We have deployed several improvements overnight and further changes are in progress.

We have identified the issue and the team is actively working on implementing a fix.

We are still having issues in the region, the engineering team is working on it.

We are continuing to investigate this issue.

We are continuing to investigate this issue.

We have made several recent changes to improve query performance and we continue to monitor the region closely.

Performance has returned to normal levels following an update. We will continue to monitor.

We have increased isolation in the storage layer for the impacted region to provide greater amounts of resilience and to allow for faster recovery. We are continuing to investigate heightened memory consumption and page faults within the storage layer. Query success rates and response durations have returned to normal levels. We will continue work to increase the resiliency of this region over the next 24 hours and will carefully monitor for any increase in query latency.

The cluster remains stable, and we are continuing to monitor it.

We appreciate the continued patience while we worked through this incident. We have been monitoring the previous fixes for the last 24 hours and all changes have responded well during sustained traffic. The region is stable and we are resolving this incident. An RCA is in progress and will be added to our status page as soon as its available.

# RCA # Query Performance Degradation in Azure West Europe, September 27 to October 1, 2026 ## Summary From the evening of September 27 to the morning of September 30 \(UTC\), customers in the Azure West Europe region experienced slow queries and timeouts. Writes were accepted throughout, but on some partitions, new data was not immediately queryable. Earlier incidents on this cluster \(September 7, 11, 15 and 16\) produced the same symptom with different triggers and have their own RCAs. We believe the condition described herein was the root cause of all prior incidents. ## Cause All data in the cluster is stored on redundant pods across many physical nodes. These pods read time-series data through memory-mapped files. The host’s operating system keeps the most frequently accessed parts of those files in a page cache built from memory not consumed by the pods themselves. In this region, each pod holds about 365 GB of data. The cache on a host could not hold the data its pods were querying, so reads that would normally come from cache became page faults served from disk. Each pod read about 90 MB/s from disk, thus a host with ten pods reached roughly 990 MB/s, which is near the throughput ceiling on each host. Memory consumption looked normal on every metric we monitor. The storage process itself uses little memory, and the cache takes the remainder, so a shortage would not appear as memory pressure or shortfall. At the throughput ceiling, index lookups on the write path were delayed by disk reads, causing writes to fall behind and pods to fail their replication-lag health check. Pods in this region spent 8.9% of the day past the lag threshold, against 0.09% in a comparable region. At peak, both replicas of the busiest partitions fell behind together, creating access delays which were most acutely visible through the query path. Slow disk caused health and readiness checks to time out, so healthy pods were removed from rotation and restarted. Each restart took 30 to 85 minutes to recover, during which the pod's partner carried the load alone, with the rebuild adding even more disk load. A file-reference safeguard was also causing 50\+ pod restarts a day where a normal rate would be 0. ## Remediation While early changes helped, and resolved many trouble indicators, they did not solve the root cause. We doubled query-layer capacity, restarted pods, raised the readiness timeouts, raised cleanup timeouts to avoid safeguard restarts, and doubled recovery concurrency after a restart. We ruled out a controller lock, a per-disk limit, and a single tenant's load. The root cause fix was to raise each storage pod's resource request so that each host holds fewer pods. Each pod now has twice as much memory for page cache and disk throughput. Within 1 hour of this change, query abandonment fell from 31% to 0.1%. Page faults and disk reads dropped sharply. During the next morning's peak, abandonment was 0.06%, within normal limits. ## Timeline \(UTC\) Sep 27 22:58 - Query queue depth alert fires; incident opened. Query-layer capacity increased over the next hours without lasting effect Sep 28 07:00 - Degradation at morning peak; storage pods fall behind on writes and fail health checks; stuck pods restarted one at a time Sep 28 11:33 - Restart loop identified: slow disk causes health checks to trigger restart; each restart takes 30 to 85 minutes to recover Sep 28 13:45 - Lost file-reference cleanup identified as a second source of forced restarts Sep 29 08:58 - Readiness probe timeout raised and rolled out fleet-wide Sep 29 11:10 - Throughput appears to recover; degradation returns, with 36% of queries abandoned Sep 29 16:20 - Queue clears after recovery-concurrency and probe changes Sep 30 00:25 - Cleanup timeout raised to 24 hours; forced restarts stop Sep 30 07:00 - Degradation at peak; abandonment about 55% Sep 30 11:59 - Analysis shows cache capacity per pod is too small and disk reads are at the host ceiling Sep 30 12:43 - Rollout begins to spread pods across more nodes Sep 30 13:21 - Query performance returns to normal; abandonment down to 0.1% within the hour Sep 30 14:20 - Page faults and disk reads confirmed sharply lower after rollout Oct 1 07:00 to 09:00 - Morning peak with 0.06% abandonment versus 40% to 55% the day before Oct 1 09:48 - Incident declared resolved internally ## Future mitigation We added warning alerts for page-fault rate, cache coverage, disk reads on storage volumes, and query abandonment. Each alert is designed so that cache pressure appears before causing external visibility. Runbooks now suggest major page faults as a leading indicator of storage performance degradation, with details on “relief valves” available to tune. We are continuing to track down the storage-engine reference leak and moving the disk check out of the health path. Neither leak nor check is a risk factor for triggering this type of incident; they are conditions observed during diagnosis and remediation that warrant investigation.

We are currently investigating this issue.

Some queries may be slower than normal and recently written data may take longer to appear in results. Data ingestion and durability are not affected. We have identified the cause and mitigation is underway

We are continuing to work on a fix for this issue.

We are continuing to work on a fix for this issue.

We are continuing to work on a fix for this issue.

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

This incident has been resolved.

We are currently investigating this issue.

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

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

This incident has been resolved.

The SSO Login Service is currently experiencing downtime and the team is currently looking into it

The engineering team has resolved the issue and is continuing to monitor the health of the SSO Login Service

This incident has been resolved.

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

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

This incident has been resolved.

# **Root Cause Analysis: Query Latency on September 11, 2026** Region: Azure West Europe Cluster: prod01-eu-west-1 ‌ ‌ **Incident report: query latency in Azure West Europe, September 11, 2026** On the morning of September 11, some customers in Azure West Europe saw slower than usual query responses. Read latency was elevated and there were occasional query timeouts. Performance returned to normal at 08:52 UTC. We're sorry for the disruption. **What happened** On September 10, a single workload ran a sustained volume of deletes. That activity left a large backlog of delete markers on every storage partition in the region. Delete markers are normally cleared by a scheduled delete-compaction process. Until that process ran, each hourly retention pass had to work through the full backlog. Passes that usually take about three minutes were taking 10 to 15 minutes across the cluster. While a partition was in one of these longer passes it responded more slowly, and queries that spanned it were delayed. At 07:55 UTC on September 11, one storage partition entered a self-recovery restart. Its companion replica was in the middle of a retention pass at the time, so for a short period that partition had no healthy replica available to serve queries. This was not the root cause, but the overlap added to the impact on queries touching that partition. Alerts on query queue depth fired at 08:14 and we opened an incident. An operator restarted the companion replica at 08:25. The impaired partition completed its recovery at 08:47. The query queue then drained without further intervention, and by 08:52 it was back to normal and the alerts had cleared. **Timeline** \(UTC\) Time Event Sep 10 - Sustained high delete volume from a single workload Sep 11, 07:55 - Storage partition restarted and entered extended recovery 08:14 - Query queue-depth alerts triggered; incident opened 08:25 - Companion replica restarted 08:47 - Impaired partition completed recovery 08:52 - Query queue returned to normal; alerts cleared **Changes we are making** There are four pieces of work under way. None of them is complete yet, and we won't consider them validated until we have confirmed the effect in production. * Retention enforcement is moving to an off-peak window. Longer passes should then fall outside business-hours query load. * Full compactions will run more frequently, so a delete backlog can clear between scheduled runs instead of accumulating. * Per-partition compaction throughput is being increased. * New alerting and telemetry will tell us whether the changes above are having the intended effect.