Lower the thread count, set a request rate limit, and cap total and per-rule run time. Each one trades speed for safety. Watch the target's error rate during the first run, then adjust, and never let throttling silently end a scan early.
Why throttle
A scanner sends many requests quickly, and a small staging server can fall over. Slow responses then look like findings, or hide them, and the owners of the environment stop trusting the scans. A gentle scan that finishes beats an aggressive one that crashes the target.
The levers
The ZAP active scan options documentation lists several controls that are typical of most tools.
| Lever | What it does | Trade-off |
|---|---|---|
| Threads per host | Increasing threads speeds the scan, but may put extra strain on the machine running the scanner and the target host | Fewer threads is slower |
| Rate limit | Enforces how fast requests are sent. The docs mark the older delay option as deprecated and point to a network rate limit option instead, which enforces the request rate | Lower rate is slower |
| Max rule duration | The longest any single rule can run, with zero meaning no limit | A cut-off rule may miss findings |
| Max scan duration | The longest the whole scan can run, to help it finish around a set time | Unfinished areas stay untested |
| Max alerts per rule | Rules that reach the value are skipped | A noisy rule stops early |
Steps
- Start low. Use a modest thread count and a firm request rate for the first run.
- Watch the target. Check CPU, response time and error rate while the scan runs.
- Raise one lever at a time. Increase threads or rate in small steps.
- Set a hard time cap that matches your window, and log when it fires.
- Check coverage afterward. Compare the list of tested URLs with what you expected. An unfinished scan should be flagged, not accepted.
- Schedule heavy scans for quiet hours. Agree the window with the owners.
- Alert the on-call team before you start, so a slow service is not mistaken for an outage.
What to watch out for
- Time caps hide gaps. A scan that stops at the limit may report "no findings" for areas it never reached. Record the percentage of the tree tested.
- Per-rule caps hide noise and signal alike. A rule stopped for raising too many alerts may have been correct.
- Rate limits and thread counts interact. Fewer threads with a high rate may still overload a slow endpoint.
- Single-use tokens may need a single thread, as ZAP's option notes warn.
Mirror production settings carefully
Staging often has fewer servers than production. A rate that is safe on production may break staging. Size the scan to the weaker environment.
What to record
Write down the thread count, rate limit, time caps and the date of each run. If a later scan finds something the earlier one missed, the settings usually explain why.
A worked example
A team scans a staging site hosted on a small virtual machine. Their first run uses ten threads. After fifteen minutes response times climb from 200 milliseconds to 6 seconds, then the app starts returning 503 errors. The scan log is full of timeouts, and the report is both noisy and incomplete.
They adjust in stages.
| Run | Threads | Rate limit | Result |
|---|---|---|---|
| 1 | 10 | None | Target overloaded, scan abandoned |
| 2 | 3 | None | Target stable, scan takes 4 hours |
| 3 | 5 | 20 requests per second | Occasional slow responses, scan takes 3 hours |
| 4 | 4 | 15 requests per second | Stable, scan takes 3.5 hours |
The values are illustrative. What matters is the method: lower until stable, then step up gradually while watching the target's health, and stop at the last stable setting.
What to monitor during a scan
- Response time of a simple health check page, polled every minute.
- Error rate on the target, such as 500 and 503 responses.
- CPU and memory on the target and on the scanner machine.
- Queue depth for background jobs, since scans may create work.
- Database connection count.
Set a stop rule in advance. If the health check exceeds a limit for a few minutes, pause the scan. Write that rule in the run plan so nobody has to decide under pressure.
Throttling and coverage
Throttling alone does not cause missed bugs. The risk is the time cap that comes with it. If a lower rate makes the scan take longer than your window, the cap ends the scan before it finishes. Handle this by splitting scans: run the sections in separate jobs, each with its own cap, so that a full pass completes across the week.
| Approach | Benefit | Cost |
|---|---|---|
| One long scan | Simple | May hit the cap |
| Split by area, such as login, search, checkout | Each part finishes | More jobs to manage |
| Alternate quick and deep runs | Fast feedback, full depth weekly | Two policies to maintain |
Remember the scanner's own limits
The machine running the scanner can become the bottleneck too. A scanner on a small container may run out of memory on a large site, producing odd results. Check its resource use alongside the target's.
Tell the right people
Load from a scan can look like an attack to monitoring teams. Tell them the source address and time window, and agree how to pause the scan quickly. A two-line message beforehand prevents a night-time page.
Where Safeguard fits
Throttling concerns how a web scanner treats your running service. For the open source inside your code, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how recurring checks are scheduled and how results are tracked over time.
Quick check
Is a scan that hit its time cap a clean scan?
No. It is incomplete. Record how much was tested and run the rest later.
Why did slowing my scan change the findings?
Time caps and per-rule limits can stop checks early, and slow responses can change results.
How do I know if my scan was throttled too hard?
Compare tested URLs and finished rules with an earlier full run. A big drop in coverage, or a log note that a time cap fired, means the scan was cut short.
Sources
Last reviewed: 19 October 2026.
