Uptime commitments, backup and recovery objectives, and how we communicate during incidents.
Why availability matters more here than usual
For most SaaS products, downtime is an inconvenience. For a compliance platform it can be worse: if your evidence store is unreachable the morning an auditor arrives, or your policy repository is down during an OCR request, the outage becomes your problem, not just ours. We design and operate the service with that asymmetry in mind, and we write our commitments down so you can hold us to them.
This page describes how we approach uptime, backup, recovery, and incident communication. The live status page shows current health; this page explains the engineering and process behind it.
Uptime commitment
Our contractual availability target is 99.9% monthly uptime, measured as the percentage of minutes in each calendar month during which the user-facing application and API respond successfully to external checks, excluding announced maintenance windows. Two things matter more than the headline number:
- How it is measured. We define availability against the user-facing application and API, measured externally — not against a ping to a load balancer that can pass while the product is effectively down.
- What happens when we miss it. Service credits and remedies are defined in the service agreement, not negotiated after the fact.
Historical uptime figures are published on our status page at /trust/system-status/. We show the history rather than a single flattering number because a rolling average can hide a bad month.
Backup and recovery
Backups exist to be restored, so we treat restoration — not the backup job — as the thing to verify:
- Customer data is backed up on a defined schedule (encrypted daily snapshots, retained for 35 days).
- Backups are encrypted and stored separately from production, so an incident that affects production does not automatically affect the copies.
- Our recovery time objective (RTO) is 4 hours and recovery point objective (RPO) is 24 hours, matching the daily snapshot cadence.
- Restores are tested on a defined cadence (quarterly), and the tests are documented — an untested backup is a hope, not a control.
What we commit to
- We target 99.9% monthly uptime, measured externally against the user-facing application and API.
- Customer data is protected by encrypted daily snapshots with 35-day retention, replicated to a second AWS region (us-west-2) so a regional failure does not take the copies with it.
- Restores are exercised quarterly against real backups, and the results are documented.
Where anything on this page differs from your signed service agreement, the agreement controls.
How we communicate during incidents
Silence during an outage is the fastest way to lose trust, so our incident process includes communication as a first-class step, not a clean-up task:
- Acknowledgement — incidents affecting customer-facing services are posted to the status page once confirmed, with an initial assessment of scope.
- Updates — posted on a regular interval while the incident is open, even when the update is “still investigating”. No update is itself information, and it is the wrong kind.
- Resolution and review — after resolution, significant incidents get a written post-incident review covering what happened, the customer impact, and what changed to prevent recurrence. Reviews for major incidents are available to affected customers on request.
If an incident involves a potential security or privacy impact, the incident response and breach notification process described in our BAA takes over, with its own notification timelines.
Maintenance windows
Routine maintenance is designed to be non-disruptive. Where disruptive maintenance is unavoidable, it is scheduled in advance, announced through the status page, and placed in a published window (Sundays, 02:00–06:00 UTC) chosen to minimise impact across customer time zones. Emergency maintenance — for example, patching an actively exploited vulnerability — may happen outside the window; we notify as early as the situation allows and explain afterwards.
Documentation available on request
- SOC 2 Type II report (under NDA)
- Penetration test summary
- Business Associate Agreement
- Architecture and data flow diagram
- Completed CAIQ / SIG Lite
The SOC 2 report covers availability commitments and the controls behind them; the architecture diagram shows the redundancy model. If your business continuity review needs something not listed — a summary of our own continuity and disaster recovery testing, for instance — ask through the same form.
Questions
Security questions go to [email protected] and get a human answer within one business day. If you are mid-incident and need status, check the status page first — it will always be faster than email, and it is where our engineers post first.