Skip to main content
Limits protect diagnostic capacity while allowing multiple users behind a shared public IP. Both request volume and concurrency matter: you can receive HTTP 429 before reaching a per-minute limit.

​
Current diagnostic limits

Limits below reflect the release deployed on 28 October 2026. These are admission ceilings, not reserved capacity or guaranteed throughput. Other users can occupy shared slots. The service’s client-tracking capacity and edge protections can also reject requests. /api/v1/location, /api/v1/locations and /api/v1/client do not consume these application diagnostic budgets. They remain subject to normal edge protections and service capacity.

​
What counts as one client?

  • A public IPv4 address shares one allowance. Colleagues using the same office NAT, or customers using the same integration backend, share that address’s budget.
  • IPv6 addresses within the same /64 prefix share one allowance.
  • Regional budgets are separate on each node. Within a node, GET and POST use the same relevant allowance.
  • All hub test types and locations share the hub allowance.
  • Hub requests retain the caller’s identity at the regional node. A direct TCP request and a hub TCP request to the same node count against the same detailed/TCP budget.
Limits count admitted requests, not individual ICMP packets or MTR cycles. A failed target lookup or failed measurement can still consume a request allowance once admitted. Minute windows begin with the client’s admitted traffic; do not assume they reset at a wall-clock minute boundary. The quick-ping budget is separate from the detailed/TCP budget, but both share the node’s 16 active slots.

​
Handling HTTP 429

Application rate or concurrency rejection returns:
  1. Pause requests for the affected budget and wait at least the number of seconds in Retry-After.
  2. Add a small random delay so several workers do not all retry together.
  3. Reduce concurrency and use a queue. Share the pause across workers using the same egress IP.
  4. If a retry is still rejected, back off again with a bounded retry count.
Retry-After: 30 is a retry hint, not an exact quota-reset timestamp or a guarantee that a slot will be available after 30 seconds. Do not retry in a tight loop. If an intermediary does not supply a retry header, use a bounded backoff instead of an immediate retry. As a conservative starting point, use at most four concurrent requests to a single regional node and eight to the hub, then adjust within the documented ceilings. These are integration recommendations, not additional enforced quotas.

​
HTTP errors

Application errors normally use {"error":"code"}. An edge or proxy can return HTML or another format, so inspect HTTP status and Content-Type before parsing JSON.

​
HTTP success is not a health verdict

HTTP 200 means you received a result, not necessarily that the destination replied or its TCP port opened. Inspect status, summary.received and the relevant result fields. Detailed probes may return execution statuses such as timeout or unavailable inside a 200 response. See result interpretation.
Last modified on October 28, 2026