Results and retention

Keep the findings you need and understand how long evidence remains available.

What is stored

Retained history contains a scan summary (identity, timestamps, status, targets, settings, counters and warnings), finding summaries, and compressed evidence for retained findings. Evidence can include the relevant HTTP requests/responses, payload and match details.

It is not a permanent copy of every unsuccessful probe, the full source profile pack, or a queue that can resume scanning after restart. Temporary scan files/logs are separate storage.

Defaults and opt-in

Client/workflow	Default
MCP create_scan	Retain when history is enabled. Set retain_results: false for temporary results.
REST POST /scans	Temporary. Send multipart retain_results=true to retain.
Current Pro Server Scanner	REST temporary results; findings retrieved into Burp can be saved in the Burp project.

With history disabled, explicitly requesting retention fails. Omitted MCP retention follows the disabled state.

Default retention

Temporary results remain available for 10 minutes after a terminal state. Retained evidence defaults to 7 days, retained summaries to 30 days, with a 2 GiB total history quota and 32 MiB uncompressed per-issue limit. Change them with the history flags.

Default locations depend on the service account:

Platform	Typical location
macOS	~/Library/Application Support/burpbounty-server/history
Linux	$XDG_CONFIG_HOME/burpbounty-server/history, or ~/.config/burpbounty-server/history
Windows	User configuration directory under %AppData%, then burpbounty-server/history

Retrieve after reconnect or restart

1. Call list_scans on the owning server; follow pagination.

2. Call get_scan_status with include_configuration: true when you need the saved selection/settings.

3. Retrieve summaries with get_scan_issues.

4. Fetch selected evidence with get_scan_issue while it remains available.

After a restart

A retained run interrupted by restart is marked failed with a restart warning. Already saved findings remain available. Restarting does not resume execution, and a historical scan cannot be resumed with resume_scan.

After evidence expires, summaries can remain discoverable until their separate expiry. Inspect evidence_expired, retention metadata, read errors and truncated_fields. MCP output truncation is distinct from on-disk issue size limits. REST retrieval of expired full evidence can return 410 Gone.

Storage pressure and deletion

The quota includes temporary files used for atomic updates. Unexpired findings are not silently evicted to make room. A storage/issue-size failure is reported and can leave only partial retained results; inspect the scan warnings and server_info.history usage.

Delete a completed scan deliberately with MCP delete_scan_history or REST DELETE /history/:id. This deletes Server history, not issues already imported into a Burp project. Do not use deletion as an automatic response to a full disk without deciding which results may be removed.

Use a distinct directory per running server. Keep it outside the temporary scan directory and mount it persistently when using a container. Back up history while the server is stopped for a consistent filesystem copy. Finding evidence can contain session data, so use the same access controls as for the assessment project.