# Clerk status

> Is Clerk down? Live status, uptime history, and per-region response times for Clerk's authentication API from our own probes every 2 minutes.

Published: 2026-08-27 | Canonical: https://yoping.me/status/clerk

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/clerk. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.