Skip to main content

Incidents & SLA

This page covers what happens during a Driftstack outage: how we detect, communicate, and resolve incidents, and the credit policy if we miss our SLA.

Status page

status.driftstack.io is the single source of truth during an incident. The same data the status page renders is also published via GET /v1/status (overall + per-component status) and GET /v1/status/incidents (recent / live incidents). To get notified by email when an incident is filed or resolved, subscribe on the status page.

Severity ladder

SeverityDefinitionFirst updateUpdate cadence
Outage Core API down across all customers, or data-loss risk. ≤ 15 min Every 30 min until resolved.
Major API degraded (>5% error rate) OR a critical surface (auth, sessions) unavailable for a subset of customers. ≤ 30 min Every 60 min.
Minor Single non-critical surface (dashboard, an SDK build pipeline) degraded. ≤ 60 min At resolution.
Maintenance (not an incident severity) Planned change with potential impact. Always announced ≥48h in advance, by a status post; it is not one of the three incident severities above. Pre-announced Start + end.

The first-update times are targets, not guarantees, unless your contract sets one (API Scale while ToS §8.13 keeps its service level; an Enterprise Order Form). One person, the founder, handles incidents. There is no rota and no pager, so outside EU business hours a first update can take longer.

Detection

Two signals trigger an incident:

Customer communications during an incident

  1. Status page entry filed with severity + title + affected components.
  2. Email fan-out to confirmed status-page email subscribers.
  3. Progress updates on the cadence above. Each update appends to the incident's timeline (visible via GET /v1/status/incidents).
  4. Resolution marks the incident resolved and triggers a final email to subscribers with a root-cause summary + remediation steps.
  5. Postmortem for Outage / Major incidents published within 7 business days on the public status page as a permanent entry under the resolved incident. Minor incidents get an inline summary on the resolved status entry.

Note: incident.created / incident.updated / incident.resolved are internal event names, not webhook event types you can subscribe to. Email subscription is the customer-facing notification path.

SLA + credit policy

For API Scale, while ToS Section 8.13 keeps its service level, the service level covers the API, the customer dashboard and the live-view streaming endpoints, as the SLA policy lists; an Enterprise Order Form sets its own. Other plans have no contractual service level (ToS Sections 8.13 and 9.1). SDK distribution is best-effort.

Tier-by-tier SLA targets, the windowing methodology, the credit bands, and the dispute process all live in /docs/sla-policy — that is the authoritative reference.

Reading SLA data from the API

GET /v1/status/sla

→ {
  "data": [
    {
      "target": "api.driftstack.dev",
      "uptimePct": 99.99,
      "totalProbes": 43200,
      "okCount": 43196,
      "failCount": 4,
      "lastProbeAt": "2026-05-11T13:00:00Z",
      "lastFailureAt": "2026-05-09T14:23:00Z",
      "windowStart": "2026-04-11T13:00:00Z",
      "windowEnd": "2026-05-11T13:00:00Z"
    },
    {
      "target": "example-target",
      "uptimePct": null,
      "totalProbes": 0,
      "okCount": 0,
      "failCount": 0,
      "lastProbeAt": null,
      "lastFailureAt": null,
      "windowStart": "2026-04-11T13:00:00Z",
      "windowEnd": "2026-05-11T13:00:00Z"
    }
  ]
}

No auth — status surface is public. Window is a fixed rolling 30 days. Field names are camelCase.

A null uptimePct means we have no measurements for that target in the window — not that it was perfect. totalProbes: 0 says the same thing in a number, and lastProbeAt is null for the same reason. Treat null as unknown and show it as unknown; a client that reads it as 100% will report an uptime figure nobody measured. An empty data list means no target is being checked, so there is no uptime figure to read.

Postmortems

Public postmortems for Outage + Major incidents live on the public status page, attached to the resolved incident entry. Each follows the same template: timeline, root cause, what we changed to prevent recurrence. Postmortems are blameless and detailed enough to be useful — we'd rather over-share than under-share.

Reporting a problem

Related