Clerk status

How we check Clerk

We watch clerk.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.

Each Clerk application answers on its own frontend API subdomain, so no shared endpoint represents customers as a group. We watch Clerk's own host, which is an honest signal about their infrastructure rather than a claim about your instance, and we would rather measure a narrower thing accurately than a broader thing by implication.

What is Clerk?

Clerk provides authentication and user management as a set of drop-in components and APIs, aimed particularly at applications where the sign-in flow, the user profile, and organisation membership would otherwise be several weeks of work that nobody wants to own. Adopting it removes that work and, as with any identity provider, places a third party on the path to the front door of your application.

The most useful thing to know during an incident is that not everyone is affected equally. Sessions are token-based, and your application verifies those tokens rather than asking Clerk about them on every request. Users who are already signed in therefore keep working during an outage, and the failures concentrate on people arriving fresh, signing up, or reaching the point where their session needs to be refreshed. The size of the impact depends heavily on when the incident happens, which is why the same duration of downtime can be barely noticed on a quiet evening and severe at the start of a working day.

That property is also a design lever. An application that verifies tokens locally against cached keys degrades gracefully, losing new sign-ins while everything else continues. One that calls the provider on every request has turned an authentication incident into a total outage for every page view. The difference is a caching decision made early, and it is not easy to change during the incident that reveals it.

Most Clerk failures, though, are configuration rather than platform problems, and the pattern is recognisable. Authentication is unusually sensitive to environment, because it validates the domain a request came from and the keys it was made with. Deploy to a new domain that is not configured on the instance, promote a build still carrying development keys, or set a secret in one environment and not another, and sign-in breaks immediately, with a clear error message that most people do not read until after checking a status page. The order is worth reversing.

Organisation and permission features add a further category. When membership, roles, or permissions are used to gate parts of an application, a change to how they are configured can lock users out of areas they previously reached, which reports as a failure and is a deliberate rule doing exactly what it was told. Reproducing the affected user's state is the way through, and no availability signal will help.

Frequently asked questions

Is Clerk down right now?

Check the board above; it reflects our own probes against Clerk from all five of our regions, refreshed every couple of minutes. Your application talks to its own frontend API subdomain, so treat this as a platform signal rather than a reading of your instance.

My users cannot sign in but this page shows Clerk up. What should I check?

Check your keys and your domain configuration first. A publishable or secret key from a different instance, a development key still in place after a production deploy, or a domain that does not match what the instance expects will all break sign-in while Clerk is entirely healthy. The errors Clerk returns name the reason, which is a faster route to the cause than any status page.

Does a Clerk outage sign existing users out?

Not immediately. Sessions are carried by tokens that your application verifies, so users already signed in continue to work until their session needs refreshing. What fails during an outage is new sign-ins, sign-ups, and the token refresh that happens periodically, which is why a short incident affects far fewer people than the user count suggests.

Why did authentication break right after I deployed?

Because a deploy changes the things Clerk validates against. A new domain or preview URL that is not configured on the instance, an environment variable holding the wrong key, or a switch from development to production keys will each produce authentication failures within minutes of a release, with no platform incident behind them.

How is this page different from Clerk's own status page?

Theirs reports what Clerk's engineers have confirmed and published for each component. This page reports what our probes measured from outside their infrastructure, from five locations, whether or not an update has been posted yet. Ours arrives earlier and says less.