> For the complete documentation index, see [llms.txt](https://docs.bountysecurity.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bountysecurity.ai/burp-bounty-pro/scan-control.md). # Scan control and performance Set sensible budgets, follow progress and understand scan states. ## Performance settings | Workflow | Controls in the launch dialog | Initial values | | -------------- | ------------------------------------------------------------------------- | --------------------------------- | | Local Active | Concurrency, Requests per second | 5, 10 | | Local Passive | Threads, Passive Concurrency | 10, 10 | | Local Smart | Threads, Passive Concurrency, Active Concurrency, Requests per second | 10 each | | Local AI | Threads, AI Analysis Concurrency, Active Concurrency, Requests per second | 10, 5, 10, 10 | | Server Scanner | Concurrency, Requests per second, per-server/overall scope | 5, 10; per-server scope initially | For local Active, concurrency is **1–1000** and RPS is **0–1,000,000**; zero means unlimited. Worker counts are derived automatically. The removal of the separate Threads control applies to this Active dialog, not to every live/passive/AI setting. {% hint style="info" %} **A limit, not a speed guarantee** An RPS setting is a ceiling, not a throughput promise. With concurrency 5 and one-second responses, throughput cannot reach 100 RPS. Increasing concurrency consumes more sockets, memory and target capacity. Start with a small profile set and increase only after measuring responses and errors. {% endhint %} Server's MCP accepts zero as unlimited RPS. The current REST configuration parser only applies positive `requestPerSecond` overrides, so use a positive explicit RPS from the extension/REST when a predictable limit matters. See [API configuration](/burp-bounty-server/rest-api.md). ## States | Display | Meaning | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Waiting / Queued | Work has not started executing yet. | | Running | Execution is in progress. | | Paused | New work is held; an already in-flight request may still complete. | | Reconnecting | Pro is recovering contact with the owning server. | | Finished | Execution ended. Local scans also show this in green when some requests completed but connection errors or other interruptions left part of the work unfinished. | | Failed | Local work could not complete any requests before an error/timeout; Server also uses `failed` for its failure paths. | | Cancelled | Work was cancelled. Existing findings are not automatically deleted. | A missing Collaborator prerequisite does not change the displayed terminal state to “Finished (incomplete)”. It still affects coverage and must be considered when interpreting results. **Finished describes the end of execution, not complete coverage.** Partial local runs keep their actual request counts, for example `2407/2466`, and their findings. Check available warnings and failed-request counters when reviewing coverage. Profiles with partial execution remain eligible for another local scan. ## Pause, resume and cancel Use per-entry controls or the intended batch controls. Pause preserves queued work; resume continues it in the same running process. For Server scans, Pro sends control requests to the server that owns each scan ID. A connection error can delay confirmation: verify the resulting state rather than assuming a click reached the server. A cancelled scan cannot be resumed. Removing a row or clearing a display is not a substitute for confirming cancellation. Server restart does not resume active work from history. ## Clear the Active Scanner table Right-click the **Active** scan table and choose **Clear** to remove all current rows, including rows hidden by the search filter. The request/response viewers are cleared too. Scan IDs remain unique, and delayed progress or completion events for cleared rows cannot overwrite new scans. **Clear affects the displayed history. It does not cancel running scans or remove findings from Burp.** To stop work, select the scans and use **Cancel** first. **Remove Selected** requests cancellation for the selected scans and removes their rows. Newly admitted scans can still appear while a batch is being prepared. ## Progress and duration The request total can change as execution becomes known, particularly for conditional steps and extra baseline/control work. Compare **finished**, **successful** and **failed** request counts when available. Terminal remote scans include an end time, including scans learned about after reconnection. Local paused time is excluded from its active timeout accounting. Current local lifecycle classification uses whether any requests completed, not a “95% complete” threshold. ## Reducing laptop load Local scanning prepares payload execution objects as workers become available, instead of allocating one scan task per payload before starting. The initial request budget is still calculated before execution. Progress counters refresh together about four times per second, with a final refresh when a scan ends. Active scans reuse one coordinator pool across manual, Smart Scan and AI-triggered launches. It admits up to eight running scan managers and 128 waiting managers. Each active manager uses at most eight payload workers. Larger selections are admitted progressively on a background thread; they do not run HTTP work on the interface thread. Repeated launches no longer create independent coordinator pools. A full preparation queue produces a visible busy message. These are internal safety ceilings: the requested Concurrency and RPS remain upper limits, but available workers can produce lower throughput. Pausing or cancelling retains the same lifecycle semantics. The implementation also reuses compiled regular expressions in a bounded cache and releases completed passive tasks from the execution registry. Response matching prepares search data once per response and reuses it across alternative conditions. It only searches the request for payload evidence after a condition group matches. These representations stay within the current task; there is no global cache of HTTP bodies. ### Investigating low local throughput After a local scan ends, the extension Output tab includes one `[Local] Scan ... timing:` summary: * **Mean Burp HTTP** is the time spent inside Burp's HTTP callback per call, including failed calls. It includes the client-side network path and work performed inside Burp, so it is different from backend response time measured on the VPS. * **Budget/pause wait** is the accumulated wait for shared concurrency, RPS and pause controls, divided by the number of HTTP calls. * **Other work** is the remaining task time per task: payload preparation, response handling, matching and publication, including any waits in those operations. A task can make several HTTP calls. * **Elapsed, concurrency and RPS** show wall-clock duration, including pauses, and the actual shared HTTP limits applied to this scan. * **HTTP max / HTTP >=250ms** identify slow callback calls. Response status groups, empty returns and callback exceptions distinguish received HTTP errors from missing responses. These are aggregated wall times, not CPU measurements. Concurrent tasks can overlap, so their accumulated times are not the scan's elapsed duration. Cancelled or interrupted scans can have partial measurements. No URLs, payloads or credentials are included in the timing summary. Compare the summary with the target-side meter. A high Burp HTTP time suggests investigating the network path or Burp's request processing; a high Other work time suggests examining profile preparation and analysis. A 10 RPS cap does not guarantee 10 arrivals per second when only one HTTP request may be in flight. An HTTP reverse proxy can reject malformed probe requests before its request counter runs. It can also normalize headers or response framing. The supplied scan meter therefore reports TCP connections and connections closed without reaching its HTTP handler separately. Those are connection counts, not additional HTTP request counts; do not add them to the HTTP total. A redirect to another port or host also leaves the meter's observation point. #### Measuring HTTP/2 traffic The scan meter accepts HTTP/2 and HTTP/1.1 over HTTPS when started with `--tls-cert` and `--tls-key`. For example, listen on port 8443 and scan `https://burpbountylab.com:8443/sqli/status?id=1`. Use a certificate for the scanned hostname. The backend can remain HTTP on port 80. For cleartext HTTP/2 on the existing HTTP port, add `--h2c`. This requires a client explicitly sending HTTP/2 with prior knowledge; it does not upgrade an ordinary HTTP/1.1 request. The `Upgrade: h2c` handshake is not supported. Use HTTPS for automatic protocol negotiation from Burp and check **Settings > Network > HTTP > Default to HTTP/2 if the server supports it**. The `h1` and `h2` output fields report incoming requests per second for each protocol. Verify that `h2` increases before treating a run as an HTTP/2 test. Concurrency counts active requests, so six simultaneous HTTP/2 streams on one connection count as concurrency six and one TCP connection. Upstream protocol selection is independent: an HTTP/2 arrival does not prove HTTP/2 was used between the meter and the backend. The HTTP/1 `Connection: close` workaround below does not apply to ordinary HTTP/2 requests. #### HTTP/1 connection handling If the target responds quickly but Burp takes about one extra second for some responses, compare the same request with `Connection: keep-alive` and `Connection: close`. Use concurrency 1 and the same RPS ceiling for both comparisons. Browser requests commonly contain `Connection: keep-alive`. In a lab reproduction, a 404 response took about 1.1 seconds through Burp with `keep-alive`, and about 0.1 seconds with `close`. The difference occurred both through the meter and directly against the application. Burp's project HTTP/1 connection reuse setting was disabled. A series of these 404 requests reached about 0.91 RPS with `keep-alive` and 9.67 RPS with `close` under a 10 RPS ceiling. These are diagnostic measurements, not a guarantee for other targets or complete profile scans. For ordinary payload throughput checks, set `Connection: close` in the starting request and repeat the same profile selection. This explicitly asks the server to end the connection after its response. Keep the original connection behavior when testing connection reuse, authentication tied to a connection, upgrade behavior or HTTP framing. Profiles that modify the connection headers can also change this behavior during execution. Review **Settings > Network > HTTP > HTTP/1 > Use keep-alive for HTTP/1 if the server supports it** when investigating persistent connections. Its effect should be measured in the installed Burp version. The extension does not automatically change this project-wide setting or overwrite every payload's connection headers. See [Burp HTTP settings](https://portswigger.net/burp/documentation/desktop/settings/network/http). {% hint style="warning" %} **Shared Burp resources** These protections reduce queue growth and thread accumulation. They are not a separate RAM or CPU quota for the extension. Burp, other extensions, retained findings, large HTTP messages and expensive custom regexes still share the same JVM. There is no automatic low-memory pause in this version. For large workloads, use Server to move HTTP execution out of Burp's process. {% endhint %} Use remote servers for active HTTP execution, lower local concurrency, select narrower tags and avoid retaining every verbose request unnecessarily. Poll compact MCP progress and request finding evidence selectively. More servers increase aggregate capacity; select **Overall** limits when you need a fixed combined budget.