For years my answer to "how much traffic can this system handle" was a shrug dressed up as a number. I would look at the current traffic, multiply by some comfortable factor, and call that the ceiling. Nobody ever checked the math against reality until a launch, a marketing push, or a viral post pushed real traffic past whatever number I had guessed. Some of those days went fine. Some of them did not, and the difference had nothing to do with how good my guess was. It had to do with luck.
The uncomfortable truth is that most systems never get load tested until they are already under load. The test environment is a scaled down approximation of production that nobody trusts enough to draw conclusions from, so the load test gets skipped, and the first real load test happens live, with customers as the test subjects and an incident channel as the results dashboard.
Claude Code changed this by making load testing cheap enough to run constantly instead of rarely enough to skip. The tests are not smarter than before. What changed is that generating realistic load, running it safely, and interpreting the results stopped being a specialist project and became a routine part of shipping. Here is the workflow.
Why Guessing Feels Fine Until It Is Not
Guessing at capacity works right up until the moment it does not, and that is exactly what makes it dangerous. A system that has never been pushed past normal traffic looks completely healthy. The dashboards are green. The response times are fast. Nothing in the day to day experience of running the system tells you where the edge is, because normal operation never gets close to it.
The edge only reveals itself under real load, and by the time real load arrives, it is usually attached to a business event that makes failure expensive. A product launch. A press mention. A marketing campaign that actually worked. The worst possible time to discover your breaking point is the exact moment someone hoped you would perform your best.
The other problem with guessing is that systems change underneath the guess without anyone updating it. A dependency gets slower. A new feature adds a query that was fine at current volume and expensive at scale. The capacity number that was true six months ago quietly stops being true, and nobody notices because nobody is testing it.
A system that has never been load tested does not have unknown capacity. It has an unmeasured capacity, and unmeasured is a worse position than knowing a low number, because a low known number is something you can plan around.
The workflow below turns load testing from a rare specialist exercise into routine, automated verification that runs often enough to catch drift before a real event does.
For a related take on replacing hope with evidence in production, see Claude Code for Chaos Engineering, which applies the same discipline to failure instead of scale.
The Traffic Modeling Skill
The first skill answers a question that most load tests get wrong from the start: what does realistic traffic actually look like. A load test built on made up traffic patterns tells you how the system handles made up traffic, which is not the same as telling you how it handles real traffic.
The skill pulls real traffic data, usage logs, and endpoint frequency to build an honest model of how requests actually distribute across the system. It captures which endpoints get hit most, what the read to write ratio looks like, how traffic clusters around specific user actions, and how it spikes around known events like a checkout flow or a content release.
This model becomes the shape of every load test that follows. Instead of hammering one endpoint at a flat rate, the generated load mirrors the mix and rhythm of real usage, scaled up to the level being tested. A system that survives realistic traffic at ten times normal volume tells you something true. A system that survives a flat hammer test on one endpoint tells you almost nothing about the system people actually use.
The Generation Skill
The second skill takes the traffic model and turns it into an actual load test, run against a real environment in a way that will not take down anything it should not.
The skill generates the load at increasing steps, starting near normal volume and climbing toward the target, watching key metrics at each step before moving to the next. This staged approach is what makes the test safe to run against a real environment. A test that jumps straight to ten times normal load with no ramp gives you a crash and very little useful data about where things actually started to break.
At each step the skill records the metrics that matter: response times, error rates, resource utilization, and queue depths across every service in the path, not just the one being targeted. The breaking point is rarely the service you expected. It is the shared cache, the database connection pool, or the downstream API with its own limits that nobody remembered to test.
The skill also knows how to stop. If error rates or response times cross a defined safety threshold, the test halts automatically rather than pushing further and causing real damage. The goal is to find the edge, not to fall off it.
The Bottleneck Skill
Finding that a system broke at a certain load level is useful. Finding out exactly why is what actually lets you fix anything. The third skill analyzes the results from a generation run and identifies the specific bottleneck that caused the degradation.
The skill correlates the metrics across every layer at the moment things started to go wrong. It looks for the first metric to cross its own threshold, the resource that saturated before the others, the queue that started backing up while everything downstream still looked fine. That first domino is usually the real constraint, even when the visible symptom shows up somewhere else entirely.
The output names the actual limiting factor. A connection pool sized for a load that traffic outgrew months ago. A single threaded piece of code that becomes the bottleneck long before CPU or memory get close to their limits. A downstream dependency with a rate limit nobody documented. Naming the real constraint is the difference between a fix that helps and a fix that just moves the problem somewhere else.
This is the same instinct behind Claude Code for Performance Optimization Patterns, applied specifically to the question of where a system stops scaling rather than where it runs slow under normal conditions.
The Reporting Skill
The fourth skill turns a load test run into something a team can act on without needing to be the person who ran it. It produces a report with the traffic level the system handled cleanly, the level where it started to degrade, the level where it broke, and the specific bottleneck behind the break.
The report tracks this over time, run after run, so capacity becomes a trend line instead of a single number frozen at whatever moment someone happened to test it. A capacity ceiling that has been quietly dropping for three releases is a very different problem from a stable ceiling, and only a tracked trend line shows you which one you have.
It also maps capacity against known upcoming events. If a marketing push is expected to send five times normal traffic and the last test showed degradation at three times, that gap is visible weeks before the event instead of during it, while there is still time to do something about it.
How the Workflow Runs in Practice
The traffic modeling skill runs first, building or refreshing the realistic traffic shape from current usage. The generation skill then runs that shape as a staged load test against a safe environment, climbing in steps and recording metrics at each one, with an automatic stop built in if things start to go wrong.
When a run shows degradation, the bottleneck skill analyzes exactly where and why. The reporting skill folds the result into the ongoing capacity trend and flags any gap against known upcoming events. The whole cycle runs on a schedule, not just before launches, so capacity drift gets caught while it is a routine finding instead of a live incident.
Over time the answer to "how much traffic can this handle" stopped being a shrug. It became a specific number, tested recently, with a named reason it stops there and a trend line showing whether that number is moving in the right direction.
What This Workflow Did to My Practice
The first change was finding a bottleneck I had never suspected. A service I considered lightly loaded turned out to be the first thing to fall over, because of a connection pool setting from an early config that nobody had revisited as traffic grew. It had been quietly the real ceiling on the whole system for months.
The second change was how I plan for known traffic events. Before the workflow, planning for a launch meant hoping the normal comfortable margin held. After the workflow, it means running the actual expected traffic shape against the system beforehand and knowing, with evidence, whether the margin is real.
The third change was that capacity stopped drifting silently. A ceiling that used to erode release after release without anyone noticing now shows up as a moving trend line, caught during a routine scheduled run instead of during the event that was supposed to prove the system could scale.
The fourth change was the biggest one. I stopped answering capacity questions with a guess dressed up as confidence, and started answering them with a number backed by a recent test. That shift changes every conversation about launches, marketing pushes, and growth, because the answer is no longer a feeling, it is a measurement.
For the full picture of how I run production systems with Claude Code, the complete series on DEV.to covers every workflow I depend on, from load testing to chaos engineering to backup verification.
FAQ
Is it safe to run staged load tests against a production-like environment?
Yes, as long as the environment is isolated from real production traffic and the generation skill has an automatic stop tied to safety thresholds. The staged ramp is what makes this safe. Jumping straight to peak load without steps is the version that causes real damage.
How often should load tests run?
Frequently enough to catch capacity drift before it becomes a surprise, and always before any known traffic event like a launch or a marketing push. A system with a stable, well understood architecture can test less often. A system shipping frequently needs it closer to every release, since any release can quietly move the ceiling.
What if the realistic traffic model misses an edge case, like a sudden viral spike?
The traffic model reflects normal usage patterns, not extreme outliers, so it is worth running a separate test with an exaggerated spike pattern layered on top of the normal shape for systems where virality is a real risk. The two tests answer different questions, and both are useful.
Does this replace a dedicated performance engineering team?
No. It replaces the version of load testing that never happens because it is too expensive to run often. Teams with dedicated performance engineers get a force multiplier, since the routine testing surfaces the interesting problems for the specialists to dig into instead of consuming their time on the mechanical parts of running a test.
The move from guessing at capacity to measuring it on a schedule is one of the highest leverage changes I have made in how I run production systems. The cost was building four skills that now run without me. The payoff was finding my real bottleneck on a quiet Tuesday instead of during a launch, and knowing, the next time traffic climbed, exactly how far it could climb before anything gave way.
Top comments (0)