Can your website handle the traffic peak? Create an operations plan before the campaign starts
A successful campaign can put more strain on your website than expected. With capacity planning, proper caching and clear contingency measures, you can reduce the risk of slow performance and downtime.
Category: Hosting and Operations
A campaign, product launch or media coverage can send far more visitors to your website than normal. In that situation, it is not enough for the solution to work well on an ordinary Tuesday. The hosting environment, application and external services must be able to handle the load simultaneously.
Many people prepare content, ads and mailings thoroughly, but treat capacity as an assumption. The result can be a website that responds slowly precisely when interest is at its highest. A practical capacity plan turns increased traffic into a manageable operational situation rather than a surprise.
Start by describing what will actually happen
“We expect a lot of traffic” is not a sufficient basis for technical decisions. The person responsible for operations needs to know when the load will arrive, which pages users will visit and what actions they will take.
A peak spread across an entire working day is different from a link being sent to a large recipient list at the same time. The same applies to the difference between reading an article and submitting a form or completing a purchase.
Create a simple event description that answers the following:
- When does the campaign start, and how long is increased traffic expected to last?
- Will visitors arrive gradually or at roughly the same time?
- Which countries and regions will the traffic come from?
- Which landing pages will receive the traffic?
- Will users read, search, download, submit a form or make a purchase?
- Which external services are part of the user journey?
- What are the consequences if the website or a key function goes down?
This provides a better basis for decision-making than a general request for “more powerful hosting”.
Distinguish between content that can be cached and work that must be performed every time
Not all page views put the same load on the server. A fully cached landing page can often be delivered without the publishing solution and database having to rebuild the page. A product search, shopping cart or personal logged-in page, on the other hand, requires more processing for each user.
Therefore, divide the campaign flow into two categories:
- Cacheable content: images, stylesheets, scripts and public pages that are the same for everyone.
- Dynamic functions: search, forms, login, stock status, shopping cart, payment and personal data.
This distinction determines how much benefit you get from caching and a CDN. If almost all traffic goes to a public landing page, much of it can be delivered from cached copies. If the campaign sends everyone through an advanced ordering process, the application and database themselves must withstand the load.
Make sure caching actually works
It is not enough for the operating environment to have a caching function. You must check which pages are cached, how long the copies are retained and what causes them to be deleted.
A common challenge is that publishing or editing clears far more cache than necessary. If someone makes a minor content change during the campaign, many requests may suddenly hit the server directly. This can create a load spike at an inconvenient time.
Therefore, clarify in advance which pages should be cached, which cookies bypass the cache and how the landing page is warmed up after a cache purge.
Use a CDN for more than images
A CDN distributes content through servers closer to users and reduces the traffic that has to reach the primary operating environment. This is particularly useful when the target audience is geographically dispersed or when pages contain many large files.
However, a CDN does not solve all capacity problems. If every page view must be processed by the publishing solution, or if all users send data to the same form and database solution, the bottleneck still lies behind the distribution layer.
Therefore, check:
- which file types and pages the CDN delivers
- whether compression and modern image formats are enabled
- how old files are removed when content is updated
- whether protection against unwanted traffic is configured correctly
- whether errors in the primary environment result in an understandable fallback page
The goal is to reduce unnecessary work for the origin server without displaying outdated or incorrect content.
Test the actual user journey under load
A simple response-time test of the homepage says little about the campaign’s most important function. The load test should reflect the actions you expect from real users.
If the goal is sign-ups, the test should open the landing page, load the necessary resources and submit a controlled test form. For an online store, the test may include viewing products, searching and creating a shopping cart, but payment steps must be completed in a safe test environment.
Increase the load gradually. At the same time, monitor response times, errors, CPU usage, memory, database activity and queues. This will show both when quality begins to decline and which part of the solution is the bottleneck.
Load testing should be planned with the hosting provider. An uncontrolled test in production may affect real users or be interpreted as unwanted traffic.
Choose the hosting environment based on impact and change requirements
The right hosting environment is not necessarily the solution with the most technical features. The choice should be based on how critical the website is, how variable the traffic is, and how quickly the team needs to be able to make changes.
A simple, managed environment may be well suited to a stable corporate website with predictable traffic. Solutions with multiple servers, automatic scaling and more advanced traffic management may be relevant when traffic varies significantly or downtime has major consequences.
Automatic scaling must nevertheless be treated as a feature to be tested, not a guarantee. New resources must start quickly enough, the application must be able to run on multiple nodes, and increased capacity in the web servers is of little help if the database or an external service remains the bottleneck.
Ask for specific answers to the following:
- Which parts of the environment can be scaled?
- Does scaling happen automatically or manually?
- How long does it take to increase capacity?
- Are there limitations in the database, storage or network?
- Who monitors the situation and intervenes during the traffic peak?
- How does additional capacity affect costs?
Freeze unnecessary changes before the campaign
A traffic peak is a bad time to update the publishing platform, replace add-ons or make major content changes. Even an apparently minor change can affect the cache, database or integrations.
Agree on a time when the solution enters a controlled change period. Critical security updates must still be assessed, but cosmetic and optional changes can wait until the campaign has ended.
Before the freeze, you should:
- complete and approve landing pages and forms
- update the solution in a controlled manner and test key functions
- take a fresh backup of files, the database and necessary configuration
- check that the backup can be used for recovery
- document how the latest change can be rolled back
The rollback plan must be brief enough to use under pressure. It should explain who makes the decision, what is rolled back, and how the team verifies that the solution is working afterwards.
Monitor the entire chain, not just the server
The server may be available even though the campaign has effectively stopped. A form may fail, the payment provider may respond slowly, or email confirmations may remain queued.
Therefore, set up monitoring that covers both technical capacity and business-critical actions. This may include availability, response times, error codes, database connections, queues and completion of a controlled test form.
Alerts must have a clearly defined recipient. Clarify who assesses the incident, who can change the hosting environment, and who informs the campaign manager. An alert without responsibility and authority to act provides little value.
Create a simple plan for the campaign day itself
Gather the most important clarifications on one page. The plan should specify the timing, expected traffic pattern, responsible people, monitoring points, approved measures and how to contact the hosting provider.
Also define thresholds for action. Examples may include a persistent increase in response times, an unusually high number of server errors or a decline in the number of completed forms. The thresholds should be adapted to the solution and tested in advance, not determined while the problem is occurring.
After the campaign, you should compare expectations with what actually happened. Look at the traffic pattern, cache hits, resource usage, errors and responses from external services. This will provide a better basis for the next campaign and allow you to adjust hosting capacity without relying on gut feeling.
Capacity planning is a collaborative effort
Professional web hosting is not just about server resources. The result depends on the interaction between content, code, database, caching, CDN, integrations and operational routines.
The best preparation is therefore to bring together the campaign manager, developer and hosting provider early on. When everyone understands the user journey, the load and the consequences of errors, it becomes easier to prioritise the right measures. This allows you to spend time and budget on the actual bottleneck rather than buying capacity you may not benefit from.
