Problem: No public status page exists today.
Area: ORB / Incident readiness.
Proposal: Stand up a public status page for the hosted product, backed by real hosted-service health (aggregating src/selfhost/health.ts's readiness()/ReadinessProbe shape and its AMS-side mirror packages/loopover-miner/lib/ams-health-server.ts across the fleet, once #7180's provisioning gives a real fleet to aggregate over).
Deliverables:
Design system: if this status page has any custom UI beyond a third-party status-page provider's own template, it must use the shared design-system package from #4966/#4967.
AMS Cloud Readiness cross-reference (added 2026-07-12)
See also #5226 in the AMS Cloud Readiness milestone — the AMS-side parallel to this exact problem, already citing this issue as precedent. Keep both sides in sync if either design changes.
Resources
src/selfhost/health.ts (readiness, ReadinessProbe — the per-instance health shape to aggregate)packages/loopover-miner/lib/ams-health-server.ts (the AMS-side mirror of the same shape)
maintainer-only — most realistic paths here (a third-party status-page SaaS signup, DNS/domain wiring) require live account access a contributor structurally can't have; this is a maintainer-executed ops task, though the health-aggregation code feeding it could be split out separately once the account/service exists.
Problem: No public status page exists today.
Area: ORB / Incident readiness.
Proposal: Stand up a public status page for the hosted product, backed by real hosted-service health (aggregating
src/selfhost/health.ts'sreadiness()/ReadinessProbeshape and its AMS-side mirrorpackages/loopover-miner/lib/ams-health-server.tsacross the fleet, once #7180's provisioning gives a real fleet to aggregate over).Deliverables:
Design system: if this status page has any custom UI beyond a third-party status-page provider's own template, it must use the shared design-system package from #4966/#4967.
AMS Cloud Readiness cross-reference (added 2026-07-12)
See also #5226 in the AMS Cloud Readiness milestone — the AMS-side parallel to this exact problem, already citing this issue as precedent. Keep both sides in sync if either design changes.
Resources
src/selfhost/health.ts(readiness,ReadinessProbe— the per-instance health shape to aggregate)packages/loopover-miner/lib/ams-health-server.ts(the AMS-side mirror of the same shape)maintainer-only — most realistic paths here (a third-party status-page SaaS signup, DNS/domain wiring) require live account access a contributor structurally can't have; this is a maintainer-executed ops task, though the health-aggregation code feeding it could be split out separately once the account/service exists.