Status & incident communication
Where to watch operational state and how we communicate during incidents.
Status page
Live at status.xcity.one. Components:
- Gateway (tokenhub) — inference API availability + p95 latency
- Identity (auth.xcity.one) — login, session, registration
- Billing — Stripe webhook ingestion and plan-state sync
- Console —
xcity.one/dashboard - Docs —
xcity.one/docs
Each component publishes a 90-day uptime history. JSON feed at /status.json; RSS at /status.rss.
Incident severity
| Level | Definition | Public update cadence |
|---|---|---|
| Investigating | Anomaly detected, scope unconfirmed | within 15 min of detection |
| Identified | Root cause known, fix in progress | every 30 min |
| Monitoring | Fix deployed, watching | every hour |
| Resolved | Service restored, postmortem pending | postmortem within 5 business days |
Enterprise customers get the same updates pushed to their dedicated Slack Connect channel within 60 seconds of the public post.
Postmortems
Within 5 business days of any S1 incident. We publish a redacted version on the status page and share the full version (including timelines, alerts, and corrective actions) with affected Enterprise customers.
Our template includes: detection → diagnosis → mitigation → root cause → corrective action → action items with owners. We follow blameless review practice — naming systems and processes, not individuals.
Scheduled maintenance
Announced ≥48h in advance via:
- Status page (banner)
- Email to billing-admin contacts
- Slack Connect for Enterprise
Emergency security patches with <15 min duration may go out without advance notice. We document them retroactively on the status page.
Last updated: