[koala73]

Summary

Scheduled Umami storage checks can no longer remain blocked behind a runner-less probe indefinitely: each new sample replaces an older probe on the same ref. Ref-scoped concurrency keeps a manual run from another branch from cancelling the production main monitor, while the existing main-only environment, Railway credential boundary, warning thresholds, and five-minute timeout stay unchanged.

The live stale owner (31125595042) was cancelled during diagnosis. Its queued replacement then reached a runner and produced a real storage result: 68.8% used, 0.661 GiB/day growth, and 23.0 days projected headroom. That warning is the retained capacity policy working after scheduler recovery; sustained capacity action is separate from this control-plane fix.

Related: #6348

Validation

• Test-first contract: the new assertion failed against cancel-in-progress: false, then passed after the workflow change.
• node --test tests/umami-storage-monitor.test.mjs — 10/10 passed.
• npm run typecheck and npm run lint passed; lint reported only existing warnings outside this change.
• npm run test:data exercised the repository suite. Its only failures were the sandbox denying macOS mktemp under /var/folders; the exact failing tests/prepush-hook-gate.test.mjs suite passed 16/16 outside the sandbox.
• The pre-push gate passed, including typecheck, Unicode safety, the focused workflow contract, version sync, and scoped repository checks.

Post-Deploy Monitoring & Validation

• Validation window: observe four consecutive natural */15 runs on main after merge, about one hour. Owner: @koala73.
• Success: every run leaves waiting/pending, gets a runner, reads the protected Railway volume, and emits usage, growth, and headroom within five minutes. Alert-policy failures are valid monitor results; scheduler or credential failures are not.
• Check: use the Umami Storage Monitor Actions history and inspect each run's runner assignment, environment step, and Postgres Umami output. Confirm that no non-main dispatch cancels a main run.
• Failure: any run remains runner-less, is concurrency-cancelled by another ref, cannot access the production environment token, omits capacity metrics, or exceeds five minutes.
• Mitigation: cancel any stale group owner before dispatching a replacement. Revert this commit only if ref-scoped cancellation causes cross-run interference, then keep manual stale-owner cleanup in place while the scheduler policy is corrected.
• Capacity follow-up: if consecutive restored samples continue to cross the existing 30-day warning contract, open separate capacity work with those samples as evidence.

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
worldmonitor	Ready	Preview	Aug 9, 2026 4:09am