How Auto-rate works

What Auto is

When you pick the Auto tier on the new-scan screen, Violet sends a short burst of probe requests to your target before recon starts, classifies the response patterns, and picks a crawler rate that fits the kind of infrastructure you are running on. The probe takes one to two seconds and adds nothing to the recon workload that follows.

The goal is simple: scan as fast as your target can comfortably handle, and no faster. Going faster than that trips your WAF, gets the worker IP rate-limited, and can stall the scan partway through with a wrongly-classified outage error. Going slower than that wastes scan time you paid for. Auto picks the right speed without you needing to read CDN documentation or remember whose origin server you are running on.

The four tiers

Every Auto-classified target lands in one of four tiers. The numbers are conservative — they are designed to keep the scan moving without surprising the target's WAF.

The tier determines the rpm cap applied throughout the scan.

What signals drive the choice

The probe runs four checks in sequence. Each one can confirm or downgrade the running classification.

1. Server header. A single GET on the root path. Violet reads the Server: response header and looks up a known fingerprint — cloudflare, akamai, fastly push toward cdn-fronted; litespeed pushes toward shared-hosting; nginx and apache are intentionally inconclusive because they fly on top of CDNs and shared hosting alike.
2. CDN signature scan. Headers like cf-ray and x-served-by are unambiguous CDN fingerprints. If either is present, the class jumps to cdn-fronted regardless of what the server header said.
3. Latency baseline. Five GETs spaced 200 ms apart. If the p95 response time is above two seconds, the class downgrades by one tier — slow under a single-user load is a hint that bulk recon traffic will tip it over.
4. Burst sensitivity. Ten GETs in roughly one second. If three or more come back as 429, 503, or a TCP reset, the class downgrades by one tier. Burst sensitivity is the most direct evidence of an active rate-limiter or WAF, so it wins when both latency and burst trigger.

The WAF allow-list header

Every probe request — and every recon request that follows — carries this header:

X-Violet-Agent-Pentest: true

If your WAF has a configurable allow-list, add a rule that exempts requests with this header from rate-limiting and challenge-mode triggers. The header is constant — it never carries a per-scan token — so a single rule covers every Violet scan against your target, forever. We deliberately keep it static so your security team can review and approve it once.

When to override

Auto is a default, not a ceiling. If you know your infrastructure is more permissive than the probe will conclude — or stricter — you can set the rate explicitly in your scan config YAML and Violet will use that exact value:

pipeline:
  rate_limit_rpm: 1200

An explicit rate_limit_rpm always overrides the probe's pick. The configured value is used for the entire scan in place of what Auto would have selected.

Common reasons to override:

• Internal staging environment with no WAF and a generously-provisioned origin — bump the rate up.
• Production on a fragile shared origin behind a CDN — the probe sees the CDN and picks cdn-fronted rates, but you know the origin breaks first. Drop the rate down to the shared-hosting tier or lower.
• Compliance constraint requiring a documented, approved scan rate. Set it explicitly so the report carries the number you committed to.