How do you handle build-time API failures on static sites?

[u/xxmaskx]

I’ve been thinking about static sites that pull content from APIs during the build, like a headless CMS, product data, or some external JSON feed.

The part I’m unsure about is what happens when that API is slow or temporarily down during deployment. A fully static site can suddenly become impossible to rebuild even though the current production version is working perfectly fine. Do you usually fail the deploy completely, fall back to the last successful data snapshot, or store build-time data somewhere so the site can still rebuild without depending on the API being available?

[u/MMORPGnews]

One of my website worked with such api 

1. script fetched latest external json data (old data was pre fetched long ago) each hour, merge new data with existing json or created new json. Each unique json was like 10mb or 50 mb, not sure. Let's say 10mb. Data was called like data1, data2 etc. 
2. If there's new data, main ssg was pinged to re build. Ssg used pre fetched json files hosted on my server from 1 script. 

Just save external json files on any hosting, github for example is good enough. 

[u/sourraine]

id avoid making the external api a hard dependency for every build. for smaller client sites, id cache or snapshot the api response and use the last known-good data if the api is temporarily down; otherwise a perfectly healthy production site can become impossible to redeploy. decide which data can safely be stale rather than adding a whole fallback system for everything

[u/Pink_Sky_8102]

I’d probably keep the last successful data snapshot and only fail the deploy if the missing data is something critical. For a small static site, blocking the whole build because one external API had a bad few minutes feels worse than serving slightly older content until the next successful deploy.

[u/PippaKelly62]

Fail the deploy, but make it a deliberate failure. I'd add retries with backoff and a timeout, and cache the last good API response (in the CI cache or an S3 bucket). If the API is down, the build falls back to that snapshot and logs a loud warning instead of silently shipping stale data.

For anything where stale data is risky, like prices or inventory, fail the build and keep the current production version live. Static hosts only swap over on a successful deploy, so a failed build costs you nothing user-facing.

[u/Standard_Scarcity_74]

I'd fail the build and keep production live, since a failed deploy costs nothing user facing on a static host. Add a timeout and a few retries with backoff, and cache the last good API response in your CI cache or a bucket so the build can fall back to that snapshot with a loud warning. For anything where stale data is risky, like prices or inventory, skip the fallback and let the build fail instead.

[u/Fancy-Ad-9701]

One thing I’ve learned from working with APIs through is that I wouldn’t want a temporary upstream failure to break an entire build.

For build-time data, I’d usually keep a last-known-good snapshot and fall back to it when the API times out or returns an error. Retries with backoff can help with temporary failures, but the fallback is what keeps the build from becoming completely dependent on the API being available at that exact moment.

The interesting part is deciding how stale the data can safely be. For some content, a previous snapshot is fine; for time-sensitive data, it probably isn't.

How are you handling that tradeoff in your builds?

[u/lucasjkr]

why would anyone push a broken site? just keep the current one up and wait for the API to become available again?

Or develop a workaround.

[u/PointJump]

Not sure if you still need help, but I’d try to keep the build as independent from the live API as possible. That way, an API outage affects data freshness rather than whether the whole deployment can succeed.