Reading the SLA before you need it
A client asked me last week what happens if her site goes down during a product launch. Fair question. I went and read the Webflow Service Level Agreement, which was rewritten on 1 August 2026 and took effect on 1 September, and the answer is a credit worth 2% of that month's fees, capped at 25% of the monthly fee per calendar month. Not a refund. Webflow's own text says the credit "may not be redeemed for cash" and "may only be applied to the ensuing Renewal Term", so the compensation for your platform failing is a discount on buying more of it.
Two percent, and only if you ask in time
The SLA defines Qualifying Downtime as an outage longer than thirty consecutive minutes that drags your total monthly uptime below the Uptime Level written on your Order Form. That threshold is not published anywhere public. It lives in an enterprise contract, so anyone reading the SLA page without one cannot tell you what number they are owed against.
Then there is the clock. Qualifying Downtime, the document says, "begins to accrue when Customer notifies Webflow and Webflow confirms the outage." Every minute before someone on your team notices and files a ticket is free. At 3am on a Saturday that is most of the outage. Once it ends you have seven calendar days to submit a written request or you forfeit the credit entirely, and section 2.4 closes by naming itself Webflow's sole and exclusive liability for anything to do with uptime.
I want to be careful here, because none of this is sneaky. Webflow's SLA is better written than most and the exclusions it lists for DDoS attacks, DNS resolvers and third party plug-ins are the same exclusions every hosting vendor writes. The gap is between what the document is and what people think they bought. An SLA is a rebate schedule with a deadline attached. Teams read it as a promise that the site will stay up.
The outage on 15 September would have paid nothing
Webflow's status page lists an incident that morning: intermittent 500 errors on hosted sites, mostly ones that had been published recently. The resolution note breaks it into four windows between 08:29 and 09:40 UTC. The longest ran ten minutes. Add them up and you get roughly thirty minutes of errors spread over seventy-one minutes of wall clock.
Under the SLA as written, that produces no credit at all. Nothing crossed thirty consecutive minutes, so nothing qualified. If you were running a campaign into a landing page that morning, you ate the lost conversions and the platform owed you zero, correctly, by the terms both parties agreed to. Webflow reports 99.95% uptime on Hosted Websites over the past ninety days, which is a genuinely good number and still leaves about sixty-five minutes a month inside spec.
The pattern holds elsewhere. Bubble's status page, measuring June through September 2026, shows 99.85% on the Main Bubble Environment and 99.77% on Bubble Dedicated, the tier you pay extra for. Across that window 99.85% is a little over four hours. Bubble's public pricing page offers no uptime commitment on any self-serve plan. Airtable's Terms of Service, last updated 31 May 2024, go further and reserve the right to "permanently or temporarily terminate or suspend your access to our Services without notice or liability, without cause or for any reason".
Owning the outage instead of filing for a credit
On our own infrastructure an outage is not a claims process. When we moved Stay World Class off Webflow and Xano onto Next.js, NestJS and Supabase, the migration ran as a four stage ETL that mapped every legacy ID to a PostgreSQL UUID so nothing lost its history. Lighthouse went from 55.91 to 91 out of 100 and largest contentful paint came down 77%. The part that matters on a bad morning is quieter: we can read the logs, roll back the deploy, and put the site behind a cached static fallback while we fix the cause.
That is the real trade. You give up someone else's promise and you take the pager. Nobody credits you 2% when your own deploy breaks, and there is no seven day window to claim anything, because the fix is yours to ship at whatever hour you choose. For a business whose revenue depends on the site being up during a launch, control over the recovery is worth more than a discount on next year's invoice.
Paying for hosting you do not run is entirely reasonable. We do it too, on Cloudflare. The difference is that the application code and the database are ours, so a vendor incident costs us a failover rather than a support ticket and a wait.
When the SLA is fine and you should stay
If your site is marketing pages and a contact form, an hour of downtime costs you some traffic and nothing structural. Webflow at 99.95% is more reliable than most self-managed stacks run by a team that does not have an on-call rotation, and honestly more reliable than a small agency's Kubernetes cluster. Moving off the platform would buy you worse uptime and a bigger maintenance bill.
Staying also makes sense when nobody on the team can respond to an incident. An SLA you cannot claim against still beats a server nobody knows how to restart at 2am. If your answer to "who gets paged" is a shrug, a managed platform is doing real work for you and the credit schedule is beside the point.
The question worth asking is narrower than platform loyalty. Work out what sixty-five minutes of downtime costs your business during your worst hour of the month, then read what your vendor owes you for it. If those two numbers are close, stay where you are. If one of them is a rounding error next to the other, that gap is the thing to fix, and it is not going to be fixed by a credit.
