A dedicated post-sign-in route rather than a fixed redirect. On the platform's own apex it identifies the platform owner and sends them to the operator console; everyone else goes to the app. Both destinations carry a parameter that clears the impersonation cookie so a previous 'act as this account' session can't carry into a new login.
Also called: where do I land after login · redirect after sign in · blank screen after login
- 1Sign-in points its forced redirect at this route so the branch happens server-side.
- 2The route checks whether it is on the platform apex or a tenant host.
- 3On a tenant host the identity lookup is skipped entirely, since the result would never be read.
- 4On the apex the owner check is raced against a 2.5 second timeout.
- 5Owner on apex goes to the platform console; everyone else goes to the app.
- 6Both redirects append ?as=clear, which middleware turns into a cookie deletion on the next request.
The timeout is the load-bearing part, and it is documented as such: 'CRITICAL: this call MUST be time-bounded… Clerk's Backend API is intermittently slow right after sign-in. Without a timeout, a slow/hung getUser left this server component pending forever — the browser sat on a BLANK /post-signin screen that only a manual refresh cleared.' Skipping the lookup on tenant hosts was 'pure latency (and blank-screen risk) for every tenant-member login.' Cookie clearing is delegated to middleware because 'server components can't call cookies().set() in Next 16.'
- A slow identity lookup left users staring at a blank page after sign-in.
- A stale impersonation cookie carried the previous account into a new login.
- Every user was dumped on the same landing page regardless of role.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →