When Next.js errors only happen under real traffic

Some bugs never appear in testing. Everything passes, the developer cannot reproduce the problem, and yet a small percentage of real users keep hitting errors. Often it gets worse at busy times of day.

This is frustrating for everyone: the team cannot fix what it cannot see, and users lose trust in the product.

Why traffic changes the result

On a developer's machine there is one user, making one request at a time. In production, the server handles many users at the same moment. That creates situations that simply do not exist in testing:

• Two requests are handled at the same time and affect each other.
• A page is cached and later served to someone it was not built for.
• A slow response triggers a fallback that never runs when things are fast.

So the problem is not in a single page. It is in how the app behaves when many people use it at once.

Common causes

• Data shared between users by mistake. If one request stores information in a place other requests can reach, a user can see something that belongs to someone else. This is also a privacy risk.
• Caching the wrong thing. A page built for one user — with their name, language or cart — gets cached and shown to another.
• Stale pages. The page was generated a while ago, but the data in the browser is new, and the two do not agree.
• Timeouts under pressure. When the server is busy, some requests time out and the page shows different content than usual.

How to track it down

Since it cannot be reproduced on demand, the approach is different:

1. Collect good information from production. Which pages, which users, what time of day.
2. Test under realistic load, with many requests at once, not one at a time.
3. Look for anything shared between requests, because that is where most of these bugs live.

When to ask for help

These are some of the hardest bugs to find, because they only live in production. They often come together with other issues, like regular hydration errors and memory leaks.

If this sounds familiar, a Production Health Audit is a low-risk way to start: I review the code and send you a written list of what I found and how to fix it.