--- title: "Why Websites Crash Under High Traffic | Evaluat" description: "Why websites crash under high traffic: the order a busy site fails in, from queues and timeouts to retries and cascades, and how to find your weak point first." url: "https://www.evaluat.com/blog/why-websites-crash-under-high-traffic" last_modified: "2026-10-21" --- [Blog](https://www.evaluat.com/blog) [Guides](https://www.evaluat.com/blog/category/guides) # Why websites crash under high traffic Most websites do not simply switch off when traffic spikes. Requests queue for a limited resource, pages slow, timeouts turn slow into failed, and retries and failed health checks pile on more load until the site falls over. The symptoms arrive in roughly that order every time. What differs is which part runs out first. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 21 October 2026 [Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 15Where slowness comes from ![The five stages a busy website fails in, drawn as a descending staircase. First, requests queue and pages slow. Second, timeouts turn slow requests into 502 and 504 errors. Third, retries and refreshes multiply the load. Fourth, overloaded servers miss health checks and are pulled from service. Fifth, the failure cascades to the next part of the system, often the database. The order barely changes; what runs out first does.](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic-cover.svg) Summary Most websites do not simply switch off when too many people arrive. Every part of a site can only do a fixed amount of work at once, such as a set number of worker processes or database connections. When requests arrive faster than that, the extra ones wait in a queue, and pages slow down. That is the first stage. In the second, requests wait longer than the timeouts set between the parts of the site, so slow turns into failed, and shoppers see gateway errors. In the third, retries make it worse, because software tries again automatically and people press refresh, so the same demand arrives twice. In the fourth, servers that are too busy to answer health checks are taken out of service, which pushes their share onto the rest. Finally the failure spreads to the next part along, often the database. The symptoms follow that order almost every time. What changes from site to site is which resource runs out first. It might be the web workers, the database connections, a payment provider or the search service. That is the useful thing to know before a sale, and a load test that ramps up traffic in a real browser is how you find it before your customers do. Listen to this article · 1:25 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/why-websites-crash-under-high-traffic.mp3) Key takeaways - A busy site fails in stages: queueing, timeouts, retries, health-check removals, then a cascade. - Every server has fixed limits, such as worker processes and database connections; traffic past them waits in a queue. - Retries and refreshes multiply demand at the worst moment; AWS shows three retries across five layers can mean 243 times the load. - Which part runs out first differs from site to site, which is why it has to be measured. - Find the first limit with a load test weeks before the sale, then protect checkout with timeouts, single retries and load shedding. ## What happens when a website gets too much traffic? Every part of a website can only do a fixed amount of work at once: a set number of worker processes, a set number of database connections, a fixed amount of CPU. When requests arrive faster than that work can be done, the extra ones wait in a queue. The waiting shows up as slow pages long before anything crashes. The limits are real numbers in configuration files. PHP-FPM, which runs many PHP shops, has a `pm.max_children` setting that, in its own documentation’s words, [sets the limit on the number of simultaneous requests that will be served](https://www.php.net/manual/en/install.fpm.configuration.php). PostgreSQL’s `max_connections` [determines the maximum number of concurrent connections to the database server](https://www.postgresql.org/docs/current/runtime-config-connection.html), and its default is typically 100. A restaurant kitchen is a fair picture. Eight cooks can make so many plates an hour. When the room fills faster than that, tickets pile up on the pass and diners wait. Nothing is broken yet. The kitchen is simply full, and the wait is the first symptom. That is why the common explanation, that the site “ran out of bandwidth”, is usually wrong. The network is rarely the first thing to fill. A product page needs code to run, queries to be answered and other services to reply, and the queue forms in front of whichever of those is slowest. Customers see a slow page, then an error page, and the headline says the site crashed due to high traffic. ## What does “the website crashed” usually mean? When people say a website crashed, they rarely mean the server switched off. Usually visitors saw error pages, pages that never finished loading, or a queue the site put them in on purpose. Each of those has a different cause, and the error code on the page is the first clue to which part ran out. The standard HTTP status codes tell you a surprising amount. Their definitions come from [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#section-15.6), the HTTP specification. | Code | What the specification says | What it usually means on a busy site | | ----------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | 502 Bad Gateway | A server acting as a gateway received an invalid response from the server behind it | The application behind the web server failed or refused the connection | | 503 Service Unavailable | The server is unable to handle the request due to a temporary overload or maintenance | Something is refusing extra work to protect itself | | 504 Gateway Timeout | A gateway did not receive a timely response from the server behind it | The request waited longer than the timeout and was abandoned | | Endless loading | No code at all | Requests are queued and nobody has given up yet | Sometimes the “crash” is a choice. When Oasis reunion tickets went on sale in August 2024, City AM reported that [Ticketmaster said its website has not crashed](https://www.cityam.com/oasis-ticket-selling-websites-hit-with-outage-issues/), and that fans had been placed in a queue because millions were trying to buy at once. A queue is a site admitting its capacity and choosing to protect it. ## In what order does a busy website fail? In roughly the same five stages almost every time. Requests queue and pages slow. Timeouts turn slow requests into failed ones. Retries and refreshes multiply the load. Overloaded servers are pulled out of service. Then the failure spreads to the next part of the system. The order of the symptoms is predictable; what fails first is not. ### 1. Requests queue and pages slow At first a busy server simply gets slower, because each request waits its turn. David Yanacek, a senior principal engineer at Amazon Web Services, describes how services [reach an inflection point where their performance starts degrading even more rapidly](https://builder.aws.com/content/3Eun1EEyX6p2e3VYNyRLSJzLuMV/using-load-shedding-to-avoid-overload). [Part 12 of this guide](https://www.evaluat.com/blog/time-to-first-byte) showed this as time to first byte climbing before anything else moves. ### 2. Timeouts turn slow into failed Every part of a site waits only so long for the part behind it. nginx, for example, [closes the connection](https://nginx.org/en/docs/http/ngx_http_proxy_module.html) if the server behind it sends nothing for 60 seconds by default. Yanacek puts it simply: [when a server gets so overloaded that its latency exceeds its client’s timeout, requests start to fail](https://builder.aws.com/content/3Eun1EEyX6p2e3VYNyRLSJzLuMV/using-load-shedding-to-avoid-overload). Worse, the server often finishes the abandoned work anyway, spending capacity on answers nobody receives. ### 3. Retries multiply the load Failed requests are tried again, by software and by people. Marc Brooker of AWS warns that [when failures are caused by overload, retries that increase load can make matters significantly worse](https://builder.aws.com/content/3EumjoZascWd1oZiEgL8ORlv3qE/timeouts-retries-and-backoff-with-jitter). His example is a request that passes through five layers of services, each retrying three times, so [the load on the database will increase 243x](https://builder.aws.com/content/3EumjoZascWd1oZiEgL8ORlv3qE/timeouts-retries-and-backoff-with-jitter). Shoppers do the same by hand. Google’s Site Reliability Engineering book notes that by the time a slow reply arrives, [there’s a good chance the user has given up and refreshed their browser, issuing another request](https://sre.google/sre-book/addressing-cascading-failures/). ### 4. Overloaded servers are pulled from service Load balancers check that each server answers a simple health check and stop sending traffic to any that do not. Under overload, healthy but busy servers miss those checks. In another AWS article Yanacek warns that [taking servers out of service during an overload can cause a downward spiral](https://builder.aws.com/content/3Ev53O39izHCtWLzp4XU6t8PC1O/implementing-health-checks), because the remaining servers inherit the load. Slack’s outage on 4 January 2021 shows the pattern: [some of our instances were marked unhealthy by our automation](https://slack.engineering/slacks-outage-on-january-4th-2021/), and then its autoscaling system downscaled the web tier, wrote Laura Nolan, a senior staff engineer there. ### 5. The failure spreads Overload rarely stays in one place. Google’s SRE book observes that [once a couple of servers crash on overload, the load on the remaining servers can increase, causing them to crash as well](https://sre.google/sre-book/addressing-cascading-failures/). Caches spread it too. A 2022 study of real incidents gives the example of a database that handles 300 requests a second behind a cache with a 90% hit rate serving 3,000, where [a cache failure can overwhelm the database](https://www.usenix.org/system/files/osdi22-huang-lexiang.pdf). The same study found retries kept the system down in more than half of the incidents it examined, even after the original trigger had gone. ## What does overload look like in numbers? One sale email is enough to show every stage. Take an example shop whose web servers run 40 PHP workers, each taking 250 milliseconds per request. Together they can finish 160 requests a second. On a normal afternoon the shop sees 90 a second, so there is room to spare and no queue. At 10:00 a sale email lands and traffic jumps to 200 requests a second. Now 40 more requests arrive every second than the workers can finish, and they wait. - **After 10 seconds**, 400 requests are queued. A new visitor waits about 2.5 seconds before a worker even starts on their page. The site is up, and slow. - **After 13 seconds**, the queue is full. PHP-FPM’s default listen backlog, its waiting queue, is [511 connections on Linux](https://www.php.net/manual/en/install.fpm.configuration.php). From here, one request in five is turned away and the shopper sees an error page, typically a 502. - **Within a minute**, shoppers who saw errors press refresh, and the basket page’s background calls retry. Arrivals climb past 250 a second, so more than a third are now refused. - **If a health check** sits in that same queue, the load balancer may decide a server is down and move its share onto the others, which fill faster still. No code changed and nothing is broken. The shop had a limit of 160 requests a second and the email asked for 200. A queue with a limit turns waiting into errors; a queue without one turns waiting into timeouts. Either way the shopper sees a failure. ## Which part of a website runs out first? It differs from site to site, and that is the most useful thing to find out. On a typical online shop the candidates are the web workers, the database, the cache, a third-party service such as payments or search, or a connection limit somewhere in front. Whichever saturates first sets your capacity, and everything behind it never gets busy. | Resource | Example limit | What you see first | | -------------------- | ---------------------------------------------- | --------------------------------------------- | | Web or PHP workers | A fixed number of processes | Rising response times, then 502 or 504 errors | | Database connections | 100 by default on PostgreSQL | Connection errors and slow pages everywhere | | Database work | Locks and slow queries on stock and orders | Checkout slows before browsing does | | Cache | Memory, or a cache purged at peak | A sudden jump in database load | | Third-party services | A payment, tax or search provider’s own limits | One step hangs while workers wait on it | | Front-door limits | Connection caps at a CDN or load balancer | Instant 503 errors with no slowdown first | Even well-prepared teams guess wrong about demand. Google’s account of the Pokémon GO launch in 2016 says the teams planned for a worst case of five times their target, and [player traffic surged to 50X the initial target, ten times the worst-case estimate](https://cloud.google.com/blog/products/containers-kubernetes/bringing-pokemon-go-to-life-on-google-cloud). Planning numbers are guesses until a test checks them against the real system. ## Why do websites crash during sales and launches? Because demand arrives in minutes, not spread across a day, and it lands on the pages that cannot be cached. Across Fastly’s retail customers, Black Friday 2025 was [only 10.8% above the November daily average](https://www.fastly.com/blog/black-friday-is-dead). The danger is not the day. It is the hour after the email, the minute a drop opens. Adobe’s figures for Cyber Monday 2025 show how concentrated that is: [in the peak hours of 8 pm to 10 pm, consumers spent $16 million every minute](https://news.adobe.com/news/2025/12/adobe-cyber-monday-hits-record). Those shoppers are in baskets and checkouts, which go to your servers, not your CDN, as [part 14 explained](https://www.evaluat.com/blog/what-is-a-cdn). Traffic is not the only cause of sale-day outages. In New Relic’s 2026 survey of 2,575 engineering and IT leaders, [third-party and cloud provider failures is the top cited cause of outages](https://newrelic.com/press-release/20260922), ahead of network failures and software deployments. That is why the [code freeze from part 11](https://www.evaluat.com/blog/black-friday-code-freeze) matters as much as the capacity plan. ## How do you stop a website crashing under high traffic? Find the first limit before your customers do, then raise it or protect it. A load test that ramps traffic past your forecast shows which part saturates first and at what level. The fixes then follow from the stage you want to stop: queueing, timeouts, retries or the spread. - **Measure your ceiling.** A [capacity test](https://www.evaluat.com/blog/what-is-capacity-testing) finds the most traffic your site serves while still meeting its targets. Know that number for checkout, not just the homepage. - **Set timeouts on purpose.** A request nobody will wait for should be abandoned early, not hold a worker for a minute. - **Retry once, in one place.** Brooker’s advice is [to retry at a single point in the stack](https://builder.aws.com/content/3EumjoZascWd1oZiEgL8ORlv3qE/timeouts-retries-and-backoff-with-jitter), with a growing, randomised delay between attempts. - **Shed load rather than serve everyone slowly.** Google’s SRE book says a server [should accept only the requests that it can process and reject the rest gracefully](https://sre.google/sre-book/handling-overload/). A virtual waiting room does this for whole visitors; [part 17 of this guide](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms) covers it. - **Cache what is the same for everyone**, and never purge it at peak. - **Treat autoscaling as help, not a plan.** AWS notes that new instances [need time to stabilize](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-default-instance-warmup.html) after they come into service, while an email multiplies traffic in seconds. ## Common mistakes when planning for high traffic Most of them come from planning for the average instead of the peak minute. - **Blaming bandwidth.** The queue is almost always in front of server work, not the network. - **Sizing for daily or hourly averages.** The failure happens in the minutes after an email or a launch time. - **Load testing only cached pages.** The homepage tests your CDN. Test search, basket and checkout. - **Retrying at every layer.** Each layer’s retries multiply the ones beneath it. - **Trusting autoscaling to catch a spike.** It reacts in minutes, and it does not add database connections. ## How Evaluat shows where your site fails first Evaluat runs each virtual user in an isolated real browser and ramps them up to the level you choose, so you can watch the stages in order: response times and time to first byte climbing per URL, then HTTP errors appearing, with Core Web Vitals showing what shoppers saw at each point. The page that degrades first points at the resource that runs out first. A failure at peak isn’t a percentile. It’s a session. When errors start, open a session from that moment. The session video shows what the shopper saw, the network log shows which request returned a 504 and how long it waited first, and the console log shows what broke in the page. Open the session. Watch the moment it broke. The boundary is worth stating. Evaluat measures the site from the outside, the way customers reach it, from the region closest to them. It does not see your worker pools or database connections directly, so pair it with your server monitoring to confirm which limit was hit. And because virtual users ramp up over minutes, it rehearses rising peaks, not every visitor arriving in the same second. Websites under too much traffic queue, time out, retry and then fall over, in that order. Find out which part of yours runs out first while there are still weeks to fix it. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) to find your site’s first limit before Black Friday. [Previous · Part 14What a CDN does (and does not) do for your site under load](https://www.evaluat.com/blog/what-is-a-cdn) [Next · Part 16Caching explained: browser, CDN, full-page and object caches](https://www.evaluat.com/blog/caching-explained) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### Why do websites crash when too many people visit? Every part of a website can handle only so many requests at once, limited by worker processes, database connections and CPU. When more requests arrive than it can serve, they queue, pages slow, and requests start timing out. Retries and refreshes then add more load, and the failure spreads from the first part to run out. ### What happens when a website gets too much traffic? First it slows, because requests wait in queues for busy servers. Then it starts returning errors such as 502, 503 or 504 as requests time out or are refused. If the overload continues, servers are pulled from service or restart, and the site can stay down even after the traffic falls. ### Is a website crash caused by a lack of bandwidth? Rarely. Most sites run out of server work long before they run out of network capacity, because each page needs processing, database queries and calls to other services. The queue forms in front of whichever of those is slowest, not in the network cable. ### What does a 503 error mean? A 503 Service Unavailable means the server cannot handle the request right now, usually because of overload or maintenance, and expects to recover after a delay. On a busy site it often means a server or load balancer is refusing extra requests to protect itself. Pressing refresh adds to the problem. ### How many visitors can a website handle? There is no general number, because it depends on what each visitor does and which part of the site runs out first. A static page served from a CDN can handle huge numbers, while a checkout that queries a database and a payment provider may slow at a few hundred shoppers at once. Measure it with a load test on your real journeys. ### Why do websites crash during sales and ticket launches? Because demand arrives in a few minutes rather than spread over a day, often straight after an email or a launch time. The busiest pages, basket, checkout and stock checks, are also the ones that cannot be cached. Sites that cope usually found their limits in advance and queue visitors rather than serve everyone slowly. ### Can autoscaling stop a website crashing? Not on its own. New servers take time to start and settle, while a sale email can multiply traffic in seconds, and autoscaling does not add database connections or speed up a payment provider. It helps with gradual growth; a sudden peak needs capacity that is already in place. ### How do you stop a website crashing under high traffic? Find the first limit with a load test before the event, then raise it or protect it. Set sensible timeouts, retry once at a single layer, cache what you can, and turn away or queue extra visitors rather than slow everyone down. Avoid purging caches or deploying at peak. Related reading ## More from the blog [![A capacity test steps the load up in plateaus, from 500 to 1,750 virtual users, while the 95th percentile response time is read at each step. Response time stays under the two second target up to 1,250 users, which is the usable ceiling, crosses the target at 1,500, and the site only breaks at 1,750. Capacity is the last step that still meets the target, not the breaking point.](https://www.evaluat.com/blog/what-is-capacity-testing-cover.svg)](https://www.evaluat.com/blog/what-is-capacity-testing) ### [What is capacity testing?](https://www.evaluat.com/blog/what-is-capacity-testing) [Most teams can tell you when their site falls over. Far fewer can tell you when it stops being good enough, and that second number is the one customers feel. Capacity testing, in performance testing, finds it. It measures how many users your site can serve while still meeting the speed and error targets you set in advance.](https://www.evaluat.com/blog/what-is-capacity-testing) [Ahmad Farzan · 18 September 2026](https://www.evaluat.com/blog/what-is-capacity-testing) [![A virtual waiting room drawn as a queue, a gate and a shop. On the left, a crowd of shoppers waits in the queue. In the middle, the gate lets them in at 150 a minute. On the right, the site holds 900 shoppers at once and stays fast for everyone inside. The queue is the easy part; the number at the gate has to be measured.](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms-cover.svg)](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms) ### [What is a virtual waiting room?](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms) [A virtual waiting room is a holding page in front of a website that lets visitors in at a rate the site can serve and queues everyone else, so a busy sale becomes a wait instead of a crash. Installing one is the easy part. Choosing how many shoppers it lets in is the hard part, and that number has to be measured.](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms) [Ahmad Farzan · 28 October 2026](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms) [![Time to first byte for the same page on a quiet afternoon and on sale day, drawn as stacked bars against Google's thresholds of 0.8 seconds for good and 1.8 seconds for poor. Network travel takes 435 milliseconds both times. Server time is 200 milliseconds when quiet, giving a good TTFB of 635 milliseconds, and 1,400 milliseconds when requests queue, giving a poor TTFB of 1,835 milliseconds.](https://www.evaluat.com/blog/time-to-first-byte-cover.svg)](https://www.evaluat.com/blog/time-to-first-byte) ### [Time to First Byte (TTFB), explained](https://www.evaluat.com/blog/time-to-first-byte) [Time to First Byte (TTFB) is how long a browser waits between starting to load a page and receiving the first byte of the reply. Good is 0.8 seconds or less. It is not a Core Web Vital, but it is the first slice of every page load and the number that moves first when your server starts to queue.](https://www.evaluat.com/blog/time-to-first-byte) [Ahmad Farzan · 8 October 2026](https://www.evaluat.com/blog/time-to-first-byte) See it on your site Test in real browsers.\ Debug in real sessions. ## Want to see this measured on your app? 30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report. [Book a demo](https://www.evaluat.com/demo?intent=performance) [How it works](https://www.evaluat.com/how-it-works)