Availability,on the record.

Measured production availability of Toden, from independent monitoring in Africa, Europe and North America. Every figure comes from recorded checks, and the method is published below.

Download reliability report Shareable report

All systems operational

As of 11 October 2026, 21:12 UTC, from OpenStatus. Monitoring since 27 September 2026.

Live status page

Platform availability

4 October 2026 to 10 October 2026 (UTC)

Source: OpenStatus · last collected 11 October 2026, 01:12 UTC

99.998%

1 day in this period had failed checks with no incident declared. That usually means failures seen from fewer than half of the monitoring regions, which do not change a service's status. They still count against availability.

4 Oct10 Oct

10 October 2026: 100.00% uptime · Degraded

Operational
Degraded
Partial outage
Major outage
No data
Scheduled maintenance

Incidents: 0
Estimated downtime: 10s
Scheduled maintenance: None
API median response: 141 ms; 95th percentile 475 ms, 7 days

Service availability

Availability by service for the selected period
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 history

October 2026Partial: 10 of 31 days99.983%
September 2026Partial: 4 of 30 days99.672%

Incidents and maintenance

No incidents or maintenance were recorded in this period.

Evidence for your security review

Send your procurement or security team a stable link to this record, or a PDF with the summary, service breakdown, incident history and methodology.

Open shareable report Download PDF

How these figures are measured

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