Support
Incidents happen. What separates a good vendor from a bad one is how they communicate through them. Here's exactly what to expect from us — so you can tell your own team and your own boss with confidence.
Where you'll hear it first
Our single source of truth during an incident is the status page. It gets the first post and every update after. From there, the channel depends on how badly it affects you.
First
Every incident is posted tothe status pageand updated there throughout. Subscribe once and it comes to you — seehow status works.
Direct
For a major (sev-1) incident affecting your Organization, we email your account admins directly. You don't have to be watching the status page to find out something is wrong.
In product
When an active incident affects something you'd use in the dashboard, we show a banner there too — so the warning is in front of you while you're working, not buried in an inbox.
How we size it
The severity of an incident drives how loudly we communicate and how fast we update. This is the framing we use.
Sev-1 — Major outage
A core capability is down or broadly broken — the API is unavailable, syncs are failing across the board, or webhooks aren't being delivered. Status page post plus direct email to affected admins.
Sev-2 — Partial or degraded
Something is degraded but working — one connector's syncs are slow, webhook delivery is delayed, or a subset of requests are failing. Status page post; email if your Organization is specifically affected.
Sev-3 — Minor
Low-impact issues with a clear workaround or limited scope. Tracked on the status page; no proactive email unless it grows.
During the incident
Silence during an outage is its own kind of damage. We commit to a regular update rhythm, even when the update is "still working on it, no new information."
For a sev-1, we post an update at least every 60 minutes until the incident moves to Monitoring — even if there's nothing new, so you know we're still on it.
For a sev-2, we update as the situation changes, and at least a couple of times per business day while it's open.
Every update names what's affectedand, when we can estimate it, what to expect next. We won't invent an ETA we can't stand behind.
After the incident
For any sev-1 incident, we publish a postmortem withinfive business days of resolution. No spin, no "we apologize for any inconvenience" and nothing else. A real postmortem includes:
If your Organization was materially affected by a sev-1, we'll send the postmortem to your admins directly — you shouldn't have to ask for it.
Subscribe to the status page and make sure your account admins are who they should be. That's how the right people hear first.