Checking system status…

Every five minutes, an automated check tests each service. A check fails when the service does not answer as it should, or when one of our alarms for that service is firing. The uptime figure is the share of these scheduled checks that passed, out of those that reached a result, counted per day in UTC. A check that could not reach a result (for example, when the checker itself was refused) and a check that did not run are left out, not counted as passed. A day with no checks shows as "No data" and never counts as up. When fewer than 90 days have been measured, the uptime line says how many were.

Uptime is not availability adjusted for incidents. A problem can start and end between two checks, or affect only some requests, and still be a real incident. Every real incident we declare is listed on this page, and its day is marked on the history bar even when every check passed. So a day can show an incident next to 100% uptime.

The checks have limits. The Web App & Authentication check loads the sign-in page but does not sign in. The Real-time Verification API check calls the health endpoint and measures how long real-time verifications wait. Bulk Verification Processing is measured by how long queued work waits, and Webhooks & Integrations by delivery errors and delays.

The uptime figure is a measurement, not a promise. It is not a service level agreement (SLA) and does not entitle anyone to service credits. Scheduled tests of our status notifications are shown as tests. They do not mark the history bars or change uptime.