Hi Devansh,

If those Sentry events cluster around deploy times, I’d treat this as version skew first.

With dynamic(() => import(...), { ssr: false }), the browser may not request that CSS/JS chunk until later. If the user loaded HTML/JS from an older deployment, then a new production deployment goes live, that old client can later try to fetch a chunk URL that no longer exists on the deployment it is being routed to. That usually shows up as:

1
Loading CSS chunk failed
2
/_next/static/css/<hash>.css
3

A good way to confirm is to check the failed asset request in Sentry or browser devtools:

1
status: 404 or failed network request
2
url: /_next/static/css/...
3
time: close to a new deployment
4

I’d also compare one failed chunk URL directly:

1
curl -I https://your-domain.com/_next/static/css/FAILED_HASH.css
2

If it returns 404, and the event happened after a deployment, that strongly points to stale client/runtime vs new deployment assets rather than a normal React error.

A few mitigations I’d check:

• enable/verify Vercel Skew Protection if your plan/project supports it

• make sure HTML/RSC responses are not being cached by an extra CDN/proxy in front of Vercel

• do not override caching for /_next/static/*

• keep deployment retention / skew max age long enough for typical user sessions

• add a one-time reload fallback for chunk-load failures so users recover instead of staying on a broken page

Vercel’s Skew Protection docs describe the exact problem: keeping framework-managed JS/CSS/data requests pinned to the deployment that served the original page:

https://vercel.com/docs/skew-protection

I would not remove dynamic() just because of this. Dynamic imports can make the issue more visible because chunks are requested later, but the underlying thing to prove is whether the failed CSS URL is from an older deployment and returning 404 after rollout.