Clerk

Failure mode: The text does not say enough to tell. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-10-01 15:44 UTC

   We are investigating increased latency for the Clerk Dashboard!

2. identified 2026-10-01 16:00 UTC

   Latency is back to normal. We have identified the issue and are actively working on fixing it.

3. monitoring 2026-10-01 18:34 UTC

   We have implemented a fix for this incident and are monitoring to ensure the issue does not recur.

4. resolved 2026-10-02 06:29 UTC

   The incident is now resolved

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with high confidence (taxonomy v0.2).

1. identified 2026-09-28 15:23 UTC

   We discovered today that emails sent only from development instances to Apple email addresses (icloud.com, me.com) are being rejected by Apple. We have reached out to Apple to inquire further and are hoping for a swift resolution on their end. In the meantime, we recommend using...

2. resolved 2026-10-19 17:39 UTC

   Despite extensive efforts to reach out to Apple about this issue we still do not have a resolution from them. As this incident has been ongoing for over a month, we have decided to move towards displaying a warning message on sign in from development instance when apple emails...

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: Data delayed, stale, lost or corrupted, or needing replay after recovery. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

1. identified 2026-09-16 12:31 UTC

   Currently there are delays for some customers in webhook delivery. The issue has been identified and we are working towards a resolution

2. monitoring 2026-09-16 13:24 UTC

   A mitigation has been applied. Webhooks are being delivered at the normal pace. We continue monitoring

3. resolved 2026-09-16 13:39 UTC

   All systems are working

4. investigating 2026-09-16 14:33 UTC

   Delays in webhook deliveries for some customers

5. monitoring 2026-09-16 14:58 UTC

   Webhook delivery is normal at the moment. We are closely monitoring

6. resolved 2026-09-16 15:20 UTC

   All systems are functional

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

1. investigating 2026-09-04 10:06 UTC

   We are seeing delays in email delivery for recipients on Microsoft-hosted mailboxes (Outlook.com, Hotmail, Microsoft 365). Affected emails, including one-time passcodes and verification links, may arrive late or require re-sending. Emails to other providers are delivering...

2. identified 2026-09-04 11:37 UTC

   We've found the cause. Emails to Microsoft-hosted mailboxes (Outlook.com, Hotmail, Microsoft 365) are being rate limited on the receiving side, and other email senders are seeing the same thing today. Emails are still accepted but some are delayed by several minutes while...

3. monitoring 2026-09-04 13:33 UTC

   Delivery to Microsoft-hosted mailboxes returned to normal at about 12:40 UTC and delayed emails have been delivered. We are monitoring to confirm it stays that way.

4. resolved 2026-09-04 14:40 UTC

   Delivery to Microsoft-hosted mailboxes has been normal since 12:40 UTC. All delayed emails were delivered. This incident is resolved.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A zone, region or data center became unavailable. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

Names an upstream provider: Google Cloud.

Started during Google Cloud: Multiple products in us-central1-b are experiencing network service degradation..

1. monitoring 2026-09-01 15:48 UTC

   GCP has several incidents open in us-central1 currently. We are proactively monitoring impact to customer traffic and have so far noted impact to analytics and some of our metrics. We will update shortly with further information.

2. monitoring 2026-09-01 16:13 UTC

   Dashboard analytics have recovered and we're continuing to monitor for additional impact from the GCP incidents.

3. monitoring 2026-09-01 17:30 UTC

   The path between our services and the database provider is currently impacted, leading to connection churn and elevated error rates.

4. monitoring 2026-09-01 17:49 UTC

   We are noting recovery in the path between our services and the database provider, but latency and error rate are still elevated above baseline.

5. monitoring 2026-09-01 18:35 UTC

   latency metrics have returned to baseline, and we're seeing recovery in error rates. We are continuing to monitor for any signs of resurgence and will update accordingly.

6. resolved 2026-09-01 19:13 UTC

   Latency and error rates have held steady since the last update. We will re-open if there is a resurgence in errors or latency.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: Traffic surge or denial-of-service attack. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

1. investigating 2026-08-31 13:42 UTC

   We're investigating elevated latency and intermittent timeouts affecting Clerk API requests. Some customers may see slow responses when loading user and organization data. Our team is looking into it and will post another update once we have more information.

2. identified 2026-08-31 14:18 UTC

   We identified elevated traffic affecting the Backend API and user-related requests, causing increased latency and intermittent failures. We've applied mitigation and are monitoring its effect. We'll provide another update once we confirm service stability.

3. monitoring 2026-08-31 15:22 UTC

   Mitigation has been applied and API performance has stabilized. We've deployed additional safeguards and are monitoring to confirm continued stability.

4. resolved 2026-08-31 15:40 UTC

   API performance has remained stable following mitigation. This incident has been resolved.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with high confidence (taxonomy v0.2).

1. investigating 2026-08-04 23:03 UTC

   We are currently investigating an increase in latency and errors in our FAPI and BAPI services.

2. identified 2026-08-04 23:14 UTC

   We've identified the issue with our upstream provider and are working on resolution.

3. monitoring 2026-08-04 23:29 UTC

   Our upstream provider has applied a fix and we've seen latency and errors subside. We continue to monitor the situation.

4. resolved 2026-08-04 23:40 UTC

   We've resolved the issue with our upstream provider.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: The text does not say enough to tell. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. identified 2026-08-01 10:04 UTC

   Elevated error rate across all service

2. resolved 2026-08-01 10:04 UTC

   All systems are operational

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with high confidence (taxonomy v0.2).

1. investigating 2026-07-31 12:23 UTC

   Elevated error rates when provision a custom domain. Existing live applications and sign-in/sign-up and sessions are not affected.

2. identified 2026-07-31 12:28 UTC

   Domain provisioning is currently delayed due to degraded availability at a third-party infrastructure provider. Existing live applications and session/sign-in/sign-up traffic are not affected. Affected domains will provision automatically once the provider recovers. No action is...

3. monitoring 2026-07-31 12:52 UTC

   A fix has been implement by the downstream provider. We are closely monitoring.

4. resolved 2026-07-31 13:00 UTC

   Custom domain provisioning is fully operational again

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: Exhausted memory, disk, CPU, queues, connection pools or quotas. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-07-16 13:04 UTC

   Reports of 429 error responses from API endpoints

2. investigating 2026-07-16 13:08 UTC

   We're continuing to investigate.

3. investigating 2026-07-16 13:27 UTC

   We're continuing to investigate.

4. monitoring 2026-07-16 13:45 UTC

   We've deployed a fix and are seeing error rates decrease. We are monitoring.

5. resolved 2026-07-16 14:01 UTC

   We have confirmed that error rates have returned to baseline.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: Exhausted memory, disk, CPU, queues, connection pools or quotas. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-07-16 07:56 UTC

   There is increased latency on our APIs. We are investigating.

2. resolved 2026-07-16 07:58 UTC

   There was a service degradation on our caching layer that affected the latency of our APIs. The caching layer is back to normal and latency dropped to normal levels.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

1. monitoring 2026-07-12 22:05 UTC

   We are observing elevated errors while provisioning domains

2. monitoring 2026-07-12 23:10 UTC

   The underlying issue has been resolved, a downstream provider incident. Domains which failed to be provisioned are now being reprocessed and succeeding. We are continuing to monitor.

3. resolved 2026-07-13 01:37 UTC

   All domains have been processed from this incident.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: The text does not say enough to tell. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-07-09 20:38 UTC

   We are observing evaluated errors in account portal and actively investigating the source of the problem

2. resolved 2026-07-09 20:43 UTC

   The underlying issue has been identified and the Account Portal is now fully functioning again.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: Data delayed, stale, lost or corrupted, or needing replay after recovery. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

1. investigating 2026-07-01 17:12 UTC

   We are investigating delays in webhook delivery. We have deployed mitigations and are continuing to monitor.

2. resolved 2026-07-01 17:26 UTC

   We have identified the cause of the delays and our mitigations have been successful. We are continuing to monitor webhook delivery.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: CDN or edge layer failed or served bad content. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-06-18 18:26 UTC

   SVGs are not loading properly, the team is investigating a fix

2. monitoring 2026-06-18 20:13 UTC

   A fix has been deployed and we're seeing improved rates of resolution on the SVGs

3. resolved 2026-06-18 20:23 UTC

   A fix has been published and confirmed it's now resolving SVGs correctly

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: The text does not say enough to tell. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-06-18 15:32 UTC

   Dashboard Overview page is not loading properly.

2. identified 2026-06-18 15:50 UTC

   Issue identified

3. monitoring 2026-06-18 15:59 UTC

   A fix has been implemented, we are currently monitoring the affected services.

4. resolved 2026-06-18 16:18 UTC

   Services are up and running.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

1. investigating 2026-06-15 15:17 UTC

   Elevated errors were observed in platform API when communicating with an upstream service

2. resolved 2026-06-15 15:26 UTC

   Systems are fully operational

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with high confidence (taxonomy v0.2).

1. identified 2026-06-12 14:48 UTC

   An upstream provider has a partial outage. Errors or delays might be encountered when a Clerk application goes live. We are monitoring the situation.

2. monitoring 2026-06-12 15:03 UTC

   A fix has been implemented by the upstream provider. We are monitoring the results

3. resolved 2026-06-12 15:29 UTC

   All systems are operational

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: Network, DNS, routing or connectivity failure. Root cause: A bug in the vendor's own code. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

1. investigating 2026-06-09 21:56 UTC

   Endpoints that use analytics (such as dashboard charts) are encountering timeouts. We are investigating.

2. monitoring 2026-06-09 22:11 UTC

   We've mitigated a connection issue with the Analytics API and are now monitoring.

3. resolved 2026-06-09 22:37 UTC

   Between 21:21 and 21:56 UTC on June 9, 2026, a portion of requests to our Analytics service failed and Dashboard charts may have failed to load. The cause was a database connection that had been silently closed upstream but was still being reused by our connection pool. We...

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: The text does not say enough to tell. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-05-28 19:16 UTC

   We are investigating elevated level of internal errors in APIs.

2. monitoring 2026-05-28 19:30 UTC

   We have deployed a mitigation to our APIs and observed errors return to a normal level. We are continuing to investigate and monitor.

3. resolved 2026-05-28 20:32 UTC

   APIs have returned to normal operation.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: The text does not say enough to tell. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-05-26 21:19 UTC

   We are investigating elevated 500s affecting a subset of our API responses.

2. investigating 2026-05-26 21:32 UTC

   We have implemented remediation for our session service. We are still investigating remediation for the Dashboard and backend API.

3. investigating 2026-05-26 21:47 UTC

   We are deploying a mitigation for the Dashboard and Backend API

4. investigating 2026-05-26 21:53 UTC

   We are continuing to work to deploy a mitigation for the backend API and Dashboard issues.

5. investigating 2026-05-26 22:00 UTC

   We have deployed a fix and are observing rapid decline in error rates. We continue to monitor the situation.

6. monitoring 2026-05-26 22:08 UTC

   We have deployed a fix for this issue and our services appear to have returned to normal operation. We continue to monitor.

7. resolved 2026-05-26 22:26 UTC

   The root cause has been identified and addressed. We will continue to monitor going forward.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with high confidence (taxonomy v0.2).

1. investigating 2026-05-22 15:48 UTC

   There is an ongoing issue with one of our upstream providers which is impacting the provisioning of domains.

2. monitoring 2026-05-22 16:53 UTC

   Our upstream provider has implemented a fix for domain provisioning. We are seeing signs of recovery and are continuing to monitor the situation.

3. resolved 2026-05-22 21:43 UTC

   Systems are back to normal.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A provider or third-party service this vendor depends on failed. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with high confidence (taxonomy v0.2).

1. investigating 2026-05-14 20:37 UTC

   Our upstream database provider is facing issues with a specific region where our database is deployed, we're currently seeing intermittent errors on the SCIM services. The rest of clerk is not affected

2. monitoring 2026-05-14 20:47 UTC

   We're monitoring the database health, no error has been found on the last 10 minutes.

3. resolved 2026-05-14 21:05 UTC

   The upstream provider marked the issue as resolved, we're continuing to monitor the database, but no error was observed.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: A code release introduced the failure. Root cause: The vendor does not say why it happened. Tagged by claude-haiku-5-5 with low confidence (taxonomy v0.2).

1. investigating 2026-05-11 15:00 UTC

   Some customers are encountering an issue where the root route at the Accounts Portal is returning 404 and not redirecting to the appropriate page.

2. monitoring 2026-05-11 15:30 UTC

   We have deployed a mitigation and are observing.

3. resolved 2026-05-11 17:19 UTC

   The issue has been resolved.

Excerpts are shortened. Read the full incident on Clerk's status page.

Failure mode: Network, DNS, routing or connectivity failure. Root cause: A failure at a provider or vendor they depend on. Tagged by claude-haiku-5-5 with medium confidence (taxonomy v0.2).

1. investigating 2026-05-08 11:02 UTC

   We are currently investigating an issue where Clerk JS cannot be downloaded, preventing sign in or sign up when using Clerk components. We believe this is related to DNS [clerk.[your_domain].com](http://clerk.domain.com "clerk.[your_domain].com"), and are working to discover the...

2. monitoring 2026-05-08 11:38 UTC

   We have observed that failures to load Clerk JS (reported by [dashboard.clerk.com](http://dashboard.clerk.com)) last occurred 30minutes ago, and this would correlate with failures reported from Clerk applications. We are in contact with our DNS providers to understand the root...

3. resolved 2026-05-08 14:40 UTC

   We continue to work with our DNS provider to discover the source of the issue. We currently believe approximately 0.37% of traffic was impacted by being unable to resolve DNS of the CDN that provides ClerkJS.

Excerpts are shortened. Read the full incident on Clerk's status page.