Service level agreement

We run to a target of 99.9% monthly uptime for the API and dashboard — roughly 43 minutes of unplanned downtime a month.

We are calling that a target rather than a guarantee, deliberately. A guarantee is only worth the measurement behind it. Ours is independent of our own servers, which is the part that matters most — but it checks every thirty minutes from one place, and that is too coarse to settle a monthly percentage on. How it is measured sets out exactly what it does and does not catch.

The API, this website and the dashboard are checked from outside our own infrastructure, on a schedule, by a service we do not host. That last part is the point: the API runs on a single server, and a monitor living on that server would go down with it and report nothing.

Each check is retried three times, twenty seconds apart, before anything is raised. One failed request is usually a network fault between the checker and us rather than an outage, and treating it as one would make the alerts worth ignoring.

Two limits, so you can judge what this is worth. Checks run every thirty minutes, not every minute, and the schedule is best-effort — it can run late. And they run from one place, so a fault between that place and our region looks the same to it as an outage here.

So this is a floor on how quickly we find out, not a stopwatch. It is why the uptime figure above is still a target rather than a guarantee, and why there is no automatic credit table further down: we would rather owe you a straight answer than compute a percentage from measurements this coarse.

It also means you may still notice an outage before we do. If that happens, tell us — we will treat it as the incident it is, not argue with you about our own graph.

Announced maintenance windows; failures of your own internet connection or device; third-party payment provider outages; and force majeure events.

Suspension for non-payment or terms breach is also excluded.

The API runs as a single process, so a deploy restarts it. That is a short interruption of a few seconds, not a zero-downtime rollover, and we would rather you knew that than be surprised by it mid-sale.

Deploys are done outside Indian and Nepali salon trading hours wherever the change allows it.

Anything needing longer than a restart is scheduled between 02:00 and 05:00 NPT and announced at least 72 hours ahead by email to workspace owners.

Starter — one working day, by email.

Growth — four working hours during India or Nepal business hours, priority email.

Chain — one hour for anything blocking trading, by phone, with a named contact.

“Blocking trading” means you cannot take payment. Those jump the queue on every plan, including Starter.

There is no automatic credit formula here. We do measure from outside now, but every thirty minutes on a best-effort schedule is not precise enough to settle a percentage of a monthly fee, and publishing a table we could not defend line by line would be a promise in the shape of a commitment rather than an actual one.

What we do instead: tell you what happened, in writing, without waiting to be asked. If an outage cost you trading time, raise it with us and we will settle it on the facts of your case — including a credit where that is the right answer.

When the checks are frequent enough and run from more than one place, a measured credit scheme is what we intend to replace this section with.

Anything lasting more than 15 minutes is emailed to workspace owners. We do not run a public status page yet; when we do, this will say where it is.

Incidents over an hour get a written post-mortem within five working days: what happened, why, and what changed so it does not recur.

Every collection is exported nightly to a single compressed file, kept for fourteen days on an access-restricted host.

Recovery is to the last nightly snapshot. There is no point-in-time restore, so the realistic recovery point is up to a day of work, not minutes. We aim to have a workspace trading again within four hours of deciding to restore.

The export is compressed rather than encrypted, and we do not yet rehearse restores on a schedule. Both are named on the security page, which sets out exactly where this falls short today.