1. What this policy covers
This policy applies to every run started from an account, whether it targets a production endpoint, a staging cluster, a home lab or a client environment covered by a signed scope. It applies to runs started by a colleague you invited, to runs scheduled by an API key you issued, and to runs you did not personally configure but paid for. The account holder is accountable for the traffic the account produces.
It also covers the behaviour around a run: how you describe the test, what you do with the report, and whether you told the people who operate the target. A technically authorised run that nobody at the target expects is still a bad run, and repeated incidents of that kind are grounds for suspension even where the DNS record exists.
The policy is short because the rule is short. Where a case is not covered here, the deciding question is the same one the verifier asks: can the person who started this run prove, on the record, that they are entitled to send traffic at that host?
2. What is permitted
You may test endpoints on a domain you control, including subdomains you can authorise individually. You may test a client environment where the client has signed a scope that names the target, the methods, the rate and the window, and where the client added the TXT record themselves or instructed you in writing to add it. You may test a home lab, a Raspberry Pi on your desk or a cloud account registered in your name.
You may run a failover drill during a maintenance window, a pre-launch rehearsal against staging, and a regression test after a deployment. You may include the resulting report in a client deliverable, a postmortem or a compliance folder. You may compare the numbers with a previous run and publish the comparison, provided the target's operator agrees.
You may stop a run at any moment. You may also ask us to stop it, and we will, without needing a reason. A stopped run is cheaper than a target that goes down while you are deciding whether to stop it.
3. What is prohibited
Do not test a target you do not control. That includes a competitor's site, a public service you use as a customer, a friend's server "just to see", a domain that expired and was re-registered by someone else, and a client's site where the "permission" was a verbal yes from someone who does not own the infrastructure. Enthusiasm is not authorisation.
Do not use runs to extort, coerce or advertise. Do not run a small test and then email the target offering protection from a larger one, and do not use the platform's name to imply that a target is under attack. Do not spoof source addresses, use reflection or amplification, or configure a method in a way that hides the origin of the traffic. The method catalogue exists precisely so that traffic is attributable.
Do not use a run as cover for something else: scanning for open ports, fuzzing for injection flaws, credential stuffing, or knocking a service offline so that a failover writes data in a state you prefer. Do not resell runs to third parties without written agreement, and do not share an account with someone whose targets you cannot vouch for.
Do not attempt to defeat verification: no borrowed tokens, no DNS games, no asking a target's administrator to add a record without explaining what it does, no exploiting a shared resolver or a wildcard. We log the resolver answers for every check, and a suspiciously convenient pass is reviewed.
4. Enforcement
A run that fails verification is refused automatically, before any traffic is generated. If a pattern suggests an account is trying to test targets it does not own: repeated verification attempts on unrelated domains, a rapid rotation of targets, a note field full of guesses, the account is reviewed by a person, and runs may be held while that happens.
Where a run is confirmed as unauthorised, we stop it, suspend the account and preserve the evidence: configuration, verification attempts, resolver answers, timestamps and billing records. We may report the conduct to the target's operator, to the hosting provider or to law enforcement where the conduct appears criminal. We will not warn an account that we are about to do this if warning would allow the traffic to continue.
Suspension for an acceptable-use reason is immediate and does not carry a refund for consumed minutes. Accounts suspended in error are reinstated within one business day, with an apology and a run credit. We would rather reverse a suspension than tolerate a flood aimed at somebody who did not ask for it.
5. Reporting abuse
If you believe traffic from this platform reached a host you did not authorise, write to [email protected] with the timestamps, the target hostname and any log lines you can share. We will identify the run, confirm whether verification existed, stop the account and reply with what we found. We do not require a lawyer to open a ticket.
If you are a hosting provider or a network operator and you are seeing a pattern you believe originates here, include the source addresses and a sample window. Our generators are documented per method, and a match is quick to confirm. If the traffic is not ours, we will say so plainly rather than leave the ambiguity open.
Abuse reports are answered within one business day, and a run still in progress is stopped immediately when a report is credible. We keep the report, the action and the outcome in a log that survives account deletion, because the point of the log is to answer this question six months later.
6. Changes to this policy
We update this policy when a new method or a new edge case makes the old wording misleading. Material changes are announced by email to account holders at least fourteen days before they take effect. A change that widens what is permitted is usually a clarification; a change that narrows it is usually a response to something we saw.
If a change makes the platform unusable for your case, cancel before it takes effect. We will refund unused, prepaid run minutes pro rata. That is the same rule as the terms of service, and it exists because a policy change should not trap a customer who bought under the old wording.
Questions about whether a specific test is permitted go to [email protected] before the run, not after. A short email describing the target, the scope and the window takes ten minutes and has saved several accounts from a suspension they did not intend.