Trust center
Incident history
Every incident that meets the publication threshold, with its timeline, its blast radius, its root cause, and what changed as a result. The disclosure commitments below were published before there was anything to test them against.
Content published as of 6 Aug 2026. Every claim on these pages links to the control, report, or policy behind it.
Disclosure commitments
The clock starts at detection, not at declaration and not at confirmation. Detection is the earlier of the first alert and the first human recognition. Severity is set when the incident is declared and may be revised upward at any time; a downward revision after publication requires an appended correction that states the original severity and the reason. History is never rewritten.
| Severity | Definition | Initial update | While open | Postmortem |
|---|---|---|---|---|
| Sev1 | Confirmed unauthorised access to customer data, confirmed data loss, or full platform unavailability. | 1 hour | Every 60 minutes | 5 business days |
| Sev2 | Major functional impairment affecting many customers, or a security event with credible but unconfirmed data impact. | 2 hours | Every 2 hours | 10 business days |
| Sev3 | Degraded service, or a contained security event with no customer data impact. | 12 hours | Daily | 15 business days, if customer visible |
| Sev4 | Minor or cosmetic, with no customer-visible impact. | Not individually published | Not applicable | Counted in the semi-annual transparency report |
- Regulatory notification does not replace public disclosure. Where a regulation sets a shorter clock, the shorter clock governs and the public update still lands on the schedule above.
- Any incident affecting a specific workspace also goes directly to that workspace's designated security contact within the initial update window. The public page alone does not satisfy the commitment.
- A postmortem is published even when the root cause sits with a sub-processor. The narrative names the category of supplier and the mitigation.
- Incidents with no customer impact are published when they are security relevant and the disclosure teaches something. No customer impact is a publishable value, not a reason to stay quiet.
- Timeline entries written after the fact are labelled as backfilled and rendered distinctly. A tidy timeline assembled later is less credible than a messy one written live.
Published incidents
That is a thin record rather than a strong one, and the honest reading is that the platform is young. The log is published in this state deliberately: the commitments above are worth more before they have been exercised than after, because publishing them first is what makes them a commitment rather than a description.
Live service health is on the status page. Historical incidents from the status record will be backfilled here and labelled as such.
What is not published
An unexplained omission is worse than a stated one, so the exclusions are listed rather than left implicit. Redacted items are marked as redacted with the category of reason, not silently removed.
- Exploit detail for a vulnerability still present in software deployed on customer devices.
- Identities of individuals, whether employees, researchers, or attackers.
- Customer identities and workspace names, unless the customer asks to be named.
- Anything that would compromise an active law enforcement matter.
- Infrastructure detail that materially assists an attacker with no benefit to the reader.