Trust
Uptime methodology
Section B.12.1 of the Terms targets 99.5% monthly uptime for the Dashboard, measured per the methodology on this page. This is that methodology, described as it is actually implemented.
What is measured
Seven components are probed independently. Each is reported separately on the status page.
| Web app | Dashboard, marketing site and docs. |
| Database | Reads and writes for every record in the product. |
| Authentication | Sign-in, sessions and access control. |
| File storage | Uploads, attachments and generated documents. |
| MCP server | The Model Context Protocol endpoint at /api/mcp. |
| Onetap Sentinel | Wall units reporting presence into the database. |
| Onetap R2 | Wall units reporting presence into the database. |
How a sample is taken
Each probe is a live request against the component, not a synthetic ping. A component is recorded as operationalwhen it answers within 1,500 ms, degraded when it answers more slowly than that, and downwhen it returns an error or fails to answer within a 5,000 ms timeout.
A component that is not enabled in the deployment — a hardware fleet with no units registered, for example — is recorded as not enabled. That is a fact about configuration rather than availability.
How often
Hourly, on a schedule independent of site traffic, plus one daily run. Samples are also recorded when the status page is loaded, so a period of heavy traffic contributes more observations than a quiet one.
How uptime is calculated
Uptime is the share of observed samples in which a component was operational — not the share of elapsed time. Samples taken while a component was not enabled are excluded from the denominator entirely, since they are evidence neither for nor against availability.
This is a sampled measurement, and we state that plainly rather than implying continuous monitoring. An outage shorter than the interval between samples may go unobserved, and an unobserved period counts neither for nor against the figure. A day on which a component was down for any observed sample is shown as a down day on the status page.
Exclusions
Scheduled maintenance does not count against uptime where at least 48 hours’ notice has been given, per section B.12.2. Downtime caused by events outside our reasonable control is governed by the force majeure provision in section B.21.
Where to see it
Current health and 90-day history for every component are published continuously at onetaplabs.com/status. The figures there are generated from the same samples described above; there is no separate internal dashboard with different numbers.