# Status Page Scope & SLA Definition
## Decision
We will build a minimal, read-only status page. It will display **one** metric: **Data Durability**.
## The Promise
> "Every patient record that successfully reaches Ferrite Systems is persistently stored and will not be lost due to software failure."
## What we will NOT promise
- **Uptime %**: We cannot guarantee 99.99% availability on customer-owned hardware. If the hospital's network or power fails, we are down. We do not control that.
- **Latency**: Sync times vary by hospital network load. We will not commit to a specific millisecond threshold.
- **Zero Downtime**: Maintenance windows will occur. We will display "Scheduled Maintenance" when applicable.
## Technical Implementation
- **Source of Truth**: The status is derived from the `sync_health` table in Postgres.
- **Logic**: If the most recent successful batch commit is < 5 minutes old, status is "Healthy". If > 30 minutes, status is "Degraded". If > 24 hours, status is "Critical".
- **Frontend**: A static React component that polls `/api/status` every 60 seconds. No real-time websockets. Keep it boring.
## Action Items
1. **James Wright**: Confirm this scope is acceptable to Sales. Do not add "Uptime" to the page.
2. **Elena Vasquez**: Build the React component. Do not add charts or graphs. Just text.
3. **Priya Nair**: Ensure the `sync_health` table is updated on every successful batch commit.
4. **Sofia Lindgren**: Deploy the static page to the customer's public IP. Ensure it is served over HTTPS.