[chatmasta]

One problem with products like this is that the same marketing materials are used by DDoS vendors. In their case of course "load testing" is coded language for "DDoSing a target." But nonetheless, you run the risk of people abusing your service to "load test" services they don't control, which could lead to high bills on your side that might never even get paid (people who DDoS others tend to have a lot of overlap with people who pay with stolen credit cards).

Do you have a plan to avoid this? I think it can be solved with simple domain verification. Generate a unique key for the customer and ask them to insert it into a DNS TXT record to prove they control the domain you're about to spam with requests on the behalf.

However, given the flexibility of your platform, that might not be sufficient. If a user can write arbitrary scripts, then can they change the target mid-test? You might also need some kind of firewalling solution in place.

[yevyevyev]

This is a topic we think about a lot. The downside to requiring domain verification is additional friction, and if an external API call is required (e.g., logging in via Auth0), those tests may not be possible.

Accounts on the free tier won't be able to create much of an attack. We perform customer verification on accounts with higher concurrent virtual user limits.

We closely monitor potential abuse and will adjust our verification strategy as needed. Thanks for the question.