Full static rebuild or incremental static regeneration for hourly content updates?

Goal

Serve a content-heavy Jamstack site with hourly CMS updates while keeping CI build times manageable.

Full static regeneration guarantees fresh HTML after every publish but rebuilds all pages, increasing build duration and compute cost as the site grows. Incremental static regeneration updates individual pages on demand or after a revalidation interval, reducing build load but allowing stale HTML until the next revalidation succeeds. Stale-while-revalidate edge caching can mask latency, yet the inconsistency window depends on cache TTL, webhook reliability, and platform-specific fallback behavior.

Unresolved trade-off: which approach better balances freshness guarantees against build cost when revalidation may fail or webhooks are delayed, and how to bound the staleness window without a full rebuild.

• Does full static rebuild remain viable as page count scales, or should ISR handle the majority of updates?
• What is the maximum acceptable stale-content window if on-demand revalidation fails?
• Should time-based revalidation supplement webhook-triggered revalidation to cover missed CMS events?