What your site does when the backend is down
Astro prerenders every route to HTML at build time unless you opt out, so a marketing page ends up as a file on a CDN that holds no opinion about whether your database is answering. A page rendered on demand works the other way: every request is a live round trip. Most of the year the difference costs nothing. You find out which one you have on the morning something upstream stops answering.
The CDN fallback does less than you think
Cloudflare's Always Online is the safety net most teams assume they already have. It serves an archived copy of a page when Cloudflare cannot connect to your origin at all, which surfaces as a status code between 520 and 527. The documentation is blunt about the limit: Always Online does not activate when the origin is reachable but returning error responses. A 500 from a healthy app server that cannot reach its own database counts as reachable. The net stays folded.
The archived copy is also older than you would guess. Cloudflare hands the Internet Archive the most popular URLs that returned a 200 in the previous five hours, and the crawl interval depends on your plan: every 30 days on Free, 15 days on Pro, 5 days on Business and Enterprise. On Pro that means your fallback pricing page can be two weeks stale, and only pages that got traffic are archived at all. Dynamic content is never served. One more edge worth knowing: enabling Always Online makes Cloudflare ignore a stale-if-error directive from your origin, so the two do not stack.
None of that is Cloudflare being stingy. A CDN sitting in front of your app cannot tell a broken deploy from a correct 500, and guessing wrong in that direction is worse than doing nothing. The useful conclusion is that resilience is something you decide in your own build output rather than something you buy at the edge.
A file cannot have an outage
Astro's default is static. Every page, route and endpoint is prerendered at build time, and adding a server adapter does not change that by itself; you opt individual routes out by putting export const prerender = false at the top of the file. The pricing page, the docs and the blog compile to HTML while the one route that reads a cookie renders on a server. That split is a per-file decision, and moving a route across it is a one-line change you can make and revert in an afternoon.
Next.js adds a third option in between. Set export const revalidate = 3600 on a route and the first visitor after the hour gets the cached page immediately while a fresh copy regenerates in the background. If that regeneration fails, people keep getting the last version that worked. You can see which branch you landed on from the x-nextjs-cache response header, which comes back as HIT, STALE, MISS or REVALIDATED. One constraint catches people late: a static export does not support ISR, so this is settled when you pick the deployment target.
On a hosted platform the dial is not exposed. Pages render the way the platform renders pages, and there is no per-route override for the two pages where you would actually want one. When we moved Stay World Class off Webflow and Xano onto Next.js, NestJS and Supabase, the headline numbers were Lighthouse going from 55.91 to 91 and LCP dropping 77%. The quieter win was that rendering became a decision somebody could make, page by page, instead of a property of the vendor.
What the SLA pays when it goes wrong
Webflow's Service Level Agreement, last modified 1 August 2026 and effective 1 September, defines Qualifying Downtime as downtime in excess of thirty consecutive minutes that pulls your monthly uptime below the level named in your Order Form. The remedy is a credit worth 2% of that month's fees per event, capped at 25% of monthly fees, and you have to request it in writing within seven calendar days or you forfeit it. The agreement calls this the sole and exclusive remedy for uptime.
Bubble's commitments live behind Enterprise. Bubble announced a 99.9% uptime SLA for new Enterprise customers on dedicated instances, with 99.99% available on a high availability configuration. Below Enterprise there is no formal uptime guarantee, a gap their own forum has been arguing about for years. For a vendor hosting millions of apps that is a defensible position. It is just not something you can lean on when your checkout is down.
These terms are normal. Every hosting SLA I have read pays in credits rather than in the revenue lost while the page was dark, and the credit is deliberately small. So the contract is not the thing to optimise. The only lever you genuinely control is what the site does while it waits, and a file waits better than a render.
When staying put is the right answer
If your site is a brochure on Webflow, you already have most of this. Webflow serves pages that do not depend on a backend you own, so the failure mode you are protecting against mostly cannot happen. Rebuilding a marketing site in Astro to improve a resilience property you already have is work with no return.
The same goes for internal tools. An ops dashboard that twelve people use during business hours does not need to degrade gracefully, it needs to be fixed by lunch, and Bubble is a reasonable place to keep it. The calculation changes when the page that goes blank is the one that takes money, or when a prospect reads your pricing during an outage and decides you are not a going concern. If somebody on your team can name that page, it is worth asking whether it has to be live at all, or whether it could have been a file built an hour ago.
