SLA policy
This page documents Driftstack's availability commitments by tier, how we measure uptime, what counts as an "incident," and the credit mechanics when we fail to meet the target. It describes the standard offering; enterprise contracts can negotiate a tier-specific SLA addendum that supersedes this page.
Tier-by-tier availability targets
Tier ids below match the AccountTier enum the API
uses; see GET /v1/account/me.
| Tier | Monthly target | Max allowed downtime / month |
|---|---|---|
free / api_starter | — | (no SLA — best effort) |
solo_manual | 99.5% | ~3h 40m |
team_manual / api_builder | 99.9% | ~43m |
agency_manual / api_scale | 99.95% | ~21m |
enterprise | 99.99% (per addendum) | ~4m |
Tier upgrades take effect immediately on payment confirmation; SLA credit accruals reset at the boundary so a mid-month upgrade does not retroactively apply the higher target.
What's covered
The SLA applies to these public surfaces:
https://api.driftstack.dev/*— every documented endpoint.https://app.driftstack.dev/*— the customer dashboard.- The live-view streaming endpoints for an active session.
What's NOT covered
- Scheduled maintenance windows announced >72h in advance on status.driftstack.dev. Maintenance windows are capped at 4h/month and rarely triggered (most deploys are zero-downtime rolling restarts).
- Failures attributable to a customer-supplied
target_url, profile state, or script — those affect that session's success rate, not Driftstack's availability. - Sub-processor outages we cannot route around: NowPayments IPN delivery, Stripe Checkout, Postmark email. We surface the impact + the upstream status page link on status.driftstack.dev.
- Force majeure: regional cloud-provider failures, large-scale DDoS against shared infrastructure, government-mandated shutdowns. We still publish the incident; it just does not accrue SLA credits.
How we measure
Availability is measured per calendar month, using probes from our health-probe service (V-295b). The probes target:
GET /v1/health— the API health endpoint.GET /on the dashboard — the customer-facing SPA shell.
A probe is "failed" when it returns non-2xx OR exceeds 5s. A minute is counted as downtime when 3+ consecutive probes fail (i.e. ≥ 3 minutes of failure register, mirroring the auto- incident threshold from. Probes run every 60s from three geo-distributed locations; the minute counts as down only when ≥ 2 of 3 locations register a failure (avoids regional ISP routing issues being counted against us).
Credit mechanics
Missing the monthly target accrues a credit on the customer's next invoice, computed against the monthly subscription fee:
| Uptime in month | Credit |
|---|---|
| Below target, ≥ 99.0% | 5% |
| Below 99.0%, ≥ 95.0% | 10% |
| Below 95.0% | 25% |
Credits are capped at the customer's monthly subscription fee for that month — they cannot exceed what was paid. Credits do not apply to per-minute or per-session usage charges, only the tier subscription line.
How to request a credit
- Email [email protected] within 30 days of the calendar month closing.
- Include the time range you observed the impact + the failure symptom you saw (5xx, timeout, etc.). If possible, include the session ids that were affected.
- We reconcile against the probe data + the audit trail on status.driftstack.dev within 5 business days. Approved credits appear on the next invoice as a line-item.
Enterprise SLA addenda
Enterprise contracts can negotiate:
- Higher per-incident credit percentages.
- Hard ceilings on degraded-but-not-down windows (P95 latency budgets).
- Dedicated 24/7 oncall pager with named first responders.
- Maintenance-window pre-approval rights.
Contact [email protected] to start the conversation. The default-tier SLA above is the floor — addenda only ever strengthen it.