There is a particularly painful kind of outage: the one that happens exactly when the site receives more people than ever. The press piece ran, the campaign started, Black Friday began, and the server returns an error while thousands of people try to get in. The irony is that this traffic cost money and effort to earn, and it is lost entirely in the ten minutes it takes for everything to come back.
The good news is that these episodes are almost always avoidable, and the preparation happens two weeks ahead.
Understanding why a site goes down
A site does not go down because "there are a lot of people" in the abstract. It goes down because a specific resource runs out, and you need to know which one to attack the right thing.
The most common is the number of simultaneous processes. Every plan has a ceiling on how many requests your site can process at once. When it fills, the next ones queue, and when the queue fills, the server returns a 503. The server is not broken: it is saying "I cannot keep up."
The second is the database. Every visit that does not come from cache fires queries. With many simultaneous visits and poorly optimized queries, the database becomes the bottleneck and the whole site crawls.
The third, less frequent, is bandwidth or CPU, typical of sites with many heavy images or complex processing on every load.
Two weeks out: measure where you stand
You cannot prepare what you have not measured. Before touching anything, find two numbers.
The first is how long your page takes to respond without cache. Measure it with any speed tool, looking at time to first byte. If it already sits at 800 milliseconds under normal traffic, under load it will be far worse.
The second is how many simultaneous visitors you can withstand. Load testing tools simulate concurrent visitors and show you the number at which errors begin. Running a modest test during a quiet hour gives you a real reference instead of an intuition.
With those two numbers you know whether you have headroom or are heading straight into trouble.
Caching: the measure with the highest return
If you could only do one thing, it would be this. A page without cache forces the server to run code and query the database on every visit. The same page cached is delivered as a static file, and the difference in capacity is an order of magnitude, not a percentage.
Three things to verify. First, that page caching is active and genuinely working: test in a private window and check whether the response carries the header indicating it came from cache. Second, that the expiry time is reasonable for the event: during a spike, pages should be stored longer than usual. Third, and this is always forgotten, that non-cacheable pages are identified: cart, account and checkout must stay out, because caching them means someone sees another person cart.
If your host offers server-level caching, use it instead of a plugin. It works before PHP even starts and performs far better.
One week out: prune what is not needed
This is the moment to shed weight. Review your active plugins and disable anything not essential for the event, especially those running on every load: related posts, counters, sliders, homegrown analytics.
Pay special attention to anything writing to the database on every visit. Internal statistics plugins are the classic example: unnoticeable under normal traffic, and under a spike they multiply writes exactly when the database is saturated. During the event, measure with an external tool.
Also review the images on the pages that will receive the traffic. Converting them to a modern format at the right size reduces transfer and speeds everything up, especially for people arriving on a phone with a mediocre connection.
Three days out: talk to your host
Almost nobody does this and it is one of the most effective moves. Write to support telling them you expect a traffic spike on a given day, at a given time, of a given approximate size. Good providers take note, and in some cases can temporarily raise your account limits or at least have someone paying attention.
It is also the moment to assess whether the plan is enough. If the load test showed you start failing at 200 concurrent visitors and you expect 500, no optimization covers that gap. Upgrading for a month is cheaper than losing the campaign.
Event day
Three simple rules. Do not ship changes that day: no plugin updates, no theme changes, nothing. If something breaks, it breaks at the worst possible moment.
Keep a monitoring tool open that alerts you if the site stops responding. Finding out from a customer who writes in is finding out late.
And keep a recent, verified backup at hand. Not for the spike itself, but because high-traffic events also attract attack attempts.
What to do if it goes down anyway
If 503 errors start, two actions produce immediate results. The first is aggressively increasing cache lifetime, so the largest possible share of visits is served without touching PHP. The second is temporarily disabling everything not essential to selling.
What does not help is restarting things at random or turning off caching "to see if it improves." Under load, removing the cache is the fastest way to make everything worse.
Afterwards: learn from the episode
Once the event is over, look at the server logs. You will be able to see the exact time errors started, how many requests per minute you were receiving, and which pages concentrated the load. That data is what lets you size things correctly next time.
And if the conclusion is that the plan was too small, take it as good news: it means the project grew. At that point the conversation is about semi-dedicated plans or a VPS, where the resources are yours and you do not share the machine with a hundred other accounts. At BanaHosting that jump happens without changing providers, which is one less complication at a moment when you already have plenty to handle.