Most CRM capacity incidents are predictable in hindsight. Marketing sends a large campaign, thousands of people click through to a form that writes into the CRM, and an integration that worked fine for a trickle of records starts timing out. A load test, run before the event, turns that surprise into a to-do list.

Decide what you are testing

“Load test the CRM” is too vague to be useful. Write down the scenario in plain language first:

• A campaign email goes out at 9 a.m. and drives a burst of web form submissions that create leads.
• The whole support team logs in at the start of a shift and opens their queues.
• A quarter-end push means every rep updates opportunities within a few days, and finance runs heavy reports.
• A data import of a large list happens while users are working.

Each scenario stresses different parts: form endpoints and lead creation, authentication and list views, reports and database load, or bulk write paths. Pick the two or three that your business actually fears.

Also decide the question the test will answer. “Can we handle the expected load with comfortable headroom?” is better than “how much can it take until it breaks?”, though knowing the break point is valuable too.

Get the numbers for the scenario

You need a realistic load shape, taken from your own history, not invented. Look at the previous campaign or peak: how many form submissions arrived, over what period, what the burst looked like in the first few minutes. Marketing can often estimate the size of the next send. Add a margin for success, since a campaign that works better than expected is exactly when you cannot afford to fall over.

Model user behaviour too. A realistic mix is not all one request type. Real users search, open records, edit and save, and some run reports. Weight the mix by what you see in production.

Where to run it

Never aim a surprise test at production during business hours. Options, from safest to most realistic:

1. A production-like staging environment with the same configuration and a similar data volume. Best option when it is truly comparable.
2. Production during a planned quiet window, with the team watching and a stop button ready. Sometimes the only way to see the true setup, but riskier.

Data volume matters more than people think. A test against a nearly empty database tells you nothing about how a table with millions of rows behaves. Use masked production data or generated data of similar size and distribution.

If you use a managed CRM, check the vendor’s policy first. Many restrict or forbid load testing against their platform without notice. Test your own surrounding components, such as the web forms, middleware and integrations, and ask the vendor about their limits in writing.

What to measure

Response time alone is not enough. Capture:

• Latency percentiles, not just averages. The slowest few percent of requests are what users complain about.
• Error rates and error types, such as timeouts versus rate-limit responses.
• Throughput, the number of successful operations per second.
• Resource use: CPU, memory, database connections, queue depth, disk activity.
• Downstream effects: how long do queued jobs take to drain after the burst ends?

Increase the load in steps and hold each step long enough to settle. Watch for the point where latency starts to climb sharply, which is usually a sign that something saturated: a connection pool, a CPU, a lock, or an external rate limit.

Test plan outline

Phase	What happens	What you check
Baseline	Light, steady traffic	Normal latency and resource use
Ramp	Increase load in steps	Where latency and errors begin to rise
Peak hold	Hold expected peak plus margin	Stability, error rate, queue growth
Spike	Sudden jump to simulate a send	Recovery and autoscaling behaviour
Soak	Moderate load for a long period	Memory leaks, slow resource exhaustion
Recovery	Return to baseline	Time to drain queues and normalise

Reading the results

Look for the first bottleneck, fix it, and re-test. Bottlenecks hide behind each other, so a single run rarely tells the whole story. Common findings:

• A database connection pool that is too small, so requests queue waiting for a connection.
• A single synchronous integration call inside the form-handling path. Move it to a background queue.
• Lock contention on a hot record, such as a counter or a shared owner field updated by every lead.
• Rate limits on a connected service that the CRM calls for every record.
• Autoscaling that reacts too slowly for a sharp spike, so a pre-warmed minimum capacity before the event is wiser.

A hypothetical

A company plans a webinar promotion and expects a large burst of registrations in the first ten minutes. Their test in staging shows form submissions succeed until the rate approaches the expected peak, then response times jump because each submission waits on a call to an email service. Moving that call into a queue lets the form return immediately, and a worker sends the emails at its own pace.

A second round exposes a different limit: lead assignment rules updating a shared round-robin counter. They change it to assign in batches. On the day, they raise baseline capacity an hour beforehand, assign someone to watch the dashboards, and keep the queue-drain graph open. It is not glamorous, but nothing falls over.

Day-of checklist

• Raise capacity ahead of the send rather than relying only on autoscaling.
• Confirm monitoring and alerts work, and who is on call.
• Pause non-essential heavy jobs such as big imports and exports.
• Have a plan to throttle the campaign send in batches if the system struggles.
• Tell the support team what to expect.

Frequently Asked Questions

How often should we load test? Before any major planned peak, after big architecture changes, and perhaps yearly as a routine. Do not rely on a test from two years ago.

Can we load test a SaaS CRM? Usually only within the vendor’s rules. Check their policy and talk to them; test your own integrations and forms independently.

What load should we simulate? Your realistic expected peak, taken from past data, plus a margin for a better-than-expected response. Then also find the break point to know your headroom.

Is a test with fake data valid? Yes if the data has similar volume, shape and relationships to production. Tiny or uniform data gives misleading results.

What if the test shows we cannot handle the load? Good, you found out cheaply. Fix the first bottleneck, re-test, or reduce the peak by staggering the campaign send.

Next Step

Take your next planned campaign, write a one-paragraph scenario with expected volume and timing, and ask the owner of the web forms and integrations whether they have ever tested that volume. If not, schedule a staged test two weeks before the send.