Find Your Breaking Point Before Your Users Do

A structured capacity assessment using progressive load testing to identify your system's breaking point, measure auto-scaling response time, and locate the infrastructure bottleneck limiting your growth.

Duration: 3 days Team: 1 Senior Load Testing Engineer

You might be experiencing...

You don't know how many concurrent users your system can handle before latency degrades
Auto-scaling is configured but you've never measured how long it takes to kick in under real load
You're planning a marketing campaign but have no data on whether your infrastructure can handle the traffic
An investor or enterprise prospect is asking about your system's capacity and you have no measured answer

A capacity assessment answers the most fundamental infrastructure question: how many users can your system handle before it breaks? This question becomes urgent before product launches, marketing campaigns, seasonal peaks, and enterprise sales conversations — but it is much better answered proactively, with controlled load testing, than reactively, during an outage.

The progressive load testing methodology used in our capacity assessment increases virtual user load incrementally, measuring latency and error rate at each step. The goal is to find the inflection point — the user count where latency transitions from linear growth to non-linear degradation. That inflection point is your practical capacity ceiling, and the component that saturates at that point is your bottleneck.

Auto-scaling behaviour is frequently the most surprising finding: cloud auto-scaling groups take 3–8 minutes to provision and warm up new instances, during which the existing instances are absorbing excess load. A system that can handle 3,200 users steadily may become unstable at 2,500 users during a traffic spike because auto-scaling cannot respond fast enough. Measuring this gap is essential for accurate capacity planning.

Engagement Phases

Day 1

Workload Modelling

We analyse your traffic patterns, user journey analytics, and API call distribution to build a realistic load model. We script the 3–5 most critical user journeys in k6 or Locust, configure think time and user behaviour patterns, and prepare infrastructure monitoring connections.

Day 2

Progressive Load Execution

We run a series of load tests with increasing virtual user counts: 100, 250, 500, 1000, 2000, and beyond until the system degrades. We record P50/P95/P99 latency, error rate, and throughput at each level. We observe auto-scaling triggers and measure time-to-scale. We identify the inflection point where latency begins to degrade non-linearly.

Day 3

Analysis & Recommendations

We identify the binding constraint — the component that becomes the bottleneck at your capacity ceiling — and provide targeted recommendations for extending capacity. We produce a capacity report with breaking point, current ceiling, auto-scaling behaviour, and projected headroom at current growth trajectory.

Deliverables

Realistic load model with k6/Locust scripts (your team retains these)
Progressive load test results (P50/P95/P99 at each VU level)
Breaking point report with bottleneck identification
Auto-scaling behaviour analysis with measured scale-out time
Capacity planning recommendations with projected growth runway

Before & After

MetricBeforeAfter
Breaking pointUnknown3,200 users identified
Auto-scale timeAssumed instant4.5 min measured
BottleneckUnknownDB connection pool

Tools We Use

k6 / Locust / Gatling Grafana / Datadog CloudWatch / Cloud Monitoring

Frequently Asked Questions

Do load tests require downtime or impact production?

Load tests are run against a staging environment that mirrors production configuration. If you want to validate production capacity specifically (required for some compliance scenarios), we run tests during a low-traffic maintenance window with agreed-upon abort thresholds. We never run load tests against production without explicit sign-off.

How do you create a realistic load model without access to production traffic?

We use your analytics data (Google Analytics, Mixpanel, or similar) to understand user journey distribution and session characteristics. We instrument a sample of production traffic using HAR capture or APM sampling to identify the API call patterns behind each journey. For new products without traffic history, we model based on your design documents and comparable benchmarks.

What if we don't have a staging environment?

This is common and we can work around it in several ways. If your cloud provider supports it, we can spin up a temporary staging environment from infrastructure-as-code for the assessment. Alternatively, we can test in a designated off-peak production window with careful load ramping and abort conditions. We discuss the best approach during scoping.

Know Your Scaling Ceiling

Book a free 30-minute capacity scope call with our load testing engineers. We review your architecture, traffic expectations, and upcoming scaling events — and scope the load test that will give you the data you need.

Talk to an Expert