One row of the table in our Cloudflare standard reads, in full: a global Cloudflare outage, every product is down, wait, accepted risk. We wrote it ourselves on 20 October, the day we moved TipBop off Google Cloud, and it is the sentence a sceptical client should read first.
The outage post explains why we left. This one is the other half: what we gave up by going all in on one vendor, and what we did so that a bad day there is a slow day and not a lost business.
Five ways it goes wrong
The standard lists them in a table, and the table is more useful than any promise would be. Each row is a failure, what happens, and how we get back.
The first three rows are the platform doing its job. Every write to D1, the database we use, is confirmed on three of five copies in different data centres before we are told it succeeded, so a failed machine or building is Cloudflare’s problem and not ours. We cannot give you a failover time for it, because Cloudflare does not publish one. A bad deploy rolls back in seconds, and bad data can be wound back in place to any minute in the last 30 days. Those are the failures that happen most, and they are cheap.
The last two rows are the honest ones. If our account is suspended or the platform loses data, we rebuild from a copy that does not live on Cloudflare. And if Cloudflare itself has a bad day, we wait.
The size of the bad day
The objection is fair, and our own hosting review made it. Written the morning of the zone outage, it pointed out that every product already sat behind Cloudflare’s DNS and proxy, so the estate’s real single point of failure was Cloudflare before we moved a thing. It counted three Cloudflare incidents in 2025 that would have hurt us, from about 25 minutes to about six hours for the long one. Our later standard records that same November outage as about three hours. We never reconciled the two numbers, so we plan for the longer one.
Moving the back end changed what is in the request path. Before, a Cloudflare outage and a Google outage were two separate ways to be down. Now it is one platform, and that platform is the one that was already in front of everything. That is concentration, and we chose it with open eyes because it removed a vendor from the path instead of adding one. We still say plainly that it makes a Cloudflare bad day a whole-estate bad day.
The backup that lives somewhere else
What turns that from a business risk into an inconvenience is where the copy is kept. Every product writes a nightly export outside Cloudflare, a full D1 dump plus every Durable Object’s SQLite data, into a storage bucket at the other cloud. The reason it is there is the same reason our Google-hosted databases were copied to Cloudflare storage before the move: a backup on the platform that failed fails with it.
An export is only a backup once it has been restored. So each night the export is loaded into a scratch environment and checked, and an email goes to our alerts inbox if it fails. The standard puts a rebuild in a fresh account at about 30 minutes. That is the plan’s figure, not a measured one, and we only count a number as ours once we have timed it, as we did with the 41-second rollback.
The same exports are our way out. They are plain SQLite, which any other platform can read, so leaving Cloudflare is a project and not a hostage situation.
What we gave up
Every platform has things it will not do. These are the ones we chose to live with, and what each costs.
When we would go back
The standard ends with a section nobody expects from a document like this: when not to use Cloudflare. It names four conditions, and any one of them is enough to send a project back to Cloud Run and Cloud SQL in London, with the exception written down before anything is built.
- A contract requires data to stay in the UK.
- The work needs heavy or long-running compute, GPUs, or native programs that Cloudflare’s containers cannot serve.
- A customer demands a financially backed uptime guarantee we cannot get.
- The code depends on Postgres in a way D1 or Durable Objects cannot replace.
And when we do go back, the standard says what that database must look like: regional, on a dedicated core, from its first real customer. One zone and a shared core are for beta, which is exactly the lesson of 20 October.
What it costs, and what it does not buy
The numbers that tempted us are estimates, so we label them as such. At 20 customers each, our standard puts the platform bill for one product at the figures below, and the biggest is a guess.
Estimated monthly platform cost at 20 customers each
Midpoints of the ranges in our standard. ZooLog's range is wide because the price of its AI features is the unknown.
Source: Estate Cloudflare architecture standard, 20 October 2026
None of this says Google Cloud was bad. Our own review said to stay and add high availability, and on its terms that was sound advice. We went the other way because cost, reliability and restore speed pointed there, and because the effort of moving was not a reason to stay. If a condition in the list above turns up, we will be back on Google Cloud for that project, and we will write it up here.
