scalr.io Status Page

Sep 1, 2026 · resolved Sep 1

This incident has been resolved.

Aug 27, 2026 · resolved Aug 27

This incident has been resolved.

Aug 25, 2026 · resolved Aug 25

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

Aug 20, 2026 · resolved Aug 20

This incident has been resolved.

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.

Is scalr.io down right now?

No — scalr.io is up. All systems operational as of Oct 12, 5:48 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.