Why Cloudways server sizing is a workload problem, not a traffic problem

Monthly visits are easy to understand, so they are often used as a shortcut for hosting capacity. The problem is that a pageview served from full-page cache can be dramatically cheaper than a request that boots WordPress, runs PHP, queries the database and waits on third-party services. A calculator that ignores this difference will undersize dynamic sites and oversize efficient cached sites.

Peak concurrency matters for the same reason. A site with 200,000 monthly visits spread evenly can be easier to serve than a site with 60,000 visits concentrated around a product launch, live class or email campaign. Server sizing should therefore consider what happens in the busiest few minutes, not just the monthly total.

The number of applications on the server adds another layer. Cloudways Flexible lets you run multiple applications, but those applications compete for the same CPU, RAM and I/O. Ten low-traffic brochure sites may fit comfortably where two busy stores would not. Treat site count as a multiplier whose effect depends on workload type.

RAM is necessary, but CPU usually decides peak responsiveness

RAM gives WordPress, PHP, the database and caches room to work without aggressive memory pressure. Too little memory can lead to swapping, killed processes or instability. But once the workload has enough memory, adding more RAM does not automatically make a slow PHP request execute faster. CPU and application efficiency often determine how the site feels under load.

On the Cloudways DigitalOcean Basic lineup, moving through the common Standard tiers generally adds CPU as well as memory. That matters because several PHP requests, database operations and background jobs may need to run together. Treat the plan as a bundle of resources rather than assuming the RAM number alone defines performance.

The most useful post-launch signals are sustained CPU saturation, memory pressure, response-time degradation, database latency and repeated slowdowns during predictable peaks. If only one metric is high while the user experience is healthy, investigate before upgrading. Sizing is about removing real bottlenecks, not chasing perfect-looking dashboards.

Cacheability changes how much server each visitor consumes

A cached anonymous request can be dramatically cheaper than a personalized dynamic request. Full-page caching can allow a content-heavy site to serve a large audience without executing the complete WordPress stack for every pageview. Dynamic account pages, searches, carts, dashboards and administrative requests cannot always take the same shortcut.

Object caching can reduce repeated database work, but it does not make every request free. PHP still executes, plugins still run and cache misses still happen. The safest sizing model asks what percentage of traffic is truly dynamic during the busiest period rather than assuming every visit costs the same amount of server time.

If you improve caching after launch, the same server may support more traffic. If you add personalization, ecommerce or membership features, capacity may fall even when total visits stay flat. Recalculate the workload after major application changes instead of treating the original server recommendation as permanent.

Leave headroom for spikes, updates and background work

A server running at its absolute maximum during normal traffic has no room for backups, plugin updates, image processing, imports, cron jobs or unexpected bursts. Reliable sizing deliberately leaves unused capacity. That unused capacity is what absorbs a campaign spike or maintenance task without turning it into a customer-facing incident.

The appropriate headroom depends on business risk. A personal project can run closer to the limit because a short slowdown has little financial impact. A store, agency client or paid course platform should usually keep more reserve capacity because performance problems can affect revenue, renewals and support workload.

Use the growth selector in the calculator to model expected expansion over the next few months. It is usually cheaper to buy a modest amount of planned headroom than to discover during a launch that the server has no spare CPU. At the same time, avoid doubling every input 'just in case' because that defeats the purpose of evidence-based sizing.

Sizing examples: three sites with the same traffic can need different servers

Imagine three websites at 100,000 visits per month. The first is an editorial site with aggressive full-page caching and very few logged-in users. The second is a lead-generation site with a heavy builder, search and several marketing integrations. The third is a small store where many visitors use carts, accounts and checkout. Their traffic totals look identical, but their server work is not.

The editorial site may be comfortable on a smaller tier because most requests are served without expensive PHP execution. The lead-generation site can need more CPU during cache misses and administrative work. The store may need the most headroom because personalized requests arrive concurrently and database writes happen during transactions.

This example is why the calculator does not convert 100,000 visits into a single RAM number. It asks what those visitors do. When you do not know the exact dynamic percentage, choose the more conservative workload category and use monitoring after launch to refine the decision rather than treating a traffic chart as a capacity benchmark.

A similar difference appears with multiple sites. Five brochure sites can collectively be lighter than one complex membership platform. If you are consolidating applications, think about combined peak behavior and maintenance overlap, then decide whether isolation is valuable for business continuity even when the aggregate resources appear sufficient.

How to use the calculator without overbuying

Start with realistic inputs rather than worst-case guesses. If most pages are cached and only administrators are logged in, select a cached or business profile. If a meaningful share of visitors use carts, accounts, search, quizzes or member dashboards, choose a more dynamic profile. The goal is to model the actual bottleneck, not to justify the largest plan.

The result includes a recommended tier and a safer headroom tier. The recommended tier is the place we would test first. The headroom tier is useful when downtime during a spike would be expensive, when traffic is highly seasonal, or when the site is expected to grow quickly. You do not have to buy the headroom tier automatically.

After launch, use Cloudways monitoring and application-level tools to confirm whether CPU, free memory, database load, PHP activity or response times are approaching uncomfortable levels. Real telemetry should always outrank a pre-purchase calculator. The calculator is strongest as a decision filter before you have production data.

Cloudways vertical scaling gives you an upgrade path

Cloudways allows servers to be vertically scaled when workload requirements grow. That changes the purchasing decision because the first server does not have to be the final server. If your traffic is uncertain, a sensible starting tier plus monitoring can be more economical than buying a large server based on a hypothetical future peak.

Scaling is still an operational event, so plan it before the server is already struggling. Watch trends, note seasonal campaigns and increase capacity ahead of known launches. Cloudways notes that a server restart can occur as resources are changed, so business-critical sites should schedule the change with the same care as other infrastructure maintenance.

The calculator therefore gives a recommended tier and a headroom tier. Start with the recommendation when the workload is predictable and scaling later is acceptable. Prefer the headroom tier when the cost of a peak failure is high, growth is imminent or the application has historically unpredictable demand.

Price should be compared with the cost of being undersized

Cloudways Flexible pricing is recurring, so a one-tier upgrade should be evaluated over a full year rather than as a small monthly difference. The calculator shows the reference monthly price and first-year promotional estimate so you can compare the cost of extra capacity with the business value of the site.

The cheapest server is not the best value if it creates slow checkouts, missed leads or recurring engineering time. The largest server is not the best value if most resources sit idle. Good sizing finds the lowest tier that meets the performance objective with an appropriate safety margin.

Promotions can lower the initial cost, but they should not influence the long-term capacity decision. Size the workload as if you will eventually pay the normal rate, then treat any temporary discount as acquisition savings. That prevents the promotion from encouraging a plan you would not want to keep after the discounted months end.

Validate the recommendation with production telemetry

No calculator can see your theme code, database indexes, third-party APIs, plugin behavior, cache configuration or traffic shape. That is why the result should be treated as a starting hypothesis. Once the application is live, production telemetry becomes the authority for whether the server is correctly sized.

Create a baseline during normal traffic, then compare it with the busiest known period. Look for CPU saturation, memory pressure, slow response times, high database load and patterns that line up with campaigns or scheduled tasks. If a bottleneck appears, determine whether optimization or scaling is the more durable fix.

Revisit sizing after major changes such as adding WooCommerce, launching a membership area, onboarding many agency sites, importing a large catalog, changing search technology or running a paid traffic campaign. Infrastructure requirements follow the application. A server that was perfect six months ago can become too small or unnecessarily large as the workload evolves.

A practical decision rule for server size calculator

Use the calculator result as the minimum tier worth testing for this general workload, then compare it with the headroom tier. If the price difference is small relative to the value of the application and peak performance matters, the headroom tier can be the more conservative production choice. If the workload is light and scaling later is easy, start lower and measure.

Do not treat the monthly traffic field as a hard limit. It is only one input in a model that also considers simultaneous users, dynamic work, application count, complexity and growth. Two installations with identical traffic can land on different recommendations because the shape of their work is different.

Finally, confirm the plan specifications and current Cloudways price at checkout. Cloudways can change server availability, pricing and promotions, and other cloud providers or premium CPU types may have different resources. The plugin keeps reference prices editable so the decision tool can be updated without rewriting the article.