LIVE TELEMETRY
Status.
My public view of service health, latency, uptime, and recent incidents.
WHAT IT IS
The honest page.
I built Status so you can see how the services behind zentr.dev are doing. Refreshing a broken page harder is a strategy, but I wanted a better one. It includes current service state, recent latency, 24-hour uptime, and incident history. Choose a service in the chart dropdown to see its recent response times.
| Signal | Meaning |
|---|---|
| Operational | The latest checks are succeeding. |
| Degraded | The service responds, but not normally or not consistently. |
| Offline | The monitor cannot get a healthy response. |
| Incident | A recorded period of failure, from detection through recovery. |
HOW IT STAYS AVAILABLE
Two cloud copies. One address.
I run service checks from my home PC every 30 seconds. Its service list follows the shared project registry automatically, using /h/main with /h/data as a fallback. The monitor uses fresh independent DNS lookups, with DNS over HTTPS as a fallback if ordinary DNS stops responding. Cloudflare and AWS each save a copy of the page and status data once a minute.
I run a DNS service on the home PC that checks both cloud copies every 30 seconds and selects a working provider for status.zentr.dev. DNS answers have a 30-second lifetime; cached answers can delay a switch. If live monitoring stops, the page identifies the saved snapshot instead of presenting it as fresh.
The PC checks my public IP every minute and automatically updates the nameserver and origin address records when it changes. Failed or conflicting IP observations keep the last known address. DNS caches can still delay recovery after an address change.
My setup depends on the home PC and connection for DNS. The parent zentr.dev domain still uses Cloudflare DNS, so an outage of those parent nameservers can affect uncached lookups. The direct AWS address remains an alternative when AWS is reachable.
A SMALL CAVEAT
Monitoring is evidence, not magic.
Uptime is calculated from recorded checks, not continuous observation. A green check means the monitor can reach the service and got the response it expected. It does not prove every possible action inside the service is working. If something feels broken while Status is green, it can still be broken. Computers enjoy nuance.