Failure should be visible, not invasive
A public status view should prove the system is alive without turning operational detail into an attack surface.
There is a satisfying version of a platform showcase where every graph is live, every component is named, and every deployment animates across the screen.
It is also an excellent way to publish private topology, capacity, versions, failure timing, and operator habits.
The public view is a product
A safe status page is not Grafana with fewer menu items. It is a purpose-built projection with an allowlisted schema.
For RS Platform, a visitor can eventually see:
- coarse operational state;
- broad regional presence;
- component categories;
- rounded workload and node counts; and
- delayed uptime and deployment activity.
They should not see peer identities, private addresses, exact capacity, software versions, raw metrics, incident detail, or arbitrary queries.
The difference is intent. An operator dashboard answers, “What exactly is wrong, and what can I do?” A public projection answers, “Is this real, and what kind of system is it?”
Independent evidence matters
The platform cannot prove its own health with one heartbeat emitted by the thing being monitored. It needs signals that fail separately: control-plane health, observability health, public-ingress probes, gateway state, and direct edge reports.
The public projection can summarize those signals, but it should never expose their raw labels or turn disagreement into a detailed incident report.
Honest unavailability beats invented health
The public site is hosted independently from the platform. When the platform API eventually becomes unreachable, the interface can remain available and say that live data is unavailable.
It must not convert silence into green.
That rule is small enough to remember and strong enough to design around: unknown is a state; healthy is a claim.