Auth0 status

How we check Auth0

We watch auth0.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

Every Auth0 tenant answers on its own domain in its own region, so there is no shared public endpoint that represents customers as a group. We watch Auth0's own host, which is an honest platform signal and explicitly not a reading of your tenant, whose region is the thing that actually decides whether an incident affects you.

What is Auth0?

Auth0, now part of Okta, is an identity platform that handles authentication for applications: login pages, social and enterprise connections, multi-factor challenges, token issuance, and user management. Teams adopt it to avoid building and maintaining authentication themselves, which is a good decision on almost every axis except one. It puts a third party on the path to the front door.

The most useful thing to understand about an authentication outage is who it actually affects. Applications built the recommended way validate tokens locally, using signing keys published by Auth0 and cached by the application, rather than calling the identity provider on every request. That means an outage does not sign anyone out. Users with valid sessions keep working normally, and the damage is concentrated on people trying to sign in for the first time, sessions reaching the point where they need a token refresh, and flows like password resets that require the provider to be reachable. An outage during a quiet period may go entirely unnoticed; one at nine in the morning is a very different event.

That distinction has an architectural consequence worth acting on. An application that calls the identity provider on every request, rather than validating tokens against cached keys, has converted a partial outage into a total one. It is a common enough pattern to be worth checking for, and the fix is a caching decision rather than a rewrite.

Regional hosting is the second thing to check during any incident. Auth0 tenants live in specific regions, and status is reported per region, so an announced incident may have nothing to do with your users. This regularly produces the situation where one team is firefighting and another sees no problem at all, and both are describing their own reality accurately.

Most Auth0 failures, though, are not Auth0's. Authentication is the part of an application most sensitive to configuration, and the configuration lives in two places at once: the tenant settings and your deployment. A callback URL that no longer matches after a domain change, a client secret rotated in one environment but not another, a signing key past its rotation, or an upstream enterprise connection having its own bad day all produce login failures that arrive minutes after a deploy and look exactly like a platform incident. The error Auth0 returns names the cause, which is why reading it first saves more time than any status page, including this one.

Frequently asked questions

Is Auth0 down right now?

Check the board above; it reflects our own probes against Auth0 from all five of our regions, refreshed every couple of minutes. Auth0 tenants are hosted per region, so also check your own tenant's region on Auth0's official status page, which reports them separately.

My users cannot log in but this page shows Auth0 up. What should I check?

Check your tenant's region first, then your own configuration. Auth0 publishes status per region, so an incident affecting one leaves the rest untouched. If the region is healthy, the usual causes are an expired signing key or client secret, a callback URL that no longer matches after a deployment moved to a new domain, or a connection to an upstream identity provider that is itself having problems.

Does an Auth0 outage log existing users out?

Not immediately, and this is the most reassuring thing to know. Users holding a valid session or an unexpired access token continue to work, because your application validates the token rather than calling Auth0 on every request. What fails is anything requiring a fresh authentication, so new logins, token refreshes, and password resets stop while everyone already signed in carries on until their token expires.

Why did logins start failing right after a deploy?

Because a deploy commonly changes something Auth0 checks. A new domain or preview URL that is not in the allowed callback list, a changed environment variable holding the client secret, or a rotated signing key will all produce authentication failures within minutes of a release. The error Auth0 returns names the reason, and it is far more useful than any status page.

Should my application keep working if Auth0 is unavailable?

For signed-in users, yes, and that is worth designing for. Validating tokens locally against Auth0's published keys, caching those keys, and giving tokens a sensible lifetime means an outage stops new sign-ins rather than ejecting your entire user base. An application that calls Auth0 on every request has made the identity provider a hard dependency of every page view.