Toden reliability report
Production availability
Reporting period: 13 July 2026 to 10 October 2026 (90 days, UTC)
Generated 11 October 2026, 22:01 UTC · Monitoring since 27 September 2026 · Source: OpenStatus, independent external monitoring, last collected 11 October 2026, 01:12 UTC
Partial period: monitoring covers 14 of the 90 days requested. Days before monitoring began are not counted as available or unavailable.
Summary
- Platform availability
- 99.897%
- API availability
- 99.863%
- Incidents
- 18
- Estimated downtime
- 20m 44s
477,613 checks recorded, 491 failed and 87 slow. Scheduled maintenance: 0 windows (0s). API median response 142 ms, 95th percentile 478 ms (average of 13 daily readings). 1 day(s) had failed checks with no incident declared, typically failures seen from fewer than half the regions.
10 October 2026: 100.00% uptime · Degraded
Use the arrow keys to move between days.
Service breakdown
| Service | Now | Availability | Median response | Observed |
|---|---|---|---|---|
| APIMyaza platform | Operational | 99.863% | 142 msover 13 days | 14 of 90 dayssince 27 September 2026 |
| Verification APIIdentity & verification | Operational | 99.862% | 356 msover 13 days | 14 of 90 dayssince 27 September 2026 |
| Hosted verification pagesIdentity & verification | Operational | 99.999% | 359 msover 13 days | 14 of 90 dayssince 27 September 2026 |
Monthly availability
- October 2026Partial: 10 of 31 days99.983%
- September 2026Partial: 4 of 30 days99.672%
Incident history
- Resolved
Downtime
1 October 2026, 20:38 UTC to 1 October 2026, 20:41 UTC · 3m 0s · Verification processing & webhooks
- Resolved
Downtime
1 October 2026, 20:38 UTC to 1 October 2026, 20:41 UTC · 3m 0s · API
- Resolved
Downtime
1 October 2026, 20:38 UTC to 1 October 2026, 20:41 UTC · 3m 0s · Verification API
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