A primary school ran an online auction to raise money for its new library. Parents and local businesses had donated about sixty items: a signed football, a weekend cottage stay, framed pictures by the pupils, a term of music lessons. The parents' committee built a simple bidding site on the school's small shared hosting plan and announced it a fortnight ahead. Bids trickled in. Everything looked fine.
The auction was set to close on a Sunday evening. In the final hour, the committee shared the link in several parents' chat groups at once, with a reminder that the most popular items were about to end. Then it all stopped working at the one moment the money was decided. This is a fictional composite, but anyone who has run a time-limited event on small hosting has seen some version of it.
The story is worth telling in detail because the cause was not a fault. The site did what it was built to do, for the number of people it was built for.
A site that worked until it mattered
For two weeks the traffic was gentle. A few dozen parents visited each evening, placed a bid, and left. On a typical visit the site loaded a PHP page, ran several database queries to fetch the item and its current highest bid, and returned about 300 KB of HTML, images and styles. Pages came back in under a second. The committee had tested it themselves, with five people, and it felt quick.
What nobody measured was how much the plan could serve at once. Shared hosting divides a server's resources among many accounts. A typical small plan caps the number of PHP processes that can run at the same time, often somewhere between a dozen and a few dozen, and limits memory and CPU time per account. Those limits are not a problem when requests arrive one at a time. They matter when everybody arrives at once.
Sunday evening, minute by minute
| Time | What was happening | What visitors saw |
|---|---|---|
| 19:00 | Message goes out in the chat groups. About 40 visitors in the first few minutes. | Normal pages, slightly slower. |
| 19:10 | Link forwarded to wider groups, and to a local community page. Concurrent visitors pass 150. | Pages take 5 to 10 seconds. |
| 19:20 | Many people refresh repeatedly to see the latest bid. Around 300 people are on the site. | Timeouts and error pages. |
| 19:30 | The most popular item reaches its closing minutes. Bids fail to save. | "Service unavailable" or a blank page. |
| 19:45 | The auction closes at its scheduled time. Several items have received no final bids. | Site returns slowly, final totals look low. |
The last row was the painful one. Auctions famously concentrate their value in the final minutes, when people who have been watching decide to commit. The site broke in exactly that window.
What was actually happening on the server
Think of the plan as a shop with a small number of tills. Each visitor's request needs a till for the time it takes to build the page. If requests arrive slower than the tills can serve them, nobody waits. If they arrive faster, a queue forms, and queued requests wait. Once the queue grows past what the server will hold, or the wait passes the web server's timeout, the visitor gets an error instead.
Two features of the auction made it worse. First, every page showed a live "current bid", so it could not be stored and handed out unchanged, and each visit ran database queries. Second, people refresh in a panic. A visitor who gets no response clicks again, and each click adds another request while the first is still waiting. Three hundred people can produce well over a thousand requests in a minute without anyone doing anything unreasonable.
Wrong turns on the night
The committee's treasurer, a volunteer with no technical background, tried the obvious things. She asked people in the groups to stop refreshing, which reached some of them and made no difference to the rest. She emailed the host, whose support replied the next morning, long after the auction was over. She also tried logging in to the control panel to upgrade the plan mid-event, which in many cases takes minutes to apply and also does not guarantee a fix, because a bigger plan with the same design may still choke.
It is worth saying plainly that none of these was foolish. Without a measure of the plan's limits or a prepared fallback, she had nothing better to reach for.
What the plan could have been given
There were three levers, and each changes the answer by a different amount.
- Reduce the work per request. Page caching, serving images as small compressed files, and storing the current bid in a fast cache instead of querying it every time cut the cost of each visit dramatically.
- Increase capacity. A larger plan, or a virtual server with more workers, raises the ceiling. This helps but costs money for a one-night event.
- Move the load elsewhere. A static page served from a content delivery network can absorb thousands of readers, with only the bid action reaching the real server.
What the committee did next time
For the following auction, they changed the shape of the whole thing rather than tuning the old site. They used a hosted auction service built for timed events, which handles bidding, countdowns, outbid emails and payment capture on infrastructure sized for spikes. The school website went back to being what a school website is for: a page with the date, the rules and a link to the service.
They also changed the human side. The end time was staggered, so that items closed across an evening instead of together. The link was shared at set times rather than blasted out in the final hour, and the message gave a calm reminder that bids placed on the service were recorded. Total raised for the second event was well above the first, though the committee were careful not to credit the technology alone.
Checking it yourself
Before any event with a deadline, run a rough load test. A free tool such as ab (ApacheBench) shows what a small plan can serve:
ab -n 500 -c 50 https://example.com/auction/item/12This sends 500 requests, 50 at a time, and reports requests per second, failures and the slowest responses. Run it against a test copy, not the live site, and with permission from your host, since some hosts treat sudden bursts as abuse. Divide the requests per second by two or three for a cautious estimate of real visitors per minute, because people read between clicks but panic when they cannot load.
Read the plan's resource limits in the control panel, and use the hosting quiz if you are unsure what kind of plan fits an event. For the failure messages you may see on the night, the status code reference explains 503 and 504.
Reading the warning signs earlier
The site gave hints before the evening itself. The previous Thursday, when a single class teacher shared the link, page times had crept from under a second to three or four seconds for about ten minutes. Nobody noticed, because nobody was watching. A simple habit would have caught it: open the site from a phone on mobile data at a busy moment, time how long the item page takes, and write the number down. If a small, ordinary bump in interest triples the response time, a proper rush will not be gentle.
The host's control panel also kept usage graphs for CPU, memory and concurrent processes. Those graphs showed the account sitting at its process limit for much of that Thursday spike. It was all there to read, in a part of the panel the committee had never opened.