§ TRUST · STATUS & SLA
Uptime. Incidents. The promises behind them.
The page the DPO asks for on the procurement call. Current platform status, rolling uptime, the SLA we'll stand behind, the credit schedule when we don't, and a chronological log of every incident with a root cause and a remediation. If anything below doesn't match what your audit pack needs, we'd rather know now than at signature.
§ UPTIME
Rolling windows. Honest about the placeholder.
We don't have a real-time status API wired up yet. The figures below are the conservative placeholders we use in the audit pack until the real feed is in. When it lands, this section stops being editorial copy and becomes a fetch at build time. The numbers will move. The honesty about the placeholder will stay.
-
Last 30 days
99.95%
PLACEHOLDER — pending real status API
-
Last 90 days
99.93%
PLACEHOLDER — pending real status API
-
All-time
99.91%
PLACEHOLDER — pending real status API
§ SLA — WHAT WE PROMISE
Three commitments. Pro+ tier and up.
- 01
§ UPTIME
99.9% monthly uptime — Pro+ tier
Calendar-month rolling. Excludes scheduled maintenance announced at least 72 hours in advance via this page and the status subscribers list. Calculated against the management plane and the embedding-store API; edge nodes are reported separately in the incident log.
- 02
§ P1 RESPONSE
4 UK-business-hour response for P1
P1 = customer-facing outage or sustained data-path degradation. Response time is acknowledgement + named engineer assigned, not resolution. Measured Mon-Fri 09:00-17:30 BST. Out-of-hours P1 routes to the on-call rota with the same 4-hour clock.
- 03
§ P2 RESPONSE
24-hour response for P2
P2 = partial degradation, non-blocking issue, or audit-impacting finding. Response = acknowledgement + triage note within one UK working day. P3 and below ride the normal support queue with no SLA clock.
§ CREDIT SCHEDULE
When we miss the promise. What you get back.
Calculated against the affected month's invoice; applied to the following month's invoice. No claim form, no escalation ticket — the credit appears automatically once the rolling uptime crosses a threshold, with the root-cause memo to follow.
- 01
§ 99.0% – 99.9%
10% credit
Of the affected month's invoice, applied to the next invoice. Below the 99.9% promise; above the major-incident threshold.
- 02
§ < 99.0%
25% credit
Of the affected month's invoice, applied to the next invoice. Triggers an automatic root-cause memo posted to this page within 14 days.
§ RECENT INCIDENTS
The log. Empty is the goal; honest is the policy.
No incidents in the last 90 days.
When an incident does happen, it lands here with:
- A timestamp. Start, resolution, total duration in UK time.
- A severity. P1 / P2 / P3, with the threshold definition linked.
- A root cause. The technical answer, not a marketing apology.
- A remediation. What's changed in code, config or process so the same incident doesn't recur.
If the log stays empty for a full audit cycle, that's the signal — the platform is doing what it's meant to be doing.
§ STATUS SUBSCRIBERS
Get email only when it matters.
A P1 incident, a major remediation, a planned-maintenance window with customer impact. No drip sequence, no marketing, no newsletter. If a quarter goes by without a message, the platform is doing its job.
EU-resident: confirmation posts to a Vercel serverless function in the EU region and dispatches through Resend EU. No US transit at any hop.
Status data resident in eu-west. Subscribe endpoint runs on a Vercel serverless function in the EU region; confirmations dispatch through Resend EU. No US transit at any hop.