Clerk will perform planned database maintenance on Saturday 19 September 2026 between 13:30 and 14:30 UTC. Signed-in end users stay signed in and your application keeps working for them throughout.

  Within that window we expect a brief interruption of a few minutes, around 14:00 UTC, during which operations that write data — including new sign-ins and sign-ups — will be temporarily rejected. The window is wider than the expected impact to allow for preparation and verification.

  What continues to work, including during the interruption

  - Active sessions. Users already signed in remain signed in, and their session tokens continue to refresh normally. No one is signed out.

  - All read operations across the Frontend and Backend APIs — users, organizations, sessions, and other resources.

  - Session verification. Your backend can continue to verify session tokens as usual.

  What is briefly unavailable during the interruption

  - New sign-ins and sign-ups. Users not already signed in will not be able to authenticate for those few minutes.

  - All write operations on the Frontend and Backend APIs — creating or updating users, organizations, memberships, invitations, and similar.

  - The Clerk Dashboard remains readable, but changes cannot be saved.

  - Clerk as an OAuth provider — /oauth/token, /oauth/authorize, /oauth/device_authorization, /oauth/end_session are unavailable.

  - Webhook events are not emitted for activity during the interruption.

  What you will see

  Affected requests return HTTP 503 with the error code maintenance_mode. If your integration retries on 503, requests will succeed once the interruption passes — no action is required on your side. We recommend not scheduling bulk imports, migrations, or backfills against the Clerk API during this window. 

  We will post updates here as the maintenance begins and completes.

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

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

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

We've resolved the issue with our upstream provider.

All systems are operational

Custom domain provisioning is fully operational again

We have confirmed that error rates have returned to baseline.

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.

All domains have been processed from this incident.

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

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

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

Services are up and running.

Systems are fully operational

All systems are operational

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 resolved the issue at 21:56 UTC. No data was lost. To prevent recurrence, we are rolling out a change to detect and self-heal from such failures. We apologize for the disruption