Your website can go down even when you changed nothing

Cloudflare sits between many websites and their visitors, to speed pages up and block attacks. Web survey firm W3Techs says Cloudflare is used by 28.4% of all websites (W3Techs, figure as shown on 2 November 2026; it is updated daily).

According to Cloudflare's account, written by chief executive Matthew Prince, the trouble started at 11:20 UTC (Cloudflare blog). A change to the permissions on one of its databases caused a settings file used by its bot-blocking system to double in size. The software that handles visitor traffic had a size limit below the new size, so it failed. Visitors to affected sites got an error page.

At first, Cloudflare's team suspected a very large attack. Prince wrote in an internal chat, "I worry this is the big botnet flexing," according to Ars Technica (Ars Technica). It wasn't an attack. Cloudflare says traffic was "largely flowing as normal by 14:30" UTC and all its systems were working normally by 17:06 UTC. It called it its "worst outage since 2019."

Two details in Cloudflare's report matter for anyone with a sign-up or log-in page.

First, Cloudflare's Turnstile "failed to load". Turnstile is the small box on a form that checks a visitor is a person and not a bot. Cloudflare says it "can be embedded into any website without sending traffic through Cloudflare" (Cloudflare docs). So a site that didn't use Cloudflare for anything else could still have a broken log-in or sign-up form that day, if it used Turnstile on that form. Supabase, a sign-in and database service that AI app builders such as Lovable connect to (Lovable docs), lets you add Turnstile to "sign-in, sign-up, and password reset forms" (Supabase docs).

Cloudflare's own dashboard shows what this looks like. Cloudflare says that "while the dashboard was mostly operational, most users were unable to log in due to Turnstile being unavailable on the login page." The page opened. People couldn't get in.

Second, services that apps rely on were hit too. Supabase's status page recorded a "Full outage" caused by "a global upstream provider", with its sign-in service (Auth) among the affected parts (Supabase status).

The others followed the same pattern: a routine change or a hidden fault inside a large provider, felt by the businesses that rely on it.

• 12 June 2025, Google Cloud. Google says a policy change with "unintended blank fields" made a key system crash around the world. It took "up to ~2h 40 mins" to fully recover in one of its largest regions (Google Cloud incident report). Because part of one Cloudflare system relied on that provider, Cloudflare had its own outage the same day. It lasted 2 hours and 28 minutes, and Cloudflare's log-in service for business apps, Access, "failed 100% of identity based logins" (Cloudflare blog). Turnstile was affected that day too.
• 19 to 20 October 2025, Amazon Web Services. Amazon says the problem began at 11:48 PM Pacific time on 19 October and ended at 2:20 PM on 20 October (AWS summary). The cause was "a latent race condition" in an automated system that keeps internet addresses up to date. In plain words, a hidden timing fault left one important address blank, so customers and other Amazon services couldn't connect to Amazon's database service.
• 5 December 2025, Cloudflare again. A settings change made while protecting customers from a newly found security flaw caused errors for about 25 minutes. Cloudflare says the affected customers accounted for "approximately 28% of all HTTP traffic" it serves (Cloudflare blog). It wrote: "we know we have let the Internet down again".

Nobody has an exact total. The day after the November outage, research firm Forrester estimated that Shopify's direct losses "total just over $4 million if you calculate the revenue lost per minute of downtime", that losses for Shopify's merchants "could top $170 million", and that "the conservative estimate for this single event lands north of $250 million across all affected businesses" (Forrester). These are estimates based on revenue per minute, not counted losses.

Trade publication Retail Week reported that outage site Downdetector showed retailers including Marks & Spencer, Ikea, Asda and Vinted were affected (Retail Week).

For a small business, the cost is more specific. On 6 December 2025, the day after the second Cloudflare outage, a merchant who runs several Shopify stores posted on Shopify's community forum that Cloudflare had "completely blocked the ability to purchase" twice in a short period (Shopify Community). They listed what it cost them: "We spent ad money driving customers to a checkout that didn't function", customer complaints, lost sales, and customers who "actually paid (money was withdrawn from their bank), but no orders appeared in Shopify". This is one merchant's account. We could not check their figures or confirm that Cloudflare caused each failure.

When a checkout breaks halfway, you may also have to find the customers who paid, match their payments by hand and answer their emails.

A status page is the public page where a company reports its problems. It isn't always there when you need it.

During the November outage, Cloudflare says its own status page went down, which at first made the team think it was under attack. On 12 June, Google says it posted its first incident report about an hour after the crashes began, "due to the Cloud Service Health infrastructure being down due to this outage." Google also wrote: "For some customers, the monitoring infrastructure they had running on Google Cloud was also failing, leaving them without a signal of the incident."

If the tool meant to warn you runs on the service that's broken, it may go quiet when you need it.

1. Know what your site depends on. Ask your developer, or the AI tool you built with, to list the outside services your site needs to open, sign people in and take payments.
2. Follow their status pages, but don't rely on them alone. As 2025 showed, they can be late or down.
3. Have your site checked from outside. A check that runs somewhere other than your own hosting sees what customers see.
4. Have a short message ready for your social accounts or customer email: what's wrong, that it isn't their fault, and when you'll update them.
5. Pause paid ads if checkout is down for long. Otherwise you keep paying for visitors who can't buy.
6. Check everything once it's fixed. Sign up, log in and go as far as the payment page yourself. Then compare your payment records with your orders for the outage period, to find anyone who paid but has no order.
7. Don't rush to change your code during someone else's outage. If the provider confirms the problem is theirs, changes on your side can add a second problem.

Heedza opens your site from outside, the way a visitor does (Heedza).

What it would catch:

• Your site showing an error. Every 5 minutes, Heedza checks that your home page answers. If it gets an error such as 500 or 502 (Cloudflare's outage pages in November and December were this kind of error) or no answer within 15 seconds, it checks again with a second request. If that fails too, it emails you, and it emails again when the site is back (Heedza online check).
• Sign-up, log-in or payment pages that stop showing their form or Pay button. Heedza opens these pages and checks the form or Pay button is still there, every hour or more often on paid plans and once a day on the free plan. If one is missing, you get a picture of the page (Heedza log-in check, payment page check).
• Telling your customers. Paid plans include a public status page you can share, showing whether your app, sign-up and payment work right now (Heedza).

What it wouldn't catch:

• A log-in that fails after the form appears. Heedza never logs in, fills in forms or pays. If the email and password boxes show but the person-or-bot check under them fails, or signing in fails, Heedza can't see that.
• Payments with no matching order. Because Heedza never pays, it can't tell you whether a payment went through or whether an order was created.
• Very short or very local outages. A down alert arrives about 5 to 10 minutes after a site goes down, and the online check runs from one location. A 3-minute blip, or a problem in one country only, may not show up.
• The fix itself. If the problem is at Cloudflare, Amazon or Google, neither you nor Heedza can fix it. You get an early signal, so you can tell customers and check your pages afterwards.
• Outages that hit the monitor too. As Google's report shows, a checking service can be affected by the same outage it's watching. That's true of any monitor, Heedza included. Heedza's own site and checks run on Cloudflare, so an outage like the one on 18 November could affect Heedza's checks too.

My site is down and I didn't change anything. What should I check first?

Check the status pages of the services your site depends on, such as your host, Cloudflare and Supabase, and search the news. If a provider confirms a problem, tell your customers and wait for its fix. Then test sign-up, log-in and payment yourself.

Can a Cloudflare outage break my site if I don't use Cloudflare?

Yes, in some cases. If your log-in or sign-up form uses Cloudflare's Turnstile check, or a service your app relies on (such as Supabase) uses Cloudflare, part of your site can stop working. In November 2025, Supabase reported a full outage caused by an upstream provider.

Do I need more than one provider for everything?

Forrester advises large companies to spread the risk, for example by using more than one provider of Cloudflare's kind. That adds cost and work. For many small businesses, a more practical first step is to find out quickly, tell customers, and check sign-up, log-in and payment once it's over.

Want to see what Heedza finds on your site? Run a free scan.