Service level agreement
Last updated 1 September 2026 · Effective On publication, following legal review · Version 1.0-draft
Draft — not yet reviewed by counsel.
This document is published so it can be read and corrected. It has not been through legal review and it does not yet bind anyone. If you are evaluating Rutba and need agreed terms, ask us and we will tell you where the review stands.
The short version
1. What this covers, and what it does not
This agreement applies to every product labelled Available now on our site, for customers on a paid plan, and forms part of the terms of service.
It does not apply to:
- products labelled Early access — usable and being finished, and section 4 of the terms says so before you buy
- products labelled Coming soon, which are not sold
- free plans, trials, sandboxes, and the public demonstration systems
- beta features inside an otherwise generally available product, where they are marked as such
- software you run on your own hardware, where availability is a fact about your infrastructure rather than ours
Saying which is which is what makes the commitment worth anything. A provider that applies one number to everything it sells, including the parts that are half-built, has published a number rather than a commitment.
2. The availability commitment
| Plan | Monthly availability | Roughly, per 30-day month |
|---|---|---|
| Standard paid plans | 99.9% | 43 minutes |
| Enterprise, on a signed order form | 99.95% | 21 minutes |
Where a signed order form states a different figure for you, the order form governs.
3. How it is measured
Availability is measured per calendar month, per service, as the proportion of five-minute intervals in which the service responded successfully to a representative request.
A five-minute interval counts as unavailable if more than half the requests in it fail with a server-side error or time out. Errors caused by a request being malformed, unauthorised, or over a documented rate limit are not failures of the service.
We measure from outside. A monitor that runs inside the same infrastructure it is monitoring reports the infrastructure healthy in exactly the situations that matter most.
4. What does not count against it
- planned maintenance announced under section 5
- emergency maintenance to address a security vulnerability, announced as soon as it is safe to announce it
- failures caused by your own configuration, your own code, your own network, or a third-party service you connected
- use in breach of the acceptable use policy, and suspension arising from it
- force majeure — a genuine external event, for as long as it lasts, and not as a general excuse
Deliberately absent from this list: capacity. If the platform is slow or unavailable because we did not provision enough of it, that is our failure and it counts.
5. Planned maintenance
Most changes ship without downtime. Where downtime is genuinely required, we give at least 72 hours’ notice, schedule it outside 08:00–18:00 UK time on working days, and keep it within a two-hour window.
Planned maintenance is capped at four hours per calendar month. Beyond that, it counts as downtime whatever it was announced as — otherwise the notice period becomes a way to opt out of the commitment.
6. Service credits
| Monthly availability | Credit, as a share of that month’s fee for the affected service |
|---|---|
| Below 99.9% and at or above 99.0% | 10% |
| Below 99.0% and at or above 95.0% | 25% |
| Below 95.0% | 50% |
Credits are applied to your next invoice. They are the sole remedy under this agreement, and they do not limit your right to terminate for material breach under the terms of service — which is the remedy that matters if this keeps happening.
If availability falls below 95.0% in three consecutive months, you may terminate the affected subscription immediately and receive a refund of the unused prepaid portion.
7. Claiming
Write to support@rutba.io within 30 days of the end of the affected month, naming the service and the approximate periods. You do not need to prove the outage — we hold the measurements, and we will apply the credit if the numbers support it and tell you what they were if they do not.
8. Support response targets
These are targets for a first substantive response during UK business hours, not resolution times — a resolution time promised for a problem nobody has diagnosed is a number invented to be quoted.
| Severity | What it means | First response |
|---|---|---|
| 1 — Critical | A production service is down or unusable for your whole organization | 2 business hours |
| 2 — High | A major function is broken and there is no workaround | 1 business day |
| 3 — Normal | Something is wrong and there is a workaround | 2 business days |
| 4 — Low | A question, or a request for a change | 5 business days |
9. Backup and recovery objectives
- Backup frequency — daily full, with continuous transaction log shipping.
- Retention — 35 days.
- Recovery point objective — 15 minutes. At most that much work is lost in a full recovery.
- Recovery time objective — 4 hours for a single service, 24 hours for a full-region event.
These are our commitments for restoring the platform. They are not a substitute for your own export of your own records, which section 20 of the terms of service keeps available to you at all times.
10. Changes
We will give 30 days’ notice before any change that reduces a commitment in this document, and you may terminate the affected subscription within that period with a refund of the unused prepaid portion. Improvements take effect immediately.