- Monitoring regions
- Johannesburg, London, Frankfurt, Amsterdam, Virginia (US East), California (US West)
- Measured by
- OpenStatus (independent external monitoring, hosted outside Myaza infrastructure)
- How often
- Every minute for the API, verification and processing checks; every five minutes for the website.
- How availability is calculated
- Availability is the share of checks that succeeded: (successful checks + slow but successful checks) divided by all checks, over complete UTC days. A check is one request from one region. A timeout, connection error or unexpected response counts as failed.
- Slow responses
- A check that succeeded but took longer than its latency threshold counts as available and is reported separately as degraded.
- Regional failures
- Each region retries before reporting a failure. Every regional result is counted, so an outage seen from one region lowers availability in proportion; a service is marked down on the status page only when at least half the regions agree.
- Scheduled maintenance
- Scheduled maintenance is not excluded. Checks that failed during maintenance count against availability like any other; maintenance windows are listed separately.
- Downtime estimates
- Estimated downtime is the failed share of checks multiplied by the observed time. It is an estimate from sampled checks.
- Missing data
- Days before monitoring began, or with no recorded checks, are not counted as available or unavailable. They are shown as having no data.
- Records
- Daily results are copied from the monitoring provider into Myaza's own records once each day has closed, and are never rewritten.
- What these figures are