A published target
99.9% monthly availability on the application, measured against actual request success rather than against a ping. The status page shows the real figure including the months we missed.
Platform · platform & data
Reliability pages usually list a number of nines and a data centre certification. Neither answers the questions that matter: what degrades first, how much work you lose in the worst case, and what you are left holding if the company behind the software goes away.
What it does
99.9% monthly availability on the application, measured against actual request success rather than against a ping. The status page shows the real figure including the months we missed.
Recovery point objective of five minutes through continuous replication; recovery time objective of four hours for a full regional failure. Both are tested rather than asserted.
Under partial failure, reads stay up, posting stays up, and agents pause first. The ordering is deliberate: automation stopping is inconvenient, a half-posted transaction is not.
Each customer’s records are logically isolated with enforcement in the data layer, so a failure in one tenant’s workload does not become a correctness problem in another’s.
A full export in open formats, scheduled or on demand, to your own storage. Not a support ticket, not an exit clause — a feature that works while everything is fine.
Public post-mortems for anything customer-affecting, with the cause and the fix rather than a note about elevated error rates.
Everything fails eventually. The design question is what fails first and what that costs you, and it is a question most vendors avoid because answering it requires admitting a failure model exists.
Ours degrades in a fixed order. Agents pause before user actions are refused. Reads survive when writes cannot. Posting to the ledger is the last thing to go and the first thing back, because a business can survive an afternoon without automation and cannot survive a period where half the transactions posted.
Every ledger write is a transaction that either completes entirely or does not occur. There is no intermediate state in which a journal exists with one side of it recorded, and no failure mode in which a retry produces a second copy — writes carry idempotency keys for exactly that reason.
This sounds obvious and is not universal. A meaningful share of the reconciliation problems we are brought in to fix originate as partial writes during a failure somebody else’s system did not handle atomically.
We are a young company. The honest risk is not that a data centre burns down — it is that we do not make it, and you are running your finance function on our software.
The mitigation we offer is not a promise about our prospects. It is that a full export in open, documented formats runs on a schedule you control into storage you own, containing your ledger, subledgers, dimensions, documents, and the audit trail. If we disappear, you hold a complete dataset a competent team can load elsewhere. Source code escrow is available on Enterprise, though we say plainly that escrowed code is less useful than most buyers assume — the data is the asset.
Restores are exercised quarterly against production-sized data, and failover is tested rather than documented. An untested backup is a hypothesis, and the moment you discover it was wrong is the worst possible moment.
Limits
That is what the number means. If your operation cannot tolerate that, say so during evaluation rather than after, and we will tell you honestly whether we fit.
We have less operational history than the incumbents. The export path exists because that risk is real, not because it is theoretical.
If your bank feed or accounting API is down, that data is stale here. We show staleness rather than presenting old figures as current.
Questions
Recovery objectives, degradation behaviour, exit path. We would rather answer them now than in an incident.