Skip to service list
IU

Clerk this week: self-serve Directory Sync, accountless setup and a Dashboard slowdown

5 min read

What happened at Clerk between 28 September and 5 October 2026: customers' IT admins can now set up Directory Sync themselves, new projects no longer need a Clerk account, the Dashboard had a slow afternoon, and Apple is still rejecting emails from development instances.

Clerk had a quiet first week of October compared with its summer. There were two releases on 30 September, one short Dashboard incident on 1 October and one email problem that has now been open for a week. None of it stopped users signing in.

This is a short update to our three longer Clerk pieces from last week: the August–September changelog roundup, the summer incident review and the agent and MCP auth explainer.

At a glance

Date What happened Type
28 Sep – Apple rejecting emails from development instances Incident, still open
30 Sep Self-serve Directory Sync Release
30 Sep Accountless setup for Next.js Release
1 Oct Dashboard increased latency Incident, resolved 2 Oct

All times below are UTC, as shown on Clerk's status page.

Self-serve Directory Sync (30 September)

Directory Sync keeps a customer's user list in step with their identity provider. When their IT team adds, changes or removes someone in Okta or Entra, the change reaches your app without anyone having to sign in first. Until now, you had to set this up for each customer in the Clerk Dashboard.

The 30 September release moves that setup into the Security tab of the <OrganizationProfile /> component, next to self-serve SSO. The customer's own admin does the work. Clerk describes a three-step flow:

  1. Configure. Clerk generates a SCIM endpoint URL and a bearer token for the admin to paste into their identity provider. Google Workspace is different: the admin uploads a service account key and enters the email of a Workspace admin account for Clerk to act as.
  2. Review attributes. The admin checks how standard attributes are mapped.
  3. Test provisioning. The admin assigns a test user and confirms the sync works.

Clerk picks the right flow for the connection type. It lists Okta Workforce, Microsoft Entra ID, Google Workspace, and custom SAML and OIDC connections.

Three details are worth knowing:

It requires Clerk Organizations and self-serve SSO. It is free in development. In production it needs the Pro or Business plan with the B2B Authentication add-on.

This is the third self-serve release in a row, after SAML on 26 June and OIDC on 31 July. Together with SSO bypass and multiple connections per Organization, a B2B app on Clerk can now hand most enterprise onboarding to the customer.

A cost to plan for

Clerk's pricing page now says: "Billing for Directory Sync connections starts January 1, 2027." One connection per app is included. After that the page lists $75 a month each for connections 2 to 15 and $60 each for 16 to 100. Self-serve setup makes it easy for customers to add directories, so count yours before January. Our Clerk pricing guide has the full breakdown.

Accountless setup (30 September)

The same day, Clerk announced that a new Next.js project no longer needs a Clerk account to get started. Running npx clerk@latest init while signed out creates what Clerk calls an accountless application, installs the SDK, scaffolds the integration and writes development keys to .env.local.

Clerk's reason is AI coding agents: "Agents stall on account creation." When you want to keep the app, npx clerk@latest auth login attaches it to your account. Clerk is clear that "Unclaimed applications and development keys are not production-ready."

We cover this, and the rest of the Clerk CLI's first six months, in Clerk's CLI and accountless setup.

Dashboard latency (1 October)

At 15:44 on Thursday 1 October, Clerk reported "increased latency for the Clerk Dashboard." The affected components were the Dashboard, Dashboard analytics and Dashboard search. The status page classed it as degraded performance.

Time (UTC) Status Update
1 Oct, 15:44 Investigating Increased latency for the Dashboard
1 Oct, 16:00 Identified "Latency is back to normal." Cause identified, fix in progress
1 Oct, 18:34 Monitoring Fix implemented
2 Oct, 06:29 Resolved Incident closed

By Clerk's own updates, the slow period lasted about 16 minutes. The incident stayed open for almost 15 hours because Clerk kept monitoring overnight. Clerk has not published a cause.

This did not affect your users. The Dashboard is where you manage your instance. Sign-in, sign-up, sessions and the APIs your app calls are separate components, and none were listed. A slow Dashboard matters when you need it urgently, for example to ban a user. For that reason it is worth knowing that user management is also available through the Backend API, which was not affected.

Apple rejecting development emails (28 September, still open)

On 28 September at 15:23, Clerk posted that "emails sent only from development instances to Apple email addresses (icloud.com, me.com) are being rejected by Apple." It said it had contacted Apple. As of 5 October the incident is still marked Identified, with no further update.

Production instances are not affected. If you are testing a sign-up flow in development with an iCloud address and the code never arrives, this is the cause. Clerk suggests using test email addresses or an address at another provider until it is fixed.

What it means for developers

isuptime checks Clerk's status every few minutes, together with 102 other services. If sign-in breaks, that page tells you quickly whether Clerk has acknowledged a problem.


Sources

Live status for the services in this post

Checked continuously against each provider's own status feed.