When should a campaign be postponed or the page taken down, and who makes that call?

The principle first: once the system is taking orders it cannot complete, leaving it open does more damage than closing it. Three signals decide it — orders failing after the customer has already been charged or notified, stock figures drifting far enough that overselling becomes likely, and errors spreading beyond checkout into other flows. If any one of them is present, swapping the campaign page for a notice is better than letting people retry over and over. The call belongs to the business or operations side rather than to whichever engineer happens to be busiest, which means someone has to be given that authority before the campaign starts. Prepare the public wording in advance too: what happened, how places or discounts will be honored, when it reopens, published on the campaign page and your social channels at the same time.

Do small campaigns need load testing too?

What matters is not the size of the campaign but how concentrated the traffic is. A flash sale announced to a modest list can put more pressure on a system in a single minute than a normal day produces in total, simply because everyone arrives at the same moment. A campaign that runs for a fortnight with traffic spread evenly may involve far more people and never strain anything. The way to judge it is to estimate how many people will be operating the site simultaneously during the busiest minute, not how many will visit overall. If that peak sits well above your everyday level, a test is worth the time. If it is only slightly higher, putting the same effort into monitoring and a fallback plan usually pays back more.

Can we run the stress test against the live site?

As a rule, no, unless it happens during a window when you are certain nobody is using the site and the relevant teams have been told in advance. Loading the production environment can degrade the experience for real visitors, and the messier problem is that test traffic writes real data: fake orders, fake accounts, and polluted analytics all have to be cleaned up afterwards, and connected payment or messaging services may genuinely be triggered. The standard approach is to stand up a test environment built to the same specification and push that instead. If circumstances leave you no option but to test against production, confirm first that the test path cannot create orders, cannot send notifications, and is excluded from analytics reporting, and keep a way to stop the run at any moment.

Traffic Spike Prep: Load Testing and Scaling

The worst outcome for a campaign is not an empty room. It is spending the budget, sending the traffic, and then watching the site refuse to load during the exact minutes that mattered most. The loss lands twice: the orders never happen, the marketing spend is wasted, and the complaints stay online long after the sale ends.

What makes this hard to anticipate is that running smoothly on a normal day tells you very little about surviving a peak. Everyday traffic is spread out; campaign traffic is concentrated, and the two put fundamentally different kinds of pressure on a system.

This guide breaks the preparation into five stages — estimating, testing, reinforcing, planning fallbacks, and monitoring — so the work rests on evidence rather than a hunch.

Estimate the peak, not the total

The first job is turning “a lot of people are coming” into something you can actually verify. What you need is not the total number of visitors across the campaign, but how many people will be operating the site at the same time during its most crowded minute.

There are a few ways to work backwards to that figure:

From the marketing plan. The first few minutes after an email or push notification goes out are usually the high point, and influencer or press coverage concentrates into a short window after publication. Lay the expected reach of every channel, the click rate you are assuming, and the send time on a single timeline, and you will see where the peaks stack on top of each other.
From your own history. Look at the analytics for the same campaign last year, or the last comparable promotion, and find the highest concurrent figure it reached; then adjust for how much harder you are pushing this time. If the site does not yet have reliable measurement in place, start by filling that gap using A Practical Guide to GA4.
From the allocation. When stock or places are limited, the number of people competing is typically far larger than the number available, and that gap belongs in the estimate.

A worked example (the figures below are illustrative assumptions only, not industry values to cite — substitute your own history): say the email goes to ten thousand subscribers, and your past sends lead you to assume one in ten opens and arrives within the first ten minutes. That is a thousand people spread across those ten minutes, and if half of them land in the first two, the busiest minute has to absorb a couple of hundred people operating at once. Run the same arithmetic for the push notification and the social post, stack all three on one timeline, and the tallest column is the target your stress test has to hit.

Two mistakes are common at this step. The first is estimating only the campaign total and never converting it into that busiest minute. The second is treating the result as the target without adding a safety margin on top — the estimate itself will be wrong, and the promotion may outperform expectations, so the number you build toward should sit above what you calculated.

The estimate does not have to be precise, but it does have to produce a target you can test against — something like “the system has to absorb this many checkouts per minute at peak.” Without a target there is no pass mark for a stress test, and running one tells you nothing about whether you are ready.

The second thing worth estimating is the shape of the traffic. The same number of people arriving evenly across an hour and the same number arriving in the half-minute after a sale opens are completely different problems.

What to measure in a stress test

A stress test uses tooling to simulate large numbers of users operating the site at once, so you can observe where it starts to slow down and where it starts to fail. A few things decide whether the exercise is useful.

Test the real journey, not the home page. Home pages are usually the easiest thing to cache, so they perform beautifully under load and tell you nothing. What you need to exercise is the path that will actually be hammered on the day: product pages, adding to cart, checkout, signing in, submitting forms.

Four numbers to watch:

Response time. How long a page or request takes. The average matters far less than the slow tail — a respectable average means nothing to the share of visitors who waited long enough to conclude the site was broken.
Requests handled per second. The practical throughput of the system.
Error rate. The point at which failures start appearing under rising load, which is usually where the real ceiling sits.
Resource usage. Which of processor, memory, or database connections runs out first. That is what tells you which layer the bottleneck lives in.

You are looking for the breaking point. The purpose of a stress test is not to prove the system “holds up” but to find the load at which it degrades and the way it degrades. Raise the load in steps, record the two thresholds where it starts to slow and where it starts to fail, and compare them with the peak you estimated earlier. The gap between those numbers is your actual margin.

The test environment has to resemble production. Results from a setup with a materially different specification are not transferable. At the same time, confirm that the simulated traffic cannot create real orders, cannot send notifications, and will not contaminate your analytics.

Where the bottlenecks usually are

In practice, the problems stress testing surfaces tend to cluster in the same handful of places:

Database queries. Easily the most common. With small volumes nothing feels wrong, but once traffic rises, a query missing an index or one being re-run inside a loop will bring the database down before anything else.
Uncached landing and campaign pages. Recalculating identical content for every single visitor is pure waste. On a normal day that only burns spare capacity; at peak it means every visitor is asking the database the same question at the same moment.
Images and static assets. Large uncompressed images consume bandwidth and drag out load times. On an ordinary day the result is merely slow; at peak they can swallow your outbound bandwidth entirely and take checkout — the one flow that cannot fail — down with them. The everyday side of this work is covered in Website Speed Optimization.
Contention over stock or codes. When many people go after the same limited inventory, a poorly designed locking approach creates long queues and, in the worst case, oversells. This is the single most common failure in e-commerce promotions; the surrounding design considerations are discussed in Building an E-commerce Site.
Limits on external services. Payment, SMS, logistics, and invoicing integrations each impose their own throughput limits, and however fast your system is, it will queue behind theirs. Confirm those limits and the provider’s peak-period behavior in advance.
Background jobs competing with the front end. Report generation and scheduled tasks running during the campaign window will fight real users for the same resources.

Scaling up and scaling back: prepare both

Scaling up means adding resources to carry more people. Cloud services generally let you raise the specification before a campaign and bring it back down afterwards, which is the most direct option. Three caveats apply: not every layer can be fixed by adding capacity, and the database is usually the hardest one to scale; changing a specification may itself require a restart; and any scaling has to be completed and verified before the campaign rather than attempted live. The hosting model you are on determines which of these options exist at all, which is worth checking against How to Choose Web Hosting.

Scaling back, or graceful degradation, means deliberately switching off non-essential features under pressure so that resources go to the flows that matter. It gets overlooked far more often than it should, and it is frequently more effective than adding capacity, because it takes effect immediately instead of waiting for resources to be provisioned.

Switches worth building in advance include: replacing live stock counts with an approximate status, hiding recommendation and best-seller blocks, temporarily disabling search, serving a pre-generated static page in place of a dynamic campaign page, and moving non-essential notifications into a batch to be sent later.

The critical part is that these switches must be built and tested before the campaign, so that on the day somebody only has to make the call and flip them, rather than write and deploy code under pressure. It is also worth deciding in advance how queueing will work: when demand genuinely exceeds capacity, showing people a waiting screen that visibly progresses is far better than showing errors and inviting everyone to refresh — refreshing only adds to the load you are already struggling with.

What to watch on the day

The goal on the day is not that nothing goes wrong. It is knowing within minutes when something does, and being able to respond. Prepare a monitoring view everyone involved can see, covering at least:

Live concurrent users and request volume.
Response times for the critical flows, checkout and sign-in above all.
The error rate, and which errors are most frequent.
Resource usage on the servers and the database.
A real business metric: successful orders submitted per minute. This one is the most honest indicator of all — when every technical metric looks normal but orders suddenly stop, something has broken that your monitoring did not catch.

Assign the people and the process as well: who is watching, who gets told when something looks wrong, who has the authority to trigger degradation, and who publishes any public notice. Those roles need to be settled before the campaign, not negotiated in a group chat while it is happening.

Picture this: shortly after the sale opens, orders are running oddly low while the pages themselves look fine. If somebody is watching the order count, the slow payment responses behind it get spotted immediately and the backup route can be switched on. If the only thing being watched is server resource usage, everything will look healthy right up until the phones start ringing.

What to do once the campaign ends

As soon as it is over, while the detail is still fresh, write down three things.

Record what actually happened. What the real peak was, which minute it landed in, and how far it sat from your estimate. That record is the most valuable input you will have for the next campaign.

Clean up the temporary measures. Raised specifications come back down as planned, degradation switches return to normal, and settings that were loosened for the occasion get restored. Temporary measures left in place have a habit of turning into security exposure or recurring cost.

Put the bottlenecks you found on the improvement list. Anything you got through by throwing resources at it still has the underlying problem. While the measurements are fresh, schedule the work to fix it properly so the next campaign is not another gamble.

The campaign date is already set and you are not sure the current system will hold: the earlier that gets looked at, the cheaper it is to fix. Talk to NETVANA about your project. Software work is quoted case by case with no fixed packages, and we start by asking about the scale of the campaign, the channels behind it, and your existing architecture, then decide whether a stress test comes first or whether the known bottlenecks should simply be fixed. What each service covers and delivers is listed in the software services overview.

Further reading: for everything to confirm before a campaign page goes live, see The Website Launch Checklist. For payment limits at peak and how reconciliation is handled, see Payment Gateway Integration in Taiwan. For fulfillment and status updates once the orders land, see Logistics Integration in Taiwan. And because campaign periods are also peak season for attacks, see Website Security Basics for Businesses.