Exact fallback behavior when a personalized fetch fails on a Sanity site

Went through the same due diligence last quarter, so in order:

1. Your Sanity content stays as the fallback. Every fetch accepts explicit fallback content, and if the request fails the fallback renders instead of an error. In the JS SDK you can also catch the rejection yourself and return defaults, something like croct.fetch('home-hero').catch(() => ({content: {...}})). In @croct/plug-next you pass it directly:

   import {fetchContent} from '@croct/plug-next/server';
   const {content} = await fetchContent('home-hero', {    fallback: defaultHeroFromSanity,});

2. The defaults differ, and it trips people up: 5000ms in the JS SDK versus 2000ms in the Next.js SDK. The Next.js default is tighter because the fetch happens server-side and blocks rendering. Both are configurable via defaultFetchTimeout.

3. Per fetch, as shown above. Each call carries its own fallback, so the hero and a sidebar module can degrade differently.

4. A paused experience shows the default slot content, so visitors get the plain Sanity version. Nothing errors, the personalized layer just steps aside.

Net effect during an outage or timeout: the site renders exactly what it would render without personalization, just with the fallback content you supplied.