#edge-cache

Jacob Paris Can you share what version of Next.js you're on? Next 16 uses Turbopack instead of Webpack so you shouldn't be getting errors like this on up to date versions

Ngoiyaeric I fixed it with sse-error-extension-conflict

Ryu Hi Aman, I’d check `use cache` itself first. Even if you did not set `export const revalidate = X`, `use cache` has its own cache lifetime behavior. The default profile includes a server-side revalidation window, so it may not behave like “only regenerate when I call `revalidateTag`.” That default is described here: https://nextjs.org/docs/app/api-reference/directives/use-cache For your case, I’d try to separate three possible triggers: 1. **`use cache` default revalidation** Add an explicit `cacheLife()` profile to the cached function/component so you know exactly when it can revalidate, instead of relying on the default. 2. **Bot or prefetch traffic** A “couple real visitors” can still create many page reads if crawlers, link previews, uptime tools, or `next/link` prefetching touch many slug pages. If you have an index page linking to hundreds of dynamic routes, try temporarily setting `prefetch={false}` on those links and see if ISR reads drop. 3. **Hidden requests that do not show up where you expect** Cached page hits may not look like normal server logs. I’d use Vercel Observability / Runtime Logs and filter by path, user-agent, and rendering/cache mechanism around the ISR spike time. If needed, add very temporary middleware for `/[slug]` that logs only non-sensitive fields like path, user-agent, referer, and timestamp. If the timestamps of ISR reads line up with bot/prefetch requests, then the cache is being touched by real HTTP traffic, just not human visitors. If ISR writes continue for slugs with no matching request at all, then I’d share a small sample of affected paths and timestamps, because that would be much stronger evidence of something internal or unexpected.

Jacob Paris Unfortunately we can't unpause your account until the usage rolls over back below its limits, otherwise it would repause immediately. You'll need to either upgrade or wait it out

Deji Ice how long do i have to wait?

Pauline P. Narvas Hey! First, try a quick cache clear to see if that fixes it. Head over to your project dashboard and open the **Deployments** tab. Find the latest deployment, hit the three dots, and select **Redeploy.** Just make sure you uncheck the **Use existing Build Cache** option before you start the redeploy. If that doesn’t do the trick, there are a few things we should look into. You might want to check the **Project Settings** under **Git** to confirm exactly which branch you’re deploying from. Take a look at your build logs too. Sometimes there are hidden warnings in there even if the deployment says it was successful. Also, let me know if you are using **SSG** or **ISR** for this project. Also, it might sound silly but did you deploy the latest changes to production? :)

Andrestm1205 I already did everything you suggested. I also disconnected GitHub and connected it again, and it still doesn’t update even though it does the pull request, the merge PR… everything, but it doesn’t deploy the updates. i need solucions.

Community Backoffice Hey! To help debug your v0 project, could you share your **v0 chat link**? It looks like `https://v0.app/chat/...` — you can copy it from your browser's address bar while in the chat. You'll also need to unlist the chat so our team can view it — here's how: https://v0.app/docs/sharing This helps the team reproduce what you're seeing much faster. Thanks!

Ryu 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: ``` Loading CSS chunk failed /_next/static/css/<hash>.css ``` A good way to confirm is to check the failed asset request in Sentry or browser devtools: ``` status: 404 or failed network request url: /_next/static/css/... time: close to a new deployment ``` I’d also compare one failed chunk URL directly: ``` curl -I https://your-domain.com/_next/static/css/FAILED_HASH.css ``` 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.

Pauline P. Narvas Can you try clearing Vercel’s Edge Cache? Go to your project dashboard → Settings → Functions → Purge Everything. This will clear all cached content. Give that a go and let us know how you get on!

Pauline P. Narvas That is odd! Do you have a URL handy for us to take a look? Otherwise, I recommend redeploying if you haven’t already. Make sure build cache is off!

Al441395 Hi! It doesn’t look like an edge cache issue. A Vercel `NOT_FOUND` response usually means there is no active deployment serving that domain, rather than stale cached content. Since the request is reaching Vercel (you have an `x-vercel-id`) and you already tried purging the CDN cache, it’s unlikely that caching is the problem. This typically happens when there is no successful “Ready” deployment, the production alias is missing, or the domain is not pointing to an active deployment. In other words, Vercel isn’t finding anything to serve for that domain at the moment. I’d recommend checking your deployments to make sure there is one in a “Ready” state, that it’s assigned to production, and that the domain is correctly connected to it. If everything looks off, try redeploying and promoting it to production. Hope this helps

Pauline P. Narvas Hey there! Your cached build issue is likely happening because Vercel is using stale build artifacts. **First, let's do a clean deploy without any cached data:** - Go to your project dashboard → Deployments tab - Click the three dots on your latest deployment → Redeploy - **Uncheck "Use existing Build Cache"** → Deploy Alternatively, you can force a clean build using: - Add environment variable: `VERCEL_FORCE_NO_BUILD_CACHE=1` - Via CLI: `vercel --prod --force` **Since your Vite project builds to `dist/public`, you'll want to make sure this is configured correctly:** - Go to Project Settings → Build & Development Settings - Set Output Directory to `dist/public` (not just `dist`) - Turn OFF any Production Override toggle if it's enabled **If you have a `vercel.json` file in your project**, it might be overriding your dashboard settings. Check if you have something like: ```json { "outputDirectory": "dist/public", "framework": "vite" } ``` Could you also clarify what "Manus checkpoints" refers to? Let me know if the clean deploy fixes it or if you're still seeing issues!