Features for authorized capacity tests

What you get

Layer 4 & Layer 7

Network and application methods for verified targets — pick the layer that matches the risk.

Multi-region capacity

Distribute authorized load across 40 regions for edge, anycast, and geographic latency checks.

Verified targets

Ownership checks, abort controls, and plan caps keep rehearsal inside a defined blast radius.

Developer API

Start and stop the same authorized scenario from CI after a human-validated smoke path.

Pentest Panel

Authorized website assessment with a structured findings report — included on Scale and higher, alongside Hub capacity tests.

Feature overview — who it is for

Slammed.st is an authorized IP stresser and load-testing platform for SRE, platform, and product teams who must answer one question before launch or peak season: how much traffic can this system sustain within latency and error budgets?

The Hub combines method selection, region choice, plan-based concurrents and duration, live metrics, abort controls, and exportable findings. It is not a booter panel and not a replacement for every scripted protocol — it is a hosted capacity rehearsal layer with verification and acceptable-use enforcement.

Typical buyers include teams shipping APIs, ecommerce peaks, game backends they operate, and CDN/WAF stacks that need an edge-versus-origin reality check. If you need vocabulary first, skim the load testing glossary. If you need policy context, start at authorized load testing.

Layer 4 and Layer 7 methods

Layer 4 features exercise the network and transport path: connection pressure, packet and bandwidth hypotheses, firewalls, load balancers, and scrubbing behavior on targets you operate. Use L4 when the risk is the pipe, connection tables, or mitigation onboarding — not when you only care about checkout JSON.

Layer 7 features send application-level HTTP(S) traffic against verified hosts and APIs. Configure scenarios that match real journeys (browse vs write paths), watch RPS alongside p95/p99 and error rate, and separate cacheable GETs from conversion endpoints so a pretty homepage does not hide a fragile API.

Method profiles should stay tied to a written hypothesis: which layer, which path, which abort rule, which cool-down. Pick the layer that matches the risk, then ramp in steps. Pair Hub charts with your own host, CDN, and APM counters. Guides: Layer 4 stress testing, Layer 7 stress testing, and when to use each.

Multi-region capacity

Capacity is only as believable as the sources that generate it. Slammed.st distributes authorized load across 40 regions, with peak platform capacity up to 4.3 Tb/s and scale that supports on the order of 1.2 billion requests in high-volume windows — subject to your plan limits and the target’s authorization window.

Multi-region runs matter for anycast DNS, edge POP behavior, and geographic latency that a single lab generator will never reveal. Still treat region choice as part of the hypothesis: start narrow for smoke tests, then widen when you need a realistic peak shape.

Your practical ceiling is always the intersection of plan concurrents, max duration, verified-target policy, and the physical capacity of the system under test — not a marketing number alone. Compare plan envelopes on pricing before booking a major window.

Live metrics during runs

While a test is active, the Hub surfaces throughput, latency trends, success rate, and error signals so operators can decide whether to continue, hold, or abort. Live visibility is what turns a “stress panel” into an engineering instrument: you react to cliffs instead of discovering them only in a postmortem CSV.

Best practice is to watch Hub metrics next to origin CPU, NIC drops, database pool saturation, and CDN challenge rates. When signals diverge — for example Hub RPS flat while origin CPU is fine — you often have an edge, WAF, or connection-limit story rather than an app-code story.

Define abort criteria before the ramp so “stop” is a rule, not a debate. Keep an operator on the console for high-stakes windows. See abort criteria and the how it works overview.

Reports and capacity cliffs

After stop, reports help you mark the stable plateau and the first capacity cliff: the step where p95/p99 breached SLO, errors spiked, or the pipe saturated. That cliff is the artifact product and capacity planning need — not a vanity peak that only lasted thirty seconds.

Use cool-down periods to see whether queues drain cleanly. Export findings into release checklists, on-call notes, and the next change window. A good report answers: what stayed stable, what failed first, and what to fix before the next authorized run — then schedule the follow-up test after the fix lands.

Target verification and safety controls

Verified targets are a core feature, not a disclaimer. You prove ownership or written permission before meaningful load. Instant stop controls, plan caps on concurrents and duration, and published Acceptable Use keep rehearsal inside a defined blast radius.

Teams should still run their own change management: notify NOC, agree abort thresholds, and keep ownership proof with the ticket. Read Legal & Acceptable Use and Is using an IP stresser legal? before production windows.

Plans, concurrents, and duration

Plans translate into how hard and how long you may push in one scenario: concurrent workers, max runtime, and access to higher-capacity methods or API automation. Free Trial exists to verify the workflow without a card; paid tiers unlock longer windows and higher concurrents for serious peaks.

Concurrents are a generator limit, not a guaranteed target RPS. Match plan size to the hypothesis, then size up when the cliff is above your current ceiling. Full matrix: pricing.

Developer API and automation

Paid plans unlock API access so the same authorized scenario can start and stop from CI, release bots, or internal runbooks. Tokens live in the client area; rotate them, never commit them, and never point automation at hosts you are not authorized to test.

Automation works best after a human-validated smoke path: verified target, known abort rules, and a documented method profile. Overview: developer docs and IP stresser for developers 2026.

Comparison vs scripts and vs typical stressers

vs k6 / JMeter / Gatling / Loader.io-style scripts: script runners excel at custom protocols, precise assertions, and CI unit-style checks you fully own. A hosted L4/L7 panel helps when you need multi-region pressure, shared team runs, and plan-based capacity without standing up a generator fleet. Many teams use both: scripts for deep protocol logic, Slammed.st for high-volume authorized rehearse.

vs typical stressers / booters: anonymous “any IP” panels optimize for disruption and deniability. Slammed.st optimizes for verified targets, accounts, legal center, and engineering outcomes. Side-by-sides: vs load-testing tools, vs typical stressers, and authorized IP stresser vs booter.

Next steps

Ready to rehearse capacity on infrastructure you control?

• Start free trial — verify a target and run a smoke scenario
• Compare plans — concurrents, duration, API
• Authorized load testing hub — policy and workflow

Also browse use cases, resources, and the glossary so the whole team shares the same definitions before peak.

Related

Resources hub · Glossary · Tools matrix · RPS calculator · Useful network tools · Blog · Pricing · Start free