Toden reliability report
Production availability
Reporting period: 4 October 2026 to 10 October 2026 (7 days, UTC)
Generated 11 October 2026, 22:05 UTC · Monitoring since 27 September 2026 · Source: OpenStatus, independent external monitoring, last collected 11 October 2026, 01:12 UTC
Summary
- Platform availability
- 99.998%
- API availability
- 99.998%
- Incidents
- 0
- Estimated downtime
- 10s
241,621 checks recorded, 4 failed and 44 slow. Scheduled maintenance: 0 windows (0s). API median response 141 ms, 95th percentile 475 ms (average of 7 daily readings). 1 day(s) had failed checks with no incident declared, typically failures seen from fewer than half the regions.
4 Oct10 Oct
10 October 2026: 100.00% uptime · Degraded
Use the arrow keys to move between days.
- Operational
- Degraded
- Partial outage
- Major outage
- No data
- Scheduled maintenance
Service breakdown
| Service | Now | Availability | Median response | Observed |
|---|---|---|---|---|
| APIMyaza platform | Operational | 99.998% | 141 msover 7 days | 7 of 7 days |
| Verification APIIdentity & verification | Operational | 99.998% | 297 msover 7 days | 7 of 7 days |
| Hosted verification pagesIdentity & verification | Operational | 99.998% | 352 msover 7 days | 7 of 7 days |
| Verification processing & webhooksProcessing & delivery |
Monthly availability
- October 2026Partial: 10 of 31 days99.983%
- September 2026Partial: 4 of 30 days99.672%
Incident history
No incidents or maintenance were recorded in this period.
Methodology
- 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