# Status Page Runbook
## Purpose
Provide a simple, accurate status signal to customers. The goal is trust, not visibility. We do not expose internal metrics, latency, or error rates.
## Scope & Constraints
- **No Real-Time Polling:** The page is static. It is updated manually or via a simple cron job that queries Postgres.
- **No Dashboards:** We are not building a Grafana-style view. No charts, no graphs.
- **Data Source:** Postgres `system_health` table.
- **Hosting:** Static HTML served via Nginx/Apache. No dynamic backend required for the page itself.
## Status Definitions
We only expose three states. Anything else is an internal issue.
1. **Operational**: All sync batches are completing successfully. No data loss.
2. **Degraded**: Sync is delayed or partial. Data is safe, but not real-time.
3. **Offline**: Sync is halted. No data is moving.
## Update Procedure
1. **Check Health:** Query `SELECT status, last_check FROM system_health;`
2. **Determine State:**
- If `status = 'OK'` -> Operational
- If `status = 'WARN'` -> Degraded
- If `status = 'FAIL'` -> Offline
3. **Update Page:** Edit `public/status.html` with the new state and timestamp.
4. **Deploy:** Push the static file to the web server.
5. **Verify:** Curl the page to ensure the new state is live.
## Communication
- **Operational:** "All systems are operational."
- **Degraded:** "We are experiencing delays in data synchronization. Your data is safe, but updates may take longer than usual."
- **Offline:** "We are currently unable to process new data. We are investigating the issue. Your existing data is safe."
## Anti-Patterns
- Do not show error logs.
- Do not show internal queue depths.
- Do not promise specific resolution times.
- Do not build a live-updating UI. If you want a live UI, that's a different product, not a status page.