When your website host fails: what moving 11 sites in a week taught us

When a host fails, the cause is often a billing or plan limit rather than a fault in your site, and the symptom can look like an attack or an outage. On 28 August every Workers-hosted site on one of our Cloudflare accounts started returning a "temporarily rate limited" page, because the paid plan on that account had lapsed. Nothing was wrong with any of the sites. We moved the affected sites over the following days, and we learned several things we would do differently.

What it looked like

All 14 Workers sites on the account returned an HTTP 429 response with Cloudflare's "this website has been temporarily rate limited" page. The page loaded in about a third of a second and came from Cloudflare's own network, before any of the sites' code ran. That is the first clue. A fault in a site's code is slow, or throws its own error page. A response that fast and identical across every site on an account is coming from the layer in front of them.

It was not a Cloudflare outage and it was not specific to any one site. The account's paid Workers subscription had lapsed and the account had fallen back to the free tier's allowance of 100,000 requests a day. The account was actually seeing about 597,000 requests a day, so everything past the cap was refused. Sites we host on Cloudflare Pages, a different product, kept working throughout.

How we diagnosed it, and what we would check first

The symptom looks like a site problem and invites a pointless migration. A single question separates the two: does every site on the account fail the same way? If so, pull the account's total request volume and compare it with the plan's allowance. Cloudflare's reporting interface still answered while the sites were throttled. We checked the numbers before touching any code or DNS.

If you have one site and it shows this kind of page, ask your host or developer which plan the account is on and whether its billing is current. That one question would have saved time.

The recovery, and the mistakes in it

We moved 11 of the affected sites to a different host as an emergency measure and moved one to a new Cloudflare account. The DNS records for those sites stayed in the old account, pointing at the new host. They had to stay unproxied, because turning the proxy back on would send traffic straight back through the throttled network.

Several things went wrong, none of them dramatic:

• Settings did not travel. Secrets and environment values are held per hosting account. A move leaves them behind. Three form-bearing sites sent enquiries to the wrong place or failed outright until we audited them, covered in the contact form that says sent but delivers nothing. One of our own sites returned errors because a login secret was missing from the new account, and eleven other secrets on it were still unset when we checked.
• Looking right was not enough. The build, the page checks and the deploy log all looked fine. Only requests to the live sites told us what was broken.
• We deleted the old destination too early on one site. On 9 October, after rebuilding a client site onto a new Cloudflare account following a failure of its previous host, we removed the old DNS zone and the temporary host straight away. The DNS change had not finished spreading, so the client's own network still resolved the old address and showed a 404 page. We recreated the temporary host as a safety net. The rule we took from it: keep the old destination serving until the change has settled, about 48 hours, and phase migrations rather than cutting over in one step.

What to ask about your own site

1. Who holds the hosting account, and who is billed? If the answer is someone you cannot contact, you have a single point of failure.
2. Who holds the domain and the DNS? See who actually owns your website for the four separate accounts most sites have.
3. What happens if the host's plan lapses? A good provider can tell you, and knows whether they would be told before you are.
4. How quickly could the site move? If the code and content are in a repository the developer controls, a move is days. If the site lives inside a hosting product that cannot export it, it may be a rebuild.
5. When was the last time someone requested the live site and checked the forms?

Why we say this openly

It would be easier to leave this out, since the lapse was on our side. We include it because the questions above are the ones we would want a customer to be asking about us, and because the way to show you handle a failure is to describe one. It also explains why we are consolidating our hosting onto one account that we watch, rather than spreading sites around.

If you are comparing providers, a monthly arrangement means the person hosting your site is paid for as long as it stays up, which is a reasonable reason to care. It does not make the hosting immune to mistakes, as this post shows. Our pricing covers what the base plan includes, and the web design service page describes how we build and host.