Is Scalr down?

We are investigating reports of errors affecting Scalr customers. Customers may see timeouts or failed requests in their runs. We are looking into this and will post another update as soon as we have more information.

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

This incident has been resolved.

We are currently investigating this issue.

This incident has been resolved.

Customers who force agent pool assignment on workspaces are seeing the error "Self-hosted agent pool assignment is required by policy." even when an agent is assigned. We are rolling back the code that caused this issue now.

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

This incident has been resolved.

**Root cause** A regression in a release deployed the morning of 2026-08-25 caused the run policy engine to incorrectly flag self-hosted agent pool assignments as non-compliant, triggering the error above even for correctly configured workspaces. **Resolution** The release was rolled back, restoring normal behavior. No customer action is required. **Preventive measures** We are adding regression test coverage for this specific scenario \(self-hosted agent enforcement combined with valid pool assignment\) to prevent recurrence, and reviewing our release validation process for this code path. We apologize for the disruption this caused to your pipelines.

The docs site is currently down. We are working with the vendor to understand what the issue is.

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.

We are continuing to monitor for any further issues.

This incident has been resolved.

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