This week our most important pages quietly returned 500 Internal Server Error to every signed-out visitor for about a day. Signed-in users (including me) saw nothing wrong. Here is what happened, how we found it, and the fix.

The symptom

Learners started messaging that "the website is stuck". The home page, Explore and Teachers loaded fine. But every skill page, lesson page and exam-prep page failed:

/              200
/skills         200
/skills/excel   500
/skills/tally   500
/study/...      500

It failed on every request, not intermittently, so it was not load or memory.

The log line

The container logs had thousands of these:

Error: Page changed from static to dynamic at runtime /skills/excel, reason: headers
see more here https://nextjs.org/docs/messages/app-static-to-dynamic-error

The root cause

Those routes were set up for ISR (cache the rendered page for an hour):

export const revalidate = 3600;
export function generateStaticParams() { return []; }

But the same pages are personalised. They show a "Get a free certificate" card only to signed-out visitors, and a Continue button to signed-in learners. To know who is visiting, a shared helper reads the request:

export const getViewer = cache(async () => {
  const bearer = readBearerHeader(await headers()); // mobile app token
  ...
  const claims = await claimsFromCookies((await cookies()).getAll());
  ...
});

A page cannot be both "render once and reuse for an hour" and "read this visitor's headers". Next.js detects that conflict during a background render and throws, so the request gets a 500.

Why did it work for weeks? Previously cached copies kept being served while regeneration failed in the background. After a deploy and a container restart, the cache was cold, so every signed-out visit triggered a fresh render, and every fresh render threw.

The fix

The pages are personalised, so they should be dynamic. On the 30 affected routes:

- export const revalidate = 3600;
+ export const dynamic = "force-dynamic";

After deploying, every page returned 200 in 0.3–0.7 s, and the error count in the logs dropped to zero.

One more trap: our deploy script undid the hotfix

I committed the hotfix directly on the server and ran the deploy script. The site stayed broken. The script does:

git fetch origin "$BRANCH"
git reset --hard "origin/$BRANCH"

The server's origin is a git bundle uploaded from my machine. The reset threw away the local commit and rebuilt the old code. The fix was to rebuild the bundle from the hotfix commit, then deploy. Lesson: know exactly what your deploy script resets to before you hotfix on the box.

What we changed so it doesn't happen silently again

1. Uptime monitoring on a deep page, not just the home page. The home page was 200 the whole time. We now check a skill page every 5 minutes too.
2. Personalised pages are dynamic by default. If we want the cache back, the signed-in parts must move to the client, so the server HTML is the same for everyone.
3. Test as a signed-out visitor after every deploy. Founders are always signed in, so we never see what new visitors see.

Takeaways

• If an ISR page (or anything it renders) calls `headers()` or `cookies()`, Next.js can fail at runtime, not at build time.
• "Works for me" means little when you are signed in.
• Monitor the pages your users actually land on.

I'm building YUNOVA in public: a free platform for learning job skills from the best YouTube teachers, with practice questions and free certificates. If you are learning Excel, start here: yunova.in/skills/excel.