Why does my webshop crash when traffic peaks?
You send the newsletter, the first clicks come in and a few minutes later the product page stops loading. The first email you get after that is from a customer who cannot check out. At that moment you want to know why your webshop crashes and how to get it back as fast as possible.
Every minute of downtime costs revenue and unsettles customers. Even so, I would not order a bigger server until it is clear where the bottleneck is. An outage like this is rarely one isolated technical incident. Usually a chain gives way under pressure: hosting, application code, database or integrations, often in combination. Extra capacity is quick to arrange. If the cause is a heavy query or a slow integration, the same outage will be waiting for you at the next campaign.
Why your webshop crashes during a peak
On an ordinary Tuesday your server has plenty of room. During a sale, hundreds of visitors search at the same time, load product images, fill their baskets and pay. All of those processes call on the same database or the same external API at the same moment. As soon as one component falls behind, queues start piling up. That is why a capacity measurement on a quiet day tells you little about what happens when the newsletter goes out.
Shared hosting can be a fine start for a small or quiet webshop. Once your revenue depends on speed, it becomes a limitation. You share capacity with other sites, you have little control over the settings and you often only hear about a problem when a customer reports it.
A VPS or cloud server is not automatically well configured just because it has more capacity. Too little memory, unfavourable PHP settings or a web server that handles too few simultaneous requests will make that server lock up as well. The setup has to fit your application and the moments when load peaks.
Look at the database and integrations first
If I could pick one place to start during an outage, it would be the database. Stock, prices, customer data, orders and product variants all come together there. A page that runs dozens of heavy database queries per visit cannot keep up when it gets busy. The database starts refusing connections or leaves tasks waiting indefinitely.
Caching takes a lot of that pressure away, provided you choose deliberately what to cache. My rule of thumb: whatever is the same for every visitor, such as a category page, can go in the cache. Stock, shopping baskets and personal prices have to stay current. Cache too aggressively and a customer sees the wrong information. Cache too little and your platform does far more work than it needs to.
Next I look at everything that has been added over the years. An extra payment method, a marketing tool or a link to your accounting software seems small. Yet every extension brings code, database requests and dependencies with it. Platforms that have been developed for a long time often run a collection of plugins where nobody knows exactly what they do during checkout or a stock update.
Custom code can have the same effect if it was never tested under concurrent load. A function that fetches one product price is harmless. A function that checks thousands of prices through an external integration on every page view will take your shop down as soon as it gets busy. Problems like these often surface after an update, while the cause had been in the code for much longer.
Then the integrations themselves. Payment providers, fulfilment partners, ERP and PIM systems, shipping services and email platforms often sit right in the middle of your order flow. If your webshop keeps waiting for a service that responds slowly, processes stall, and in a busy checkout you notice that immediately. A stock check that runs synchronously for every visitor can often be updated periodically and in a controlled way instead. With timeouts, a queue, error handling and a fallback, your webshop keeps selling when an external service has a hiccup.
A 504 does not say which part is waiting
Changing settings straight away during an outage can make the problem worse. Start by writing things down: the time, the error message, which pages were affected and what changed at that moment. Was a campaign running? Was an import in progress? Was an update or a new integration deployed just before? With that context you reach the cause much faster.
Then follow the chain. Server monitoring shows whether CPU, memory, disk space or network traffic is hitting a limit. The application logs contain errors in code, plugins and processes, and database monitoring shows which queries are slow and which tables are getting locked. If checkout is where it fails, also request the logs from your payment provider and your API integrations.
An error code such as 502, 503 or 504 is a clue, not a diagnosis. A 504 means one component is waiting too long. That could be an exhausted PHP worker, a slow database query or an API that is not responding. To tell those apart you need someone who looks at infrastructure and application together.
I would skip a load test with a thousand homepage visits. It mostly proves that your homepage is fast. A useful test mimics what customers really do: search, filter, open product pages, log in, order and pay. That mix is exactly where you see things start to stall.
Include the jobs that run out of sight too, such as stock imports, invoice generation, product feeds and backups. If one of them starts in the middle of a sale, it claims capacity your checkout needs. Plenty of processes do not have to run right away. Scheduling and priorities often gain you more here than heavier hardware.
A bigger server mostly buys time
When the shop is down, getting it reachable comes first. Adding capacity, temporarily disabling a faulty extension or pausing heavy background jobs is sensible at that point. Treat it as first aid. As long as the underlying bottleneck remains, the problem returns at the next peak.
If one flawed query swallows all available capacity, it will do the same on a bigger server, just a little later.
Scaling up is the right step when your visitor numbers grow structurally and the application runs efficiently. A busy B2B webshop with complex pricing agreements has different demands from a catalogue with few transactions. Dedicated resources, a separate database or a scalable architecture can make sense then, and optimisation will not always replace such an upgrade. The order I stick to: measure, pin down the cause, improve, and only then add capacity where it is needed.
Agree who watches which part
If your hosting sits with one party, development with a second and an integration with a third, the analysis often takes too long. Each party looks at its own piece, while your customer only sees a webshop that does not work. So write down who is responsible for hosting, application management, updates, integrations and monitoring.
Test changes in a separate environment before they go live, even if your webshop is small. That is where you check updates, theme changes and new integrations while the live shop keeps selling. Add automatic backups and a recovery procedure you know how to run. Set up monitoring so that you get more than an alert when the website is offline: rising response times, increasing error rates and unusual load should trigger a signal as well.
At LJPc, development, hosting and support sit under one roof in Assen. That lets us trace an outage from the server into the code, which gives you room to plan campaigns and growth with more confidence.
If a sale or newsletter is on the calendar, put its send time next to the schedule of your imports, feeds and backups. Move anything that can wait to a quiet hour. Then check in your monitoring whether you get a signal when response times rise. If you only hear something once the site is already down, that is the first thing I would have changed.