Modeling the network's future
Cloudflare's network handles more than 81 million requests per second at peak, spread across data centers in over 330 cities and 120+ countries. The capacity planning team's job is to make sure that global footprint always has enough headroom to serve customer traffic, even when things go wrong. That means constantly asking "what-if" questions: What happens if a data center fails? What if a major customer doubles or triples its request volume overnight? What if traffic patterns shift from one region to another?
The answers to those questions determine where traffic gets served from and what the customer experience looks like under stress. This is why scenario planning is so central to how Cloudflare operates its infrastructure.
Why CPU time matters
Cloudflare's network sits within 50 ms of roughly 95% of the Internet-connected population. But proximity alone is meaningless if the local data center lacks the compute capacity to actually serve requests. The company has invested heavily in real-time systems — like Traffic Manager and backbone routing — that shift traffic dynamically to work around congestion and failures. Those systems handle volatility on short timescales, but capacity planning must look much further ahead.
The unit of measurement for that planning is CPU time, defined as the time each request spends in the CPU. This is the same metric Traffic Manager uses, and for good reason: requests per second is a misleading measure when workloads vary widely in cost. A cache-served website with the WAF disabled is far cheaper in CPU terms than one with full WAF rules enabled and caching turned off. By recording CPU time per request in milliseconds and aggregating it per second, Cloudflare gets a common unit across all customer workloads. That unit also correlates directly with latency, which makes it meaningful for customer experience.
…using requests per second as a metric isn’t accurate enough when actually moving traffic. The reason for this is that different customers have different resource costs to our service; a website served mainly from cache with the WAF deactivated is much cheaper CPU wise than a site with all WAF rules enabled and caching disabled. So we record the time that each request takes in the CPU. We can then aggregate the CPU time across each plan to find the CPU time usage per plan. We record the CPU time in ms, and take a per second value, resulting in a unit of milliseconds per second.
Supply and demand scenarios
Once the metric is set, the modeling work splits into two buckets: supply and demand. Each one generates its own set of what-if questions that feed into the planning engine.
Demand what-ifs
- What if a new customer onboards with a significant volume of requests and/or bytes?
- What if an existing customer grows its request or byte volume by a multiplier (2x, 3x, nx) at peak for the next three months?
- What if the global growth rate across all data centers changes from X to Y two months from now, indefinitely?
- What if the growth rate at one specific data center facility changes from X to Y one month from now?
- What if egress traffic to a last-mile network shifts from one location (such as Boston) to another (such as New York City) next week?
Supply what-ifs
- What if a data center facility loses some or all of its available servers two months from now?
- What if X servers are added to a facility today?
- What if some or all connectivity to other ASNs (12,500 networks, nearly 300 Tbps) fails now?
From questions to answers
Each scenario, or combination of scenarios, is expected to produce answers to a core set of questions: What does the overall capacity picture look like over time? Where will traffic be directed? What are the cost implications? Will additional servers need to be deployed to absorb the load?
Modeling each of these scenarios by hand would be an unsustainable operational burden. That realization is what drove the launch of "Scenario Planner," a system designed to make what-if capacity modeling repeatable and manageable at Cloudflare's scale.
A closer look at the tooling
Scenario Planner, completed in August 2024, aims to make capacity simulations accessible across Cloudflare rather than leaving them to a handful of specialists. At its core, it takes hypothetical changes to demand and supply metrics and translates them into CPU time—the common unit that underlies all of Cloudflare’s capacity modeling.
The inputs are phrased as practical "what-if" questions that infrastructure engineers might ask. On the demand side, that includes onboarding a new customer with a large request volume, multiplying an existing customer’s traffic by a set factor, or adjusting the global data center growth rate from one value to another at some point in the future. For each query, the planner turns the inputs into a load distribution across data centers, using either the customer’s actual historical distribution or the aggregate distribution across all regions.
Supply-side scenarios are just as direct: what if a data center loses some or all of its servers two months out? What if we add X servers to a facility today? In both cases, the server counts are converted to CPU time before being passed to the backend simulation engine. Users specify the data center, the number of servers involved, and the timeline over which the change occurs.
Reading the output
The results are displayed through the same heatmap and failover views that capacity planners already use for standard forecasting. That design choice matters: teams don’t need to learn a new visualization to make sense of a scenario.
The heatmap, in its default state, reflects current and planned capacity. A typical frame shows, for example, data centers in Eastern North America with Ashburn in yellow—that color indicates the capacity planning threshold of 65% CPU utilization has been reached. That number is not a warning but a trigger point: it gives the team enough lead time to procure, ship, install, and light up new servers before customer impact occurs. Cloud icons mark planned upgrades sized to stay ahead of forecasted demand.
To see how the view shifts, consider a scenario where Ashburn, Miami, and Atlanta fail simultaneously and stay offline indefinitely. That is an extreme hypothetical, but the simulation reveals how the remaining large ENAM facilities would absorb the traffic. The heatmap is capped at 75% because Traffic Manager generally engages around that utilization level; beyond it, customers may begin to see added latency depending on product and workload.
Where the requests actually go
The heatmap shows constrained capacity but not where serving would fail over. That is what the failover simulator adds. The capacity planning team has long simulated how Traffic Manager would reroute traffic over sustained periods, and Scenario Planner extends that work directly into the what-if flow.
Under the simulated ENAM outage, the model points to a significant portion of Atlanta’s CPU time being served from DFW/Dallas, plus smaller shares from Newark and Chicago for the rest of the year. Nothing is actually being rerouted today, but this kind of forward-looking failover behavior lets planners test multiple simultaneous failures anywhere on the globe. The goal is to act on those simulations before customers are ever exposed to a degraded experience.
Removing the guesswork
Cloudflare's capacity planning still works with a forecast horizon of 12 months to three years and produces weekly, monthly, and quarterly projections. What Scenario Planner changes is the cost of testing alternatives against that baseline. Instead of building one-off manual models for each hypothetical, internal teams can model changes to demand and supply across all data centers and see exactly how the network would respond—constraints, failover, and all.
