Your Site Crashed During Your Biggest Sale. Let Us Talk About Why

There is no worse time for a website to fall over than the exact moment everyone shows up. Flash sale, viral post, product launch, the traffic you dreamed of arrives, and the server quietly gives up. The screenshots of your error page spread faster than your promo did.

Almost always, this is not bad luck. It is infrastructure that was set up once and never built to handle a crowd. No room to scale, no safe way to deploy, no monitoring to warn anyone until customers do it for you.

The fix is not mysterious, but it does need doing before the big day, not during it. Below is the readiness checklist we would walk through with any team that has a major campaign on the calendar. Use it as a self-assessment. Every item you cannot tick is a place your site can break.

Four to six weeks before

1. Know your expected peak

Estimate how many people could hit the site at once, not per day. Look at past campaigns, the size of your email list and social following, and any paid traffic planned for launch hour. Then plan for a multiple of that, because a promo that goes viral does not follow your forecast.

2. Load test the real journey

Testing the homepage alone proves very little. Simulate the path buyers take: landing page, product page, add to cart, checkout, payment. The weak point is usually something unglamorous, like a database query on the cart, a stock check, or the login service. Run the test against a copy of production, find where it bends, fix that, and test again.

3. Put a CDN and caching in front

Images, scripts, and pages that look the same for everyone should be served from a content delivery network, not your origin server. This one step often removes a large share of the load. Be careful with anything personal, such as carts, prices for logged-in users, and stock levels, so nobody sees someone else's data.

4. Make scaling automatic, and test it

If your app runs on cloud infrastructure, configure it to add servers when load rises and remove them afterwards. Then actually trigger it during the load test. Autoscaling that has never been exercised has a habit of hitting an account limit or a slow startup at the worst moment.

5. Check the database separately

Web servers are easy to multiply. Databases are not. Look at slow queries, missing indexes, and connection limits. Consider read replicas for heavy browsing traffic. A surprising number of "the site is down" incidents are really "the database ran out of connections".

6. Ask your third parties about their limits

Payment gateways, shipping calculators, SMS or OTP providers, and search services all have rate limits. Find out what they are, tell them about your campaign if they offer that, and decide what your site does if one of them slows down. A checkout that waits forever for a slow API is as bad as a crashed one.

One to two weeks before

7. Automate deployments and practise rollback

If releasing an update means someone copying files to a server by hand, that is a risk on any day and a serious one on sale day. Set up automated deployments, and make sure you can roll back to the previous version in minutes. Rehearse it once so the steps are not being read for the first time under pressure.

8. Set up monitoring that alerts a person

Dashboards nobody watches do not count. Configure alerts for error rates, response time, server load, and failed payments, sent to a channel the on-call person actually reads. You want to hear about trouble from your monitoring, not from a customer's post.

9. Prepare a graceful fallback

Decide in advance what happens if demand exceeds what you can serve. A queue or waiting-room page that tells people they will get in shortly is far better than an error. A lightweight static version of the campaign page is another good safety net.

10. Protect against bad traffic

Big sales attract bots: scalpers, scrapers, and sometimes deliberate attacks. Basic bot protection and rate limiting at the edge help keep capacity for real customers. If you have never had your site reviewed, a penetration test well before a major campaign is worth considering.

On the day

11. Freeze changes

No new features, no "quick fix" to the homepage an hour before launch. Agree a code freeze a day or two ahead, with only emergency fixes allowed.

12. Name the people in the room

Who watches the dashboards? Who can make the call to roll back or switch on the waiting room? Who updates social media and customer service if something goes wrong? Write the names down, and give customer service a prepared message they can send.

After the day

13. Review, then right-size

Hold a short review: what held, what wobbled, what you would change. Then scale the extra capacity back down. A side benefit of doing this work properly is that it usually trims your cloud bill too, because most setups waste money on capacity they never use efficiently.

When this is overkill

If your site gets steady, modest traffic and campaigns rarely move the needle, you do not need all thirteen items. Good hosting, caching, backups, and regular website maintenance will cover most of the risk. The full checklist pays off when a single day carries a meaningful share of your revenue or reputation.

Releases should not be scary, and big days should not be gambles. If your site is slow, fragile, or unpredictable, or you have a launch coming and too many unticked boxes on this list, our Cloud and DevOps service makes it fast, stable, and ready for the crowd.