# session.updated: signal, not sync
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.
## What to do on receipt
1. 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.
2. If you only need lifecycle (sign-in, sign-out, revoke), do not subscribe to session.updated at all. Fewer events is a feature.
3. 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.
4. Return 200.
## The trap
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.
## Checklist
- 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.