What the status page shows
- Component status — API, dashboard, webhooks, settlement rails, KYC providers, sandbox
- Ongoing incidents — with live updates and estimated time to resolution
- Scheduled maintenance — planned with 7+ day notice
- Historical uptime — 90-day rolling per component
Subscribe to updates
Three channels:- Email — any resolution or new-incident notification
- Webhook — POST to your URL on status changes (useful for routing to your PagerDuty)
- Slack — our public Slack app posts to your channel
Uptime targets
| Component | SLA |
|---|---|
Core API (/v1/*) | 99.95% |
| Dashboard | 99.9% |
| Webhooks | 99.9% for delivery attempts; 99.99% for queue retention |
| Sandbox | 99.0% (no SLA, best-effort) |
| Settlement rails | Inherits upstream provider SLAs |
When your integration fails
Quick checklist before escalating:- Check status.getsly.ai — platform incident?
- Inspect response
request_id— include it in support tickets - Read the
codefield — is this a known error category? See error codes - Try in sandbox — same request in test environment; reproduces? Integration bug. Doesn’t reproduce? Environment-specific.
- Open a ticket — see support
Post-incident reports
Every Severity 1 and Severity 2 incident gets a public postmortem within 7 business days. You can read past ones at status.getsly.ai/history.Degraded modes
Sly’s architecture gracefully degrades on certain failures rather than returning500. Examples:
- Settlement rail outage → transfers held in
processingstate, retried when rail recovers. Webhooktransfer.delayedfires. - Quote provider outage → existing quotes honored; new quotes return
503. - KYC provider outage → account creation succeeds; verification deferred with
pendingstatus. - Dashboard outage → API unaffected. Dashboard is independent.
