{
  "meta": {
    "version": "v1",
    "pricing": {
      "public": {
        "label": "Public",
        "description": "Read-only API access for lightweight status checks and public integrations."
      },
      "premium": {
        "label": "Premium",
        "description": "API keys with higher hourly quotas, plus Slack, Teams, Discord, webhook, and email outage alerts across your vendor stack."
      }
    },
    "generatedAt": "2026-10-27T15:30:48.579Z"
  },
  "data": {
    "id": "incident_statuspage_influxdb_020h6gmr70rt",
    "slug": "influxdb-query-performance-degradation-in-azure-westeurope-2026-09-11",
    "title": "Query performance degradation in Azure Westeurope",
    "summary": "Query performance degradation in Azure Westeurope",
    "status": "resolved",
    "stale": false,
    "severity": "minor",
    "startedAt": "2026-09-11T08:45:49.611+00:00",
    "updatedAt": "2026-09-28T13:16:15.191+00:00",
    "resolvedAt": "2026-09-11T09:46:51.096+00:00",
    "provider": {
      "slug": "influxdb",
      "name": "InfluxDB Cloud"
    },
    "affectedServices": [
      {
        "slug": "influxdb-api",
        "name": "Serverless writes & queries"
      }
    ],
    "links": {
      "html": "/incidents/influxdb-query-performance-degradation-in-azure-westeurope-2026-09-11",
      "api": "/api/v1/incidents/influxdb-query-performance-degradation-in-azure-westeurope-2026-09-11",
      "providerHtml": "/providers/influxdb",
      "alerts": "https://outagedeck.com/account?stack=influxdb&utm_source=api&utm_medium=response&utm_campaign=api_alerts&utm_content=incident"
    },
    "impactSummary": "InfluxDB Cloud reported a minor event for the affected tracked services.",
    "source": {
      "id": "source_influxdb_status",
      "kind": "official_api",
      "name": "InfluxDB Cloud Status",
      "checkedAt": "2026-10-27T15:30:11.676+00:00",
      "stale": false,
      "officialUrl": "https://status.influxdata.com",
      "statusPageUrl": "https://status.influxdata.com"
    },
    "updates": [
      {
        "id": "update_statuspage_influxdb_020h6gmr70rt_d115j48xdm8n",
        "status": "identified",
        "body": "The issue has been identified and a fix is being implemented.",
        "createdAt": "2026-09-11T08:45:49.729+00:00"
      },
      {
        "id": "update_statuspage_influxdb_020h6gmr70rt_45v450jv8ypl",
        "status": "monitoring",
        "body": "A fix has been implemented and we are monitoring the results.",
        "createdAt": "2026-09-11T09:27:31.289+00:00"
      },
      {
        "id": "update_statuspage_influxdb_020h6gmr70rt_2nmxvxby7343",
        "status": "resolved",
        "body": "This incident has been resolved.",
        "createdAt": "2026-09-11T09:46:51.096+00:00"
      },
      {
        "id": "update_statuspage_influxdb_020h6gmr70rt_ymvbblktk9w7",
        "status": "resolved",
        "body": "# **Root Cause Analysis: Query Latency on September 11, 2026**\n\nRegion: Azure West Europe Cluster: prod01-eu-west-1\n\n‌\n\n‌\n\n**Incident report: query latency in Azure West Europe, September 11, 2026**\n\nOn 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.\n\n**What happened**\n\nOn 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.\n\nDelete 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.\n\nAt 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.\n\nAlerts 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.\n\n**Timeline** \\(UTC\\)\n\nTime     Event\n\nSep 10 - Sustained high delete volume from a single workload\n\nSep 11, 07:55 - Storage partition restarted and entered extended recovery\n\n08:14 - Query queue-depth alerts triggered; incident opened\n\n08:25 - Companion replica restarted\n\n08:47 - Impaired partition completed recovery\n\n08:52 - Query queue returned to normal; alerts cleared\n\n**Changes we are making**\n\nThere 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.\n\n* Retention enforcement is moving to an off-peak window. Longer passes should then fall outside business-hours query load.\n* Full compactions will run more frequently, so a delete backlog can clear between scheduled runs instead of accumulating.\n* Per-partition compaction throughput is being increased.\n* New alerting and telemetry will tell us whether the changes above are having the intended effect.",
        "createdAt": "2026-09-28T13:14:14.145+00:00"
      }
    ],
    "access": {
      "plan": "public",
      "keyed": false
    }
  }
}