Clerk event: session.updated is noisy, do not mirror sessions off it

TL;DR

Fires when session data changes: last-active timestamps, metadata writes, factor updates. If you only need lifecycle (sign-in, sign-out, revoke), do not subscribe to session.updated at all.

Steps

1. Fires when session data changes: last-active timestamps, metadata writes, factor updates. It fires far more often than the other session events and carries incremental state, not lifecycle transitions.
2. Decide BEFORE subscribing what you want from it. Valid uses: updating a "last active" display, reacting to a metadata flag your own code set, feeding an anomaly detector.
3. If you only need lifecycle (sign-in, sign-out, revoke), do not subscribe to session.updated at all. Fewer events is a feature.
4. If you subscribed, make the handler cheap and idempotent: read the fields you care about, ignore the rest, return 200 fast. Never do heavy work here; this event's volume punishes slow handlers.
5. Return 200.
6. Mirroring sessions. Agents sometimes build a local session table keyed off created/updated/ended and then fight drift forever: missed deliveries, reordered events, and TTL differences between Clerk and the mirror. Your source of truth for "is this session valid" is a live check against Clerk, not a webhook-maintained copy.
7. - If your handler does more than a quick field read and a targeted write, move the work to a queue and return 200 immediately.

• session.updated volume scales with user activity. Load-test your endpoint against your busiest hour, not your average.
• Prefer reading session claims per request for auth decisions. Webhooks tell you what happened; they are not an auth cache.

When to use

You are seeing this: It fires far more often than the other session events and carries incremental state, not lifecycle transitions. Use this skill when you run into "Clerk event: session.updated is noisy, do not mirror sessions off it".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Clerk's event catalog (Dashboard → Webhooks → Event Catalog) lists session.updated among the session events. The overview guide warns webhooks are async and suited to background tasks, not synchronous flows. Verified live at https://clerk.com/docs/guides/development/webhooks/overview.