scalr.io Status Page

Jul 6, 2026 · resolved Jul 6

**Summary** On July 6, 2026, runs failed to start for approximately 22 minutes, returning the error "Cannot provision execution environment." The root cause was a stuck PVC \(persistent volume claim\) during a migration to new network storage for the Terraform/OpenTofu providers cache. **Impact** Between 16:48 and 16:53 UTC, new runs across affected workspaces failed to schedule with a "Cannot provision execution environment" error. **Timeline** \(all times UTC\) * 16:48 — Issue detected; investigation began * 16:50 — Root cause identified: PVC stuck due to in-use protection finalizer * 16:51 — Mitigation deployed \(providers cache disabled\); monitoring began * 16:53 — Continued monitoring, no further impact observed * 17:10 — Incident resolved **What Happened** During the migration to new network storage for the Terraform/OpenTofu providers cache, the existing PVC was still attached to multiple active workloads. Kubernetes' in-use protection finalizer blocked deletion and recreation of the volume, so new runs could not bind to it and failed to schedule. **Mitigation** We disabled the providers cache to unblock run scheduling while we worked on the underlying volume issue. This restored run scheduling immediately, with only a minor, temporary performance impact from running without a warm provider cache. **Root Cause** The migration runbook did not account for the PVC's in-use protection finalizer when workloads were still actively bound to the volume, which blocked the planned delete-and-recreate step. **Remediation and Prevention** * Immediate: delete the workloads still holding the PVC, recreate the volume, and restore it as the providers cache. * Preventive: update the migration runbook to explicitly drain or cordon any workloads still bound to a PVC before attempting to delete and recreate it, rather than assuming the volume is free.

Jul 1, 2026 · resolved Jul 1

**Summary** On July 1, Terraform and OpenTofu runs experienced significant delays, up to 10–25 minutes, during the initialization and plan phases for a number of customers, due to capacity constraints in the network-backed provider plugin cache under load. We have mitigated the issue by temporarily removing the shared network storage from the provider download path, and the platform is stable. We are re-architecting how provider plugins are distributed to prevent this class of slowdown from recurring. **What Happened** Before a run can begin planning, it downloads the Terraform/OpenTofu provider plugins it needs \(for example, the AWS, GCP, or Azure providers\) from a shared cache backed by network storage. A period of high run volume, combined with growth in the total size of the provider cache, drove the aggregate load past the practical limits of that storage. As downloads queued, the init/plan phase of affected runs slowed dramatically, in some cases by 10–25 minutes, and a small number of runs errored or hit their timeout and had to be retried. The network storage reached its limits due to the large number of connected run nodes and began throttling, slowing down all workloads that relied on it. **Mitigation** After several unsuccessful attempts to increase the storage throughput, we temporarily removed the shared network storage from the provider cache path, providers are currently downloaded over the public network for each run. As a result, init times may be slightly longer than with a healthy provider cache, and runs temporarily depend on the availability of public provider registries. **What We're Doing Next** We are improving the plugin cache architecture along two lines: a node-local caching layer that eliminates the shared network storage bottleneck \(to be in place before we re-enable the provider cache\), and a caching network mirror that removes the direct dependency on public registry availability. Together, these layers ensure the failure of any one of them is absorbed by the others without service degradation. We apologize for the disruption. If you have questions or are still experiencing issues, please contact our support team.

May 21, 2026 · resolved May 21

This incident has been resolved.

May 19, 2026 · resolved May 19

This incident has been resolved.

May 18, 2026 · resolved May 18

This incident has been resolved.

Is scalr.io down right now?

No — scalr.io is up. All systems operational as of Jul 13, 11:44 PM UTC.

What is scalr.io's current status?

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

How do I get alerted when scalr.io goes down?

Alert24 monitors scalr.io 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.