All modules are running slow in Prod1/2/3/4 due to cloud provider incident

What to do

• Check whether you use Harness Platform, Platform, Platform, Platform in us, us-west1. 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 2h 7m it lasted.

  Anything that failed between 2026-08-20 17:17 UTC and 2026-08-20 19:23 UTC may need a replay.

• Subscribe to Harness's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=harness works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from Harness 8

1. investigatingAug 20, 2026, 3:37 PM UTC

   We are currently investigating this issue.

   provider

2. investigatingAug 20, 2026, 4:05 PM UTC

   The slowness could cause either of below symptoms: - Pipelines not starting - Delays in execution - Pipelines being cancelled due to timeouts

   provider

3. investigatingAug 20, 2026, 4:22 PM UTC

   Our cloud provider is facing an active incident and we are following up.

   provider

4. investigatingAug 20, 2026, 4:32 PM UTC

   We are continuing to investigate this issue.

   provider

5. identifiedAug 20, 2026, 4:50 PM UTC

   Our cloud provider has confirmed an ongoing incident impacting multiple regions. Harness pipelines have not experienced failures as a result, though some users may continue to experience slowness. We are monitoring the situation closely and will provide updates as more information becomes available.

   provider

6. monitoringAug 20, 2026, 5:17 PM UTC

   We are observing improved latencies across the board following the fix implemented by our cloud provider. We are continuing to monitor the situation closely and will provide further updates as warranted. We noted some stuck executions for CI for couple of customers, which we are investigating

   provider

7. resolvedAug 20, 2026, 7:23 PM UTC

   This incident has been resolved.

   provider

8. postmortemAug 26, 2026, 4:57 AM UTC

   # Summary On 20 August 2026, beginning at approximately 15:00 UTC, the Harness platform experienced widespread performance degradation across all production environments. Pipeline executions that normally complete in around two minutes took seven to ten minutes. Continuous Delivery, Continuous Integration, pipeline orchestration, and Feature Management & Experimentation were all affected. Google Cloud Platform experienced a multi-product incident in the us-west1 region affecting Bigtable, Compute Engine, Google Kubernetes Engine, and persistent-disk I/O. Harness production infrastructure runs on persistent disks in that region. The degradation raised database operation latency from approximately 2 ms to over 10 ms at the 95th percentile, which in turn caused message-queue processing lag and propagated to every service that depends on timely database access. ‌ # Impact This was a degradation, not an outage. Pipelines continued to execute and complete successfully throughout; they were slow rather than failing. No data was lost, and no customer work was dropped as a result of this incident. # **Root cause** Harness production infrastructure in the affected environments runs on Google Cloud Platform persistent disks in the us-west1 region. When that storage layer degraded, the effect propagated through the platform in a predictable chain: **Persistent-disk I/O degradation in us-west1.** Google Cloud Platform experienced a multi-product incident affecting Bigtable, Compute Engine, Google Kubernetes Engine, and persistent-disk performance. This was an infrastructure failure in the provider’s environment, outside Harness’s control. # **Preventive actions** Although Harness cannot prevent a cloud provider infrastructure failure. The actions below are aimed at detecting one faster and being better positioned to act on it. | **Action** | | --- | | Continue routine pre-testing of targeted cross-region database failovers, as performed during this incident, to keep failover readiness verified rather than assumed | | Assess full-stack multi-region failover readiness for future scenarios in which cross-region latency would be unacceptable |

   provider

Corrections

None so far.

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