We're sorry for the trouble. There is an active incident, Deployments slow to start, affecting deployments across US West and other regions due to deployment worker instability. Your deployment's build, container creation, and healthcheck steps all completed, but promotion to active has not progressed, which is consistent with this incident. We are working to stabilize the system and clear the backlog. Please follow that link for live updates.

Update 01:35 UTC: RESOLVED for us. Traffic restored at 01:25:54 UTC - once your networking fix propagated, probes reached the 53b7371e container, and ingress flipped to it (stable external 200s verified). We aborted our queued extra redeploy (bc9ce8c7) to avoid another cutover mid-incident. Remaining cleanup on your side: the service still shows 53b7371e as 'Deploying' even though its container is serving - please tidy when the backlog clears. Customer-visible impact: ~00:23-01:25 UTC.

Apologies for the trouble. The Deployments slow to start incident caused the delays across your deployment's steps, and your stuck deployment has now fully promoted to SUCCESS with networking configured. Separately, there is a new incident affecting US West: Storage and networking issues affecting some services in US West, which may be worth monitoring given your region.

URGENT REGRESSION 01:47 UTC - NOT resolved, and now data-availability-threatening. When 53b7371e was promoted to active (~01:34 UTC) the public ingress path BROKE AGAIN: api.recireel.com and the service domain time out (TCP connect OK, zero bytes) while your internal health checkers still reach the container. Worse, volume I/O has collapsed on container 370df75540e2 - store SQLite commit durations 01:33-01:36 UTC: 16,643ms / 5,143ms / 40,378ms / 95,324ms / 85,851ms. 95-second disk commits on a singleton production volume is a data-availability risk, not just routing. We are deliberately NOT redeploying (removed our own queued redeploys) to avoid a volume detach/attach while your storage/network layer is unstable. Please: (1) fix/reroute ingress to the promoted container; (2) check the host/storage backing recireel-recovery-volume. Hard-down for customers since ~01:35 UTC - second hard-down window tonight.

Recovery confirmed 02:01:45 UTC after your storage-infrastructure fix: 10/10 external 200s, store commits back to ~60ms (from 95,324ms), same container, no restore needed. Customer-visible windows tonight: ~00:23-01:25 and ~01:35-02:01 UTC. Solved stands. Thank you.

Apologies for the disruption tonight. The first window (00:23-01:25 UTC) was caused by the Deployments slow to start incident, and the second (01:35-02:01 UTC) by a storage and networking issue in US West that has since been resolved. Glad the service and volume I/O are fully back to normal with no data loss.