LAB NOTE · DATA LAYER

Public Status Summary Data Layer

The first data layer does not publish raw operations. It publishes a small, public-safe summary that can later be cached, charted, or archived without exposing the control plane.

Why a summary exists

Raw health checks are valuable for operators, but they can contain too much implementation detail for a public website. A public summary gives visitors a clear answer — operational, degraded, or outage — without leaking systemd output, listener maps, host details, webhook payloads, private tokens, or VPN configuration.

Current shape

Public endpointstatus.solarfans.cc/summary.json returns a compact schema for coarse service health.

Human pageThe Live Status homepage reads from the same public-safe status model instead of exposing raw checks as the primary user experience.

Private detailDetailed checks, operational logs, event files, and secrets stay behind the VPS and protected operator channels.

Future storageKV can cache the latest summary, D1 can store uptime history, and R2 can hold redacted archives if those needs become real.

Boundary rule

The public layer should explain state, not grant control. If a field helps a visitor understand availability, it may belong in the summary. If it helps an attacker map infrastructure or trigger actions, it stays private.

Verification pattern

The public summary endpoint returns HTTP 200 and a stable schema version.
The summary uses coarse service names and public status values.
Leak checks reject private terms such as secrets, raw payloads, systemd output, listener details, internal host data, or VPN material.
Cloudflare KV, D1, and R2 remain separate production gates until there is a concrete storage need and rollback plan.

Result

Solarfans now has a public-safe status contract: simple enough to cache at the edge, structured enough for future history, and narrow enough to preserve the private operating boundary.