Okiyumi Status
Public status and observability for production services
Reliability · infrastructure
Monitoring that tells the truth: public health and origin health are different things.
Context
A production status and observability system built on Uptime Kuma — but not the stock Kuma page: a custom public UI, an API gateway, a history layer and real monitoring semantics.
Problem
Green internal health doesn't mean the product is reachable for a user. A real incident exposed the gap: the system was alive inside but unreachable outside — and stock monitoring saw nothing.
Solution
- 01
Separating PUBLIC HEALTH from ORIGIN HEALTH: two independent views of one system, born from a real incident.
- 02
A custom public UI: overall status, groups, 90-day uptime history, latency, SSL, incidents, maintenance and stale-data detection.
- 03
Long memory: 730 days of daily history, 90 days of raw latency, Telegram alerts over a durable retry queue, backup monitoring and a historical store.
Architecture
Public UI
RU / EN · dark / lightAPI gateway
history layer · semanticsUptime Kuma
monitoring 17 servicesInfrastructure probes
backups · restore drillTelegram delivery
durable retry queueFLOW
- 01Origin health→ Public probes
- 02Public probestruth for the user→ Public status
Numbers
active monitors
days of UI history
days of daily history
Stack
- Uptime Kuma
- custom gateway
- Telegram bot
- nginx
- backups
- probes
Outcome
- A real isolated restore drill of the backup was performed — recovery is proven in practice, not assumed.
- A product insight from an incident became an architectural principle: public vs origin drives the whole system.