Availability, measured rather than promised.
Most vendors publish a number they intend to hit. We publish the number we actually recorded, alongside the endpoint the number came from, so you never have to take our word for it.
Recorded availability
Loading the recorded history…
This figure is computed in your browser from
GET /api/v1/status/history —
the same public, unauthenticated endpoint you can call yourself. If our arithmetic and yours
disagree, yours wins.
How it is measured
- A scheduled task inside the Worker probes each target every 15 minutes and writes one row per check. Roughly 96 checks per target per day.
- Two targets are probed independently: the Worker process itself and database reachability. A day counts as fully up only when every check on every target passed.
- Results are written as they happen, not reconstructed afterwards. A failed check stays in the record.
- History is retained and served for the last 30 days.
There is no third-party status vendor in this path and no manual step where someone decides whether an outage counts. That is deliberate: a status page a vendor can quietly edit is not evidence, and this is a company built on the difference.
What this is not
This is a published measurement, not a contractual guarantee. Our Terms of Service state that we do not commit to a service level except where one is expressly set out in a written enterprise agreement, and nothing on this page changes that.
Recorded history is also a description of the past. It is evidence about how the service has behaved, not a prediction of how it will behave. We publish it because it is checkable, not because it is a promise.
Availability is one dimension of readiness and not the hardest one. CapchaCloud is pre-certification: there is no SOC 2, ISO 27001, PCI DSS or FedRAMP report today, and no third-party penetration test has been performed. That is set out in full in the Trust Center.
Related
Live status board · Trust Center · Incident notification · Terms of Service