Clerk's reliability in summer 2026: every incident from July to September

When your authentication provider is down, your app is effectively down too. Users can't sign in, can't sign up, and in some setups can't even refresh the session they already have. For the thousands of apps that use Clerk, a Clerk incident becomes their incident.

That is why Clerk's record over the summer is worth a close look. Earlier in 2026 it was not good. This article reviews what happened after that, based on Clerk's public status page and its own postmortems.

The background: a rough February and March

Clerk published three postmortems in five weeks:

• 10 February: a failure at Clerk's DNS provider blocked authoritative DNS for Clerk's APIs for 2 hours 32 minutes. Clerk says that thanks to caching, more than 95% of requests still succeeded.
• 19 February: a routine automatic ANALYZE changed a database query plan. Queries slowed down, and more than 95% of traffic was rejected with HTTP 429 errors. Service came back after about 90 minutes, when the command was re-run by hand.
• 10 March: a failed live migration of Clerk's Google Cloud SQL database caused disk latency and lock contention. The outage lasted about 26 minutes, 15:57 to 16:23 UTC.

The March postmortem was unusually direct. Clerk wrote that "frustration is rightfully mounting" and that it had moved "the majority of our engineering team to reliability-focused projects for the foreseeable future." It also said that if Google would not stop live migrations for good, it would "need to migrate to another database provider or operate Postgres in-house."

July to September: what the status page shows

None of the summer incidents were full outages, and the ones we could check were marked as degraded performance. There were plenty of smaller ones, though. Durations below are measured from the first to the last update on each status page entry.

There were also two scheduled database maintenance windows:

• 19 September: Clerk warned of "a brief interruption of a few minutes, around 14:00 UTC." During it, operations that write data, including new sign-ins and sign-ups, OAuth endpoints and webhook emission, would be rejected with HTTP 503. Existing sessions and session verification were not affected.
• 26 September: a 30-minute window from 14:00 to 14:30 UTC, during which Clerk said some requests "may briefly fail or be slow."

The two maintenance windows fit Clerk's March plan, which was to move to planned replica promotions instead of surprise live migrations.

Reading the pattern

A few things stand out.

• The dependencies are still where the trouble is. The 4 August incident was an upstream provider. On 1 September a Google Cloud problem in us-central1 disrupted the connection between Clerk and its database provider, causing "connection churn and elevated error rates." Clerk's core still depends heavily on Google Cloud in one region.
• Some incidents are not about Clerk at all. The 4 September email delays came from Microsoft rate-limiting incoming mail, and Clerk noted that other senders were hit too. The Apple rejections affect only development instances. From your user's point of view, though, "the code never arrived" is still a sign-in failure.
• The failures are smaller. In the first quarter, the incidents that got postmortems were a DNS outage and two full database outages. This quarter's biggest events were partial degradations lasting an hour or a few hours. That is progress, but it is not a spotless record.

Keeping sign-in working when Clerk is not

You can't fix your provider, but you can limit how much of its trouble reaches your users.

1. Don't make every page depend on a live Clerk call. Clerk's 19 September notice confirms that session verification kept working while writes were paused. Apps that verify the session JWT locally, and only call the Backend API when they must, keep working through most degradations.
2. Treat 429 and 503 from Clerk as temporary. Retry with backoff, and show "sign-in is temporarily unavailable" instead of a generic error.
3. Make webhook handlers idempotent and tolerant of delay. Two of the summer's incidents were webhook delays. If your user provisioning depends on the user.created webhook arriving within seconds, add a fallback check.
4. Use Clerk's new diagnostics. SMS delivery events (added 17 September) and Email Logs show whether a code was delivered, rejected or delayed. SSO bypass (29 September) lets allowlisted users get in when their company's identity provider is down. Both are covered in our August–September roundup.
5. Plan for agents too. OAuth endpoints were among the operations paused on 19 September. If you have adopted Clerk's new agent and MCP auth features, connecting agents will fail during those windows as well.
6. Subscribe to maintenance notices. Both database windows were announced in advance on the status page.

isuptime tracks Clerk's live status together with 102 other services. When your sign-in page starts failing, it takes one click to tell whether the problem is Clerk, its cloud provider or your own code.

---

Sources

• Clerk status: incident history (Clerk)
• Postmortem: DNS Provider Outage (February 10, 2026) (Clerk)
• Postmortem: Clerk System Outage (February 19, 2026) (Clerk)
• Postmortem: Clerk System Outage (March 10, 2026) (Clerk)
• Elevated API Errors, 16 July 2026 (Clerk status page)
• Increased error rate, 1 August 2026 (Clerk status page)
• Increased API latency and errors, 4 August 2026 (Clerk status page)
• Elevated API latency, 31 August 2026 (Clerk status page)
• GCP incident in us-central1-b, 1 September 2026 (Clerk status page)
• Delayed email delivery to Microsoft recipients, 4 September 2026 (Clerk status page)
• Delays in webhook delivery, 16 September 2026 (Clerk status page)
• Scheduled database maintenance, 19 September 2026 (Clerk status page)
• Scheduled database maintenance, 26 September 2026 (Clerk status page)
• Development instances only: Apple rejecting emails (Clerk status page)