Per-component or all-components. Updates for new incidents, transitions, and resolution.
Per-system health, current latency, last incident.
90-day component uptime.
No active incidents.
Last incident closed 6 days ago. Subscribe below to be notified the moment something changes.
Last 5 incidents — date, duration, components, summary.
- 12 days agominor·47 minutesElevated latency on Q&A copilot in EU region.Affected: Q&A copilot (EU)
- 17 days agominor·18 minutesJira push retry storm.Affected: Integrations — Jira
- 24 days agomajor·2 hours 11 minutesRecording ingestion delayed for large uploads (> 2 GB).Affected: Recording ingestion
- 31 days agominor·9 minutesWebhook deliveries delayed.Affected: Webhooks (outbound)
- 52 days agomajor·33 minutesSSO logins failing for SAML customers.Affected: Authentication / SSO
Published in advance. Outside business hours where possible.
Sundays 02:00–05:00 UTC. Used selectively. Announced ≥ 7 days in advance via this page, email, and in-product banner.
When required for security or stability. Communicated as soon as the work is scheduled, even if < 7 days out, with the reason explicit.
Breaking API changes follow the public deprecation policy (≥ 90 days’ notice for any non-additive change to the documented API).
Get notified the moment status changes.
Pick any combination of channels. Workspace owners on Team+ receive critical incident notifications by default — extend distribution to security and on-call contacts in workspace settings.
/status/feed.rss · /status/feed.atom · per-component feeds.
Drop a Slack incoming webhook URL; we post incident updates to your channel.
GET /status/v1/summary returns the JSON the page renders from.
This page reports state. SLA commitments live with pricing.
Citesvue publishes operational state on this page for everyone. Contractual uptime SLAs and remedies are tier-specific and apply to Enterprise workspaces with dedicated support.
A predictable channel ladder, every time.
- 01Status page. First update goes here, every time, regardless of severity.
- 02Email. To workspace owners and on-file security contacts for SEV-1 and SEV-2.
- 03In-product banner. For SEV-1 incidents affecting authenticated sessions.
- 04CS / Enterprise account contacts. For Enterprise SEV-1, on-call CS lead reaches out within the SLA window.
- 05Post-incident report. ≤ 5 business days for SEV-1/SEV-2; ≤ 10 for SEV-3.
We do not use Twitter / X as a primary incident channel. The status page is the source of truth.
What “regular updates” actually means.
| Severity | Definition | First public update | Update cadence | Post-mortem |
|---|---|---|---|---|
| SEV-1 | Service unavailable for the majority of users; data integrity at risk | ≤ 15 minutes | Every 30 minutes | ≤ 5 business days |
| SEV-2 | Significant degradation; subset of users or one component degraded | ≤ 30 minutes | Every 60 minutes | ≤ 5 business days |
| SEV-3 | Minor degradation; workaround available; small user impact | ≤ 60 minutes | At state changes | ≤ 10 business days |
| SEV-4 | Cosmetic or low-impact issue; no user-visible effect | Logged when resolved | N/A | N/A |
A confirmed material breach triggers a separate, parallel notification path — see breach notification on /compliance.