RESOURCES
Verified target
A verified target is a host, IP, or hostname you own or have written permission to test, confirmed through the platform’s verification flow before meaningful load.
Definition
A verified target is an asset that has passed ownership or authorization checks — DNS proof, control-panel confirmation, signed permission, or an equivalent flow — so the platform allows traffic generation against it. Slammed.st requires verified targets; anonymous “any IP” testing is not supported.
Verification is the product boundary between an authorized capacity panel and a booter. It sits beside the published Acceptable Use Policy and identifiable accounts.
Related: abort criteria, authorized vs booter.
Why it matters for authorized load testing
Without verification, “load testing” language becomes a cover for third-party disruption. Engineering teams need a clear yes/no: are we allowed to test this exact host in this window? Keep ownership proof with the change ticket; “we thought it was ours” is not authorization.
Verification also protects shared infrastructure partners — notify NOC when intensity warrants it, and stay inside the written scope.
How Slammed.st uses it
Before serious Hub runs, you verify targets in-product. Plans, free trial, L4/L7 methods, and multi-region capacity all operate inside that constraint. Instant stop and plan caps further bound the blast radius.
Create an account only if you will test verified assets · Pricing · Legal guide.
Glossary cluster
Browse related term pages and the hub glossary:
- RPS
- Concurrent connections
- Latency
- Soak test
- Abort criteria
- Throughput
- Layer 4
- Layer 7
- Verified target (this page)
- Spike test
- Load testing glossary (hub)
Why verification exists
A verified target is how Slammed.st keeps capacity testing inside authorization boundaries. Without proof that you own or may test the host, a generator network becomes indistinguishable from abuse tooling. Verification is not bureaucracy for its own sake — it is the control that lets SRE teams rehearse safely while refusing anonymous “any IP” workflows.
See also Acceptable Use on the legal center and the hub at authorized load testing. Index: glossary.
Practical verification sequence
- Confirm internal ownership or collect written permission covering scope and window.
- Complete the in-product verification steps for the exact hostname or IP.
- Smoke a tiny run to prove metrics and stop controls before any campaign intensity.
- Keep proof next to the change ticket and the Hub report.
Start on a free trial. Plan limits: pricing. Product flows: docs.
When a target should not be verified or tested
Do not attempt to verify third-party properties, customer tenants without permission, or infrastructure outside the written scope. If ownership is unclear, stop and escalate to legal/SRE — do not “try a small flood to see.” Pre-flight reachability checks on assets you already control can use useful network tools, then return to Hub only for authorized runs.
Related terms: abort criteria. Narrative context on the blog.
Related
Resources hub · Glossary · Tools matrix · RPS calculator · Useful network tools · Blog · Pricing · Start free