Your video took off, a news site mentioned you, or the sale you planned for weeks finally landed, and at the exact moment the biggest crowd showed up, your site slowed to a crawl or started showing an error. Every minute it stays down feels like watching customers walk past a locked door. If your website crashed from a traffic spike, the spike is often still happening, which means some of that moment can still be saved. The first hour is not about fixing the whole site. It is about confirming what is actually wrong, getting your host on the problem, and keeping one simple page in front of the people who are arriving. The deeper fix can wait until the crowd thins out. You can start on the first step in the next five minutes.
Key Takeaways
In the first hour, confirm the outage from outside your network, contact your host with the URL, time and error, switch on existing caching, and send the campaign link to a simple page with a temporary redirect.
Each uncached page visit can tie up a server process and a database query, and Kinsta documents that extra requests wait in line once every PHP thread is busy, which can end in timeouts and 503 or 504 errors.
A static fallback page, the cache your site already has, or your host's own temporary upgrade may solve this one incident, and an upgrade alone will not fix a slow plugin, a bad query or a bot flood.
The First Hour Is About Keeping One Page Up
While visitors are still arriving, your job is narrow: keep the page they are trying to reach, or a stand-in for it, loading. Everything else, including what caused the crash and whether you need a different plan, is a question for tomorrow. The five steps below run in order, and each one takes minutes rather than hours. Keep notes as you go, because the times, errors and screenshots you collect now are what your host and any developer will need later.
Confirm it is really traffic
Load the exact campaign URL on your phone with Wi-Fi turned off, or ask someone elsewhere to try it. Write down the time and the error you see, such as a 502, 503 or 504, a timeout, or a blank page. Then check your host's status page and, if you use one, your CDN's status page, because a provider-wide outage looks identical to your visitors.
A crowd is not the only thing that knocks a site over at the worst possible moment. If the browser says the site cannot be found at all, check that your domain has not lapsed, and our guide on what to do when a domain name has expired covers that path. If your analytics show thousands of hits from odd places with no real referrer, or the site is showing pages you did not create, you may be dealing with bots or an attack, and the steps in the first 24 hours after a hack come first. A sudden spike can be automated traffic, so look at where visits are coming from before treating every request as a buyer.
Call your host with the evidence
Open a support ticket or chat and give them the URL, when the problem started, a screenshot of the error, where the traffic is coming from, and how long you expect it to last. Then ask direct questions: is my account hitting a resource limit, are the PHP workers or database connections maxed out, are you rate limiting me, and is there an incident on your side? A support agent can see your account's resource graphs. You usually cannot, and guessing wastes the minutes that matter.
Ask one more thing: does the plan have a temporary capacity increase or a same-day upgrade, and what does it cost afterward? Some hosts offer exactly that, and for a short spike it may be all you need.
Turn caching on, and leave a working cache alone
If you can still reach your site's admin area or hosting panel, switch on the full-page cache for public pages if it is off. Caching means the server builds a page once and hands the saved copy to the next thousand visitors instead of rebuilding it for each one. If caching is already on and pages are loading for some people, do not clear it. A cleared cache forces the server to rebuild every page at the worst possible time. The one reason to clear it mid-spike is if the saved copy is itself the error page.
Check what your host already provides before adding anything. WordPress.com's support pages, for example, say its built-in server cache makes a separate caching plugin unnecessary there and potentially harmful. The WordPress cache documentation explains the different layers if you are unsure which one you have.
Put up a simple holding page
A holding page is one plain page: your offer, a line saying the full site is catching up, and a way to reach you, such as a short signup or contact form hosted somewhere that is still working. Build it as a static page, meaning plain HTML with no database behind it, on a separate static host or a CDN you already have set up. A page like that has almost nothing to break.
This is the step that turns lost visitors into people you can reach later. Someone who leaves an email address on a plain page is worth far more than someone who stared at a spinning wheel and gave up.
Point the viral link at the lightweight page
If the original page cannot come back quickly, send the campaign URL to the holding page with a temporary redirect, not a permanent one. Google's guidance on redirects and Google Search says a temporary redirect keeps the original URL in its results, which is what you want when the page is coming back. A permanent 301 tells search engines the move is for good.
If you control the link in your ad, bio or post and can change it and test it within a few minutes, point it at the lightweight page directly. If you cannot verify the change quickly, leave the link alone and rely on the redirect.
Your Site Ran Out of Workers, Not Bandwidth
Once the page is holding, the question becomes why it buckled. The short answer is that a sudden crowd used up the limited processing capacity on your hosting account, and that is a different thing from running out of monthly data.
Every hosting plan comes with a fixed amount of CPU, memory, disk activity, database connections and worker processes. Hostinger's guide to server performance metrics treats these as separate from traffic, and shared plans cap each account so one busy site cannot slow its neighbors, as SiteGround describes in its fair use policy. An "unlimited bandwidth" plan can still run out of the capacity to build pages for a crowd of visitors at the same moment.
The multiplier is uncached pages. On a site that builds each page on request, every visit runs code, loads the theme and plugins, and queries the database. Kinsta's PHP thread documentation explains that one thread handles one request at a time, and once every thread is busy, new requests wait. Slow plugins and heavy database queries make each request hold its thread longer, as Kinsta's page on PHP performance sets out. Enough waiting ends in timeouts and 503 or 504 errors, which is often exactly what your visitors saw.
That is also why there is no reliable "my site can handle X visitors" number. Capacity depends on how many visitors arrive at the same time, how much work each page takes, and how much of it the cache absorbs. Monthly visitor counts and pageviews are poor stand-ins for that, and a page speed score will not show account throttling or a queue of waiting requests either.
The Cheap Fixes Come Before a New Host
We sell hosting, and a new host is often not what you need after one spike. If the page that matters can be served as public content, a static fallback, the cache you already have, a compatible caching setup and your host's own temporary upgrade may be enough for this event. Try those first.
An upgrade makes sense when the evidence shows you are hitting your plan's limits, or when the parts of your site that cannot be cached, such as checkout, need more capacity. An upgrade on its own will not fix a slow database query, a broken plugin, a bot flood or a third-party service that went down. That is why a site can move to a bigger plan and still crash during the next spike. Look at what failed before paying for more of the same thing.
The table below sorts the usual causes by what fixes them and how big the job tends to be. It is a diagnostic order, not a ranking of how often each happens; no cross-host data exists to rank them, and any site can have any of these first.
| What failed | Fix | Typical scale |
|---|---|---|
| Uncached public landing page | Turn on host or server page cache and test what it excludes | Usually a same-day settings job |
| Account resource limits | Host's temporary upgrade or plan change | Minutes to a day; confirm the ongoing cost |
| No CDN, or CDN leaving pages uncached | Set up DNS, cache rules and a way to clear or roll back | Hours to days |
| Heavy plugin, theme, query or scheduled job | Find it in logs and test changes on a copy first | Hours to several days |
| Checkout, login or payment paths | Add capacity to the application and database | A technical project |
| Host-wide outage | Only a static fallback or a second provider helps | Planned ahead, not during |
A CDN Helps Public Pages and Leaves Checkout on Your Server
A CDN, or content delivery network, keeps copies of your files on servers around the world. When a visitor asks for something the CDN has saved, it hands over the copy and your own server never hears about it. Cloudflare's getting started guide for caching walks through the basic setup.
The catch is in what gets saved. Cloudflare's page on default cache behavior says images, scripts and style files are cached by default, but HTML pages are not unless you add cache rules for them. If your pages are built on request, a CDN with default settings can still leave your server doing the hard part. Pages tied to a visitor, such as a cart, an account or a checkout, should skip the cache on purpose. The rules for when a saved copy may be reused are set out in the IETF's HTTP caching standard, RFC 9111, published in June 2022.
A static site goes further: every page is prebuilt, so there is no page-building server or database query for those pages at all. AWS describes this setup in its guide to hosting a static website on CloudFront, where cached files come from edge servers and the origin is only asked when a copy is missing.
Neither a CDN nor static hosting makes a site impossible to take down. Cache misses, logins, checkout, forms, publishing and DNS mistakes all still depend on something behind the scenes working. The cost to start is low. Cloudflare's plan page lists a free plan and a Pro plan at $20 a month billed yearly or $25 month to month, and the CloudFront FAQ lists a free tier of 1 TB of data transfer and 10 million requests a month, subject to AWS's terms.
The Next Spike Is Won in the Week Before It
A planned promotion, a product launch or a TV spot gives you time to prepare, and a few hours of preparation can change how the next spike goes. The steps below cover the host, the cache, the fallback and testing. None of them promise zero downtime; they keep your offer and a way to reach you available while anything else gets fixed.
Know which pages will take the hit
Pick the one or two URLs the promotion will send people to. For each, sort what happens on it into public content that can be cached and actions that cannot, such as adding to a cart, logging in or paying.
Ask your host for the real limits
Ask for the limits the plan actually enforces, not the name on the plan: CPU, memory, PHP workers or concurrent processes, database connections, disk activity, data transfer, what happens when you go over, how to get a temporary upgrade, how to reach support fast and what monitoring you can see. Hostinger's article on preparing a site for Black Friday traffic is a useful checklist to compare against.
Test the cache, the fallback and the redirect
Turn on page or edge caching for public pages and confirm carts, accounts and checkouts are excluded. Build the static fallback page and set up the temporary redirect before launch day, then test both. Load testing is worth doing only with your host's permission and a gradual ramp. AWS's load testing guidance for CloudFront warns that a test from a single IP address gives misleading results and can strain a small set of edge servers.
Write the plan down, test it and keep it current. NIST's contingency planning guide, SP 800-34 Rev. 1, was written for federal systems rather than small business hosting, but its habit of documenting and rehearsing a fallback applies to a one-page promotion too. Know who holds the logins for your domain, hosting, CDN and analytics, because finding a password in the middle of a spike costs the same minutes the spike does.
A Ten-Minute Check Tells You Where You Stand
You can run this today, before anything is on fire. It will not tell you your exact capacity, but it will show you who controls what and whether your cache is doing its job.
- Find your host, site platform and CDN: Check your billing emails, your DNS dashboard or your hosting control panel.
- Read your plan's real limits: Open the plan page and resource dashboard, and note CPU, memory, workers, database and transfer limits, current usage, any warnings, and whether a temporary upgrade exists.
- Check that caching is on: Load a public page in a private browser window and look at the response headers or your host dashboard for a cache status, without clearing a working cache.
- Test from outside: Open your host's and CDN's status pages, load your main URL from another connection, and note the status code and time.
Skip testing checkout, account or form pages as if they should be cached; those are meant to reach your server every time. If you finish the four checks and still cannot tell who runs your DNS or whether the cache is working, that is the gap to close before the next promotion, not during it.
Would your site survive the next spike?
Pick an answer to begin.
1. Your site is slow during a spike and caching is already on. What should you do with the cache?
2. Your main page is down for an hour. Which redirect should point the campaign link at a holding page?
3. You add a CDN with default settings. What does it usually cache?
Frequently Asked Questions About website crashed from traffic spike
Can too much traffic crash a website?
Yes. A sudden crowd can use up the server, worker, database or account resources on your plan, especially on pages that are built fresh for every visitor instead of served from a cache.
My website went down after a viral post. What do I do first?
Check the site from outside your own network, look at your host's status page, contact your host with the URL, time and error, and send visitors to a simple cached or static page using a temporary redirect.
Will a CDN stop my website crashing?
It can take a lot of load off your server for pages it caches. Cloudflare does not cache HTML pages by default, and cache misses, logins and checkout still depend on your own server.
Should I upgrade my hosting after a traffic spike?
Only after checking that you actually hit your plan's limits. A slow plugin, a heavy database query or bot traffic will keep causing trouble on a bigger plan.
Should I use a 301 redirect while my site is down?
No. Use a temporary redirect for a temporary outage. Google says a temporary redirect keeps the original URL in its results.
How do I handle a traffic spike before a planned promotion?
Ask your host for your plan's real limits, turn on caching for public pages, build and test a static fallback and redirect, and load test only with your host's permission.
The Bottom Line
When a spike takes your site down, the first hour is about one page, not the whole site. Confirm it is really traffic and not an expired domain or an attack, get your host looking at your account, switch caching on without clearing a working cache, and point the campaign link at a simple page with a temporary redirect. The reason it happened is usually a line of visitors waiting for a limited number of server workers, not a shortage of bandwidth.
After the crowd passes, compare the incident window with your resource graphs, error logs and traffic sources before you buy anything. The next promotion goes differently when you know your real limits, your public pages are cached, and a tested fallback page is sitting ready.
If you want someone to look at that evidence with you, Web Leveling can read your resource and error logs, set up caching and a static fallback, and tell you whether your current plan is enough before anyone suggests a move. Our web hosting work starts with the least disruptive fix, and if your host's own upgrade or the cache you already have will do the job, we will say so. We work with small and medium businesses across the country and overseas. Tell us what happened during your spike, and we will help you get ready for the next one.
Terms
Traffic spike words in this post
Tap a term to see what it means.
Cache. A saved copy of a page or file that can be handed to the next visitor without rebuilding it.
CDN. A content delivery network, a set of servers around the world that hands out saved copies of your files.
PHP worker. A server process that builds one page request at a time on sites that run PHP code.
Static page. A prebuilt page of plain HTML that needs no database or page-building server to load.
Temporary redirect. A signal that sends visitors from one URL to another for now, while telling search engines the original will return.
503 error. A status code meaning the server is temporarily unable to handle the request, often because it is overloaded.
Origin. Your own web server, which a CDN goes back to whenever it does not have a saved copy.