# Request timeout errors only in the Next.js app, JS SDK on the same network is fine

Asked by Ken Watanabe on 2025-11-06. Tags: nextjs, timeout, errors.

I build for users in Nairobi where connectivity can be slow and variable, so I
watch latency behavior closely. We run two properties: one on the plain
JavaScript SDK and one on `@croct/plug-next`. The Next.js one intermittently
logs "Request timeout" errors during traffic from mobile networks, while the JS
SDK property never times out under the same conditions.

Before I start tuning blindly: do the two SDKs actually behave differently
around timeouts, or should I be looking for a problem in our infrastructure?
I would appreciate a precise answer if anyone knows the defaults.

## 2 answers

### Accepted answer from Aisha Bello (2025-11-06)

They do behave differently, and the difference explains exactly what you are
seeing. The default fetch timeout is 5000ms in the JS SDK but only 2000ms in
the Next.js SDK. The Next.js default is tighter because a server-side fetch
blocks the whole page render, so it fails fast by design. The same network
latency that sails through on the JS property can trip the 2 second limit on
the Next one.

Two things to do:

1. Raise the limit where it makes sense for your audience via the
   `defaultFetchTimeout` option.
2. More importantly, always pass a `fallback` to your content calls. With a
   fallback, a timeout degrades gracefully to default content instead of
   surfacing as an error. For a low-bandwidth audience this is the setting
   that actually protects the user experience.

With both in place the timeout stops being an error and becomes a controlled
worst case.

#### Reply from Ken Watanabe (2025-11-07)

Precise indeed, thank you. Raised the timeout to 4000ms and added
fallbacks everywhere; the error rate dropped to zero overnight.

### Answer from jorge_mtz (2025-11-07)

Small caution from someone who tuned this before: do not just crank
`defaultFetchTimeout` way up on the server side. Every millisecond you allow
is a millisecond your slowest visitors might wait for first byte. The
fallback is the real fix, the timeout number is just where you draw the line
between personalized and default content. We settled on 3000ms after looking
at our own latency distribution rather than picking a round number.