InfluxDB Cloud Status Page

Sep 29, 2026 · resolved Oct 2

# 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.

Sep 28, 2026 · resolved Sep 28

This incident has been resolved.

Sep 16, 2026 · resolved Sep 16

This incident has been resolved.

Sep 11, 2026 · resolved Sep 11

This incident has been resolved.

Sep 11, 2026 · resolved Sep 11

# **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.

Is InfluxDB Cloud down right now?

No — InfluxDB Cloud is up. All systems operational as of Oct 12, 4:51 AM UTC.

What is InfluxDB Cloud's current status?

InfluxDB Cloud: All Systems Operational. Alert24 checks InfluxDB Cloud's status page continuously and can notify you the moment it changes.

How do I get alerted when InfluxDB Cloud goes down?

Alert24 monitors InfluxDB Cloud and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.