There is no number on this page, and that is the honest answer.
Revision: Pre-Audit Candidate, 12 October 2026
Version 1.1, dated 12 October 2026 (Pre-Audit Candidate), replacing version 1 of 21 August 2026; it brings the page into line with the service as built, and every change is recorded in the project's change history. A service level page normally opens with a percentage. This one does not, because no listed Haven plan carries an uptime commitment, a measured availability target, or an automatic service credit. Inventing one would take five seconds and would be the single easiest lie on this website to tell.
What the paid tiers carry instead is a support commitment, and the exact status of that commitment is unusual enough to be worth a page of its own.
This is a draft, and we are not lawyers
Everything on this page was written by the people who build Haven, from the code, in the same register as the rest of this site. It is not legal advice and it has not been reviewed by a solicitor. Before this business relies on it — and before you do — it needs a lawyer's pass, and the clauses that need one most are marked where they appear. We would rather ship an honest draft that says so than a confident boilerplate that says nothing.
"Priority support" is a promise about humans, and the code says so
Every other capability in the plan catalogue is a thing the server checks: a storage ceiling
it refuses an upload against, a group size it will not exceed, a session count it enforces, a
retention window a sweep acts on. prioritySupport is the one flag in that
catalogue that no server code reads at all, and the file it lives in says so
in as many words — it is documented there as deliberately not a code path, a service-level
commitment about who answers your message and how fast, which is a promise about people
rather than something software can enforce or refuse.
That is why the comparison table on the pricing page draws the support row differently from every other row, and why the plan cards give it neither a tick nor a cross. A tick would quietly claim it was enforced somewhere. It is not enforced anywhere, on purpose.
So what does it actually mean
- Free, Personal, Family and Team: we aim to reply within 24–48 working hours, and a paid plan is answered ahead of a free one. That is a target, not a clock with a remedy behind it.
- Business: we aim to reply within 4 hours during UK business hours.
- Enterprise: whatever the contract says, which is where a number with teeth belongs.
And what it does not mean
These response times are aims. Nothing measures it, no record of it is published, and no remedy attaches to missing it — you do not get a credit, and the plan does not become refundable because a reply was slow. If you need a response time with a consequence behind it, the listed plans do not have one and no amount of paying for a listed plan produces one. That is Enterprise, and it lives in a signed contract.
Availability
We intend hosted Haven to be available continuously, and we run it as though it were. That is a statement of how the service is operated, and it is not a warranty. There is no percentage, because there is no published measurement to hold a percentage to, and a number with no measurement behind it is decoration.
What you can check yourself, today
The instance answers two endpoints designed for exactly this.
/api/health reports whether the process can serve traffic and names the
failing check when it cannot — database, disk, sweeps. /api/ready answers a
different question: whether this process finished starting on the schema it expects,
which is what a deploy waits on before moving traffic. Neither needs an account. Point
your own monitoring at them and you will know more than any status page we could write.
What does not exist
No status page. No incident history. No published post-incident reports. No maintenance window schedule. If any of those appears later it will be because it was built, and this page will say so on the day rather than in advance.
Planned interruptions, and how you would find out
Not by email — we hold no address for you and cannot send one. And not in the app either: there is no operator-to-customer notice channel in this product, so planned maintenance is not announced to you in advance any more than unplanned downtime is. Downtime of either kind announces itself by the service being down, which is the whole of the mechanism and is worth knowing before you depend on it for something time-critical.
Backups, stated as what they are
Backups are an operational arrangement, not a feature of this software
This site says a subscription buys "a server somebody keeps patched, backed up and running", and that is true — but it is worth being exact about where the truth lives. There is no backup mechanism in the Haven source tree. No backup script, no scheduler, no snapshot code, nothing you could go and read. Backups are something whoever operates the instance arranges around it, and on a hosted plan that is us.
The consequence, stated rather than left implied: there is no published recovery point objective and no published recovery time objective, and no commitment on this page that a given hour's messages would survive a total loss of the machine. If a restore guarantee is something your organisation needs in writing, that is an Enterprise contract term. And note what a backup can never restore here — a private key sealed under a password nobody remembers is as unrecoverable from a backup as it is from the live database.
Things outside anything we could commit to
- Push notification delivery. The message leaves us and travels through a browser vendor's push service. Whether and when it arrives is theirs, not ours. What that costs you in privacy is on the sub-processors page.
- Calls, on an instance with no relay. Relay-only is the default and there is no public fallback, so an instance without a relay reports calls unavailable rather than quietly connecting them in a way that would leak both participants' addresses. That refusal is the correct behaviour, not an outage.
- Anything on your device. A browser that will not run the app, a device that was compromised, an extension that interferes. Local wipe, auto-lock, the panic key and the duress password all narrow a window and none of them defeats code already running on the machine.
- Your password. Losing it loses the account and no service level can change that; there is nothing on our side to reset it against.
- Being right about the threat model. Availability is not security. Everything on the security page stays true on a day when uptime is perfect.
If you need an actual SLA
Then you need Enterprise and a signed contract, and the honest framing of that is: the number does not exist until it is negotiated. The catalogue describes Enterprise as "a dedicated instance, an SLA, and written terms on exactly what the server holds" — that SLA is a thing agreed with a customer, not a published document you are entitled to by paying more, and this page is not going to imply it is sitting somewhere ready.
What we can bring to that conversation is unusual and might be more useful than a percentage: the source is readable, the disclosure panel runs against your own instance and derives its list from your own schema, and every unflattering fact on this website is pinned in the code to a named table and column so that it cannot quietly disappear from the panel a future version shows you. Ask, and we will tell you what a quote can and cannot move.