Log Panel

The Log tab shows extension log lines for the current session — status and errors during a run.

The Burp Extensions → Output console stays quiet for routine export work; detailed lines go here (and optionally to the database Exporter index when that source is enabled).

Log panel UI

Scrollable log with level filter (includes TRACE), search, and toolbar controls for Copy, Pause autoscroll, and Clear. The context menu can copy the selection, current line, or all retained entries. There is no log-save command; use Copy all when you need to preserve the panel contents. Pause autoscroll and incremental rendering keep the tab responsive under load.

The visible model retains at most 5,000 entries. Delivery is time-sliced onto Swing's event thread so sustained logging does not monopolize the UI. Clear fences already queued UI delivery so pre-clear lines cannot reappear; it does not erase independently exported log events from the Exporter index. The Log panel and Exporter index are separate destinations with separate purposes.

Where logs go

Destination	What goes there
Burp console	Extension initialization/unload messages and initialization failures only
Log panel (this tab)	Extension package log lines (DEBUG+ by default)
Exporter index (database)	Config snapshot on Start, log events, and stats snapshots when Exporter is selected, export is running, and a database destination is active

What to expect

• No routine per-request or skip-reason logging (efficiency). Live Proxy correlation emits one DEBUG first-marker diagnostic per run and rate-limited failure summaries.
• Indexing failures at ERROR.
• Search-destination HTTP diagnostics appear at DEBUG for connection tests, index setup, and transport troubleshooting. Authorization and other known credential material is redacted. Response bodies are diagnostic previews (up to 4 KiB), and the complete assembled response diagnostic is capped at 8 KiB; complete arbitrary response bodies and Java stack traces are not emitted by these paths.
• During large snapshots, EdtMonitor may log EDT stack traces here if the tick budget is missed (panel-only; not indexed to OpenSearch).
• After [Export] Stopped. or force-stop, run-scoped Log-panel output stays silent until the next Start; late transport completions cannot resume the finished run's accounting.
• Stop and a later Start preserve the visible session log. Use Clear when you intentionally want an empty panel. Extension unload/reload or Burp restart creates a fresh extension session and does not restore the previous panel contents.

Run health

Log and Stats Panel together show whether a run is caught up:

Signal	Where	Meaning
Backlog complete	[StartupExport] / [SnapshotExport] completion lines	Capture/enqueue finished for that source — not proof every document reached the database
Push failures	Stats Failures vs Recovered Failures	Failures counts failed database pushes and does not decrease on later success; Recovered Failures tracks retry-drain successes
Retry activity	Log filter TRACE	DEBUG per retry drain push; INFO when a retry fails or recovers

Remote / non-local Database destinations: WARN and ERROR provide the clearest view of capacity pressure, soft outage, and shared cooldown. Runtime interpretation: Config - Monitoring remote database exports. Line catalog: Amazon OpenSearch signals.

Files integrity and Stop lines

A Files run logs whether each selected output was created or opened for append, including its baseline size. The normalized export directory is locked for the run so another exporter process cannot write there concurrently. Transient append failures can be retried only after a partial append is rolled back; File Counts / Copy expose Retry Attempts.

Graceful Stop reports these phases: closing live correlation intake, waiting for admitted responses, draining accepted traffic, clearing remaining queued traffic and run-scoped spill/correlation state, draining retries when applicable, pushing final exporter stats, validating file artifacts, and closing destination connections. Final Files validation checks file identity and expected baseline + appended size. Deletion, replacement, truncation, or unexpected growth logs an error and leaves that artifact Integrity: Failed; healthy artifacts finish Integrity: OK.

Stop logs file_counts and misc_stats session summaries but does not call database _refresh or _count. A second Stop force-aborts remaining retry, final-stats, file-validation, and connection-close waits.

Run checklist (startup and snapshot lines)

On Start, major export paths log completion totals you can use as a run checklist:

When	Log shape (examples)	What it tells you
Traffic startup backlog finishes	[StartupExport] Traffic: startup backlog complete	Aggregate startup traffic docs across Repeater Tabs, Proxy WebSocket history, and Proxy History, with per-source counts and file/OpenSearch failure totals
Adaptive startup slice completes	[StartupExport] <source>: slice lane=... range=... count=... bytes=... elapsedMs=... nextTarget=... reason=...	Findings, Sitemap, Proxy History, and Proxy WebSocket each start at 50 items, target about 15 s per completed slice, and adapt independently within 1-250 items from per-lane prepared-byte and throughput history before yielding to the next lane
Per traffic source completes	[SnapshotExport] Repeater Tabs: / Proxy WebSocket: / Proxy History:	Per-source captured, file-written, and OpenSearch-exported counts
Findings / Sitemap / Proxy WS historic snapshots	[SnapshotExport] Findings: / Sitemap: / Proxy WebSocket: snapshot complete	Snapshot captured vs written vs exported; zero failures on a clean run
Sitemap scope/dedupe	[SnapshotExport] Sitemap: backlog filters:	How many site-map rows were seen, exported, skipped for scope, or skipped as duplicates within the run

Findings startup summaries also reconcile seen vs exported issue counts, including severity-filter skips.

Key takeaways: [SnapshotExport] and [StartupExport] completion lines provide the authoritative per-source totals. A Repeater Tabs capture complete line may temporarily show delivery_pending=true; the aggregate Traffic completion line refreshes its delivery counters and reconciles Repeater Tabs + Proxy WebSocket + Proxy History.

Periodic and live traffic lines

• Findings and Sitemap re-poll Burp's full in-memory lists on a 30 s interval while export runs.
• Quiet cycles log [PeriodicExport] Findings: or [PeriodicExport] Sitemap: with how many in-scope rows were checked and whether anything new was exported.
• When export stops, a sparse [LiveTraffic] Traffic: attribution summary line may list live traffic by Burp tool source, with OpenSearch and file sinks reported separately (for example openSearch={Scanner=256}; file={Scanner=256}).
• Repeater Tabs startup is a one-time snapshot, not live Repeater stream traffic — it does not appear in [LiveTraffic] on Stop (Scanner and other live tools do).

Live Proxy correlation lines

Live Proxy HTTP export uses an asynchronous annotation-token join to the exact Proxy History row. The private token and temporary spool filename are intentionally omitted from logs. Use generation, callback messageId, and counters to correlate events without exposing marker material.

Level / line	Meaning
INFO [ProxyCorrelation] Run opened:	A fresh correlation generation opened after Start bootstrap. Pending state begins at zero; abandoned prior-run artifacts are discarded rather than recovered.
DEBUG First live Proxy HTTP request marked:	First successfully marked request for the generation. This is one diagnostic per run, not per-request logging.
WARN Multiple Proxy History rows matched one marker	Exact uniqueness failed. The exporter does not pick an arbitrary row; after the bounded correlation window it can export the complete downstream exchange with History-only fields unavailable.
WARN Stop timed out waiting for HTTP response callbacks	Stop's bounded response wait expired. The line includes generation, in-flight count, and wait duration; unresolved work is discarded during run cleanup and is not replayed later.
ERROR Live Proxy correlation rejected: reason=...	Active traffic could not be admitted safely (inactive_generation, missing_marker, unexpected_marker, duplicate_marker, or marker_attach_failed). Includes generation, callback messageId, cumulative explicit failures, and suppressed repeats.
ERROR spool lines	Serialization, write, load, initialization, cleanup, or quota handling failed. Repeats are rate-limited; the line reports the failure category and cumulative/suppressed counts without token-bearing paths.
INFO [ProxyCorrelation] Run summary (intake closing):	Final current-run counters: Proxy/HTTP callbacks, marked/responses, unmarked tracked/pre-run responses, History lookups/matches, bound/eligible totals, memory/durable pending, spool totals/failures, and explicit failures.

Normal healthy interpretation:

• HTTP Marked / Responses converges for the controlled Proxy workload.
• Bound / Eligible converges after near-real-time History rows arrive.
• Memory and durable pending return to zero after successful handoff.
• Lookup, cleanup, spool, and explicit failure counters remain zero.

A non-zero Pending Durable count (the Stats UI label for temporary current-run overflow) means correlation moved document state out of heap for this run only. It reaches zero through exact binding, bounded History-unavailable fallback, or Stop cleanup — not recovery after Stop/restart. See Reference — Live Proxy History-field correlation and Stats — Proxy Correlation.

Pressure and overflow lines

• When spill, queue-drop, or retry-capacity pressure occurs, [TrafficExportQueue] and [OpenSearchRetry] emit throttled Overflow summary lines (first event immediately, then cumulative reason keys and queue/spill context about every 30 seconds) instead of one line per document. Under deliberate pressure or outage, expect those summaries — not thousands of per-document warnings.
• When Traffic Spill is Full, Log warns that new live traffic is rejected so the earliest backlog is preserved (not drop-oldest-on-spill-reject).
• A chunk flush exception logs [SnapshotExport] Chunk flush failed for <index> and counts the chunk as failed instead of aborting the whole snapshot run. A flush-slot watchdog warns after ~120 s, but does not abandon a live request: the snapshot waits for the transport timeout/retry outcome so one layer owns indexing and retry accounting. Stop still cancels active run work.
• Historic startup lanes yield only after a completed SnapshotExportEngine slice. The ~15 s target adjusts the next item allowance; it never cancels an in-flight database request to enforce a deadline.

Amazon OpenSearch signals

When the database destination is Amazon OpenSearch, these Log-panel lines are worth knowing during long runs:

Signal	Meaning
Waiting N ms for shared bulk rate-limit cooldown... (INFO, waits ≥ 1 s)	Shared capacity cooldown — intentional pacing, not a hung worker. Escalates 5s → 15s → 30s → 60s under repeated pressure (honors Retry-After up to 60s).
Soft outage: entering from bulk pressure / Soft outage: capacity probe failed	Soft capacity outage started; export stays enabled while pacing and draining retries.
Soft outage cleared: destination reachable	Soft outage ended after successful reachability / meaningful payload or retry-drain progress (not exporter log/stats singles alone).
Authorization recovery paused after repeated 401/403 responses	Database sends and snapshot production pause without stopping the run. Retry documents remain queued while automatic probes use increasing backoff.
Authorization recovery probe starting / Authorization recovery restored	A background authorization check is running, or access has returned. Recovery revalidates selected indexes and may replay reproducible snapshots when the cluster identity changed or indexes were recreated.
Bulk capacity pressure: / Bulk item capacity pressure:	HTTP 429/502/503/504, transport timeout-style failures, or per-item circuit_breaking / throttled on HTTP 200.
Snapshot flush slot wait: ... waitedMs=... (INFO, waits ≥ 1 s)	Snapshot senders blocked because in-flight flush slots are busy — usual cause of a multi-tens-of-seconds throughput chart gap.
Snapshot flush slot watchdog: ... action=await_transport_outcome (WARN, ~120 s)	A live request is unusually slow. The snapshot keeps waiting for the transport-owned timeout/retry result instead of cancelling independently and risking duplicate outcome accounting.
[StartupExport] ... slice lane=... elapsedMs=... nextTarget=... reason=... (DEBUG)	One completed adaptive startup slice. grow, shrink, shrink_fast, hold, hold_no_bytes, and clamp reasons explain the next per-lane item allowance. shrink_fast means a completed, byte-producing slice exceeded the wall-time target by at least 3x, so the next allowance moved directly to the predicted lower target.
Bulk HTTP response received: ... elapsedMs=... (INFO when ≥ 5 s)	Slow Amazon bulk that held a flush slot; correlate with requestId and chart gaps.
Amazon bulk pressure applied: ...	Adaptive byte budget / in-flight flush serialization after rate-limit pressure (Amazon starts near 1 MiB, floor 512 KiB, grows toward 5 MiB).
Amazon capacity symptom (client-observed): ...	Throttled WARN after capacity HTTP status or transport failure (CloudWatch verify hint).
Bulk HTTP transport failure ... timeoutClass=... requestId=... elapsedMs=... (WARN)	Wire failure: connect, connection-request/lease, or response, plus cause chain.
recovery lines with evidence=bulk_item_success	Retry-drain recovery proof for previously failed items.

A long gap on the Stats throughput chart during remote Database export is usually flush-slot waits or a shared cooldown — not a quiet retry poll, and not an automatic export stop. Shared AIMD applies across OpenSearch / Amazon OpenSearch / Elasticsearch. Mild capacity may log scope=index; hard 429/502/503/504 remains scope=cluster. Soft-outage drain keeps a normal cadence while the retry queue is non-empty. Exporter log/stats success alone does not clear Soft Outage / shared AIMD. Stop-path cooldown waits are capped at 2 s; graceful Stop aims for ~20 s wall-clock, with undrained retries reported as Permanent Drops. Classic Amazon bulks are bounded: 15 s connect, 30 s connection-request (pool lease), 2 min response. Misc Stats gauges: Stats - Database Capacity.

Indexing failures (ingestion)

ERROR lines and [PERMANENT] drops mean OpenSearch rejected or dropped documents. Cross-panel validation and OpenSearch queries: Reference — Data Integrity.

• Immense term / ignore_above — immense_term_rejected
• Nested document limit — nested_document_limit_exceeded
• Permanent drops — grep [PERMANENT]; permanent_drops
• Maximum-fit rejection - Permanently rejected search document that cannot fit the absolute bulk ceiling. One ERROR is emitted per affected search document with index/index key, stable operation ID, full request URL (including query string), original bytes, smallest fitted bytes, the 5 MiB absolute ceiling, and reason max_fit_exceeded. The Files copy remains unchanged.
• Bulk response consistency - Bulk response outcome mismatch is a WARN emitted when a successful Bulk API response's top-level errors flag disagrees with its parsed item outcomes. The line includes the local requestId, index, reported flag, parsed failure count, and response item count for correlation with nearby HTTP diagnostics; it does not include the response body or credentials. Item-level outcomes remain the basis for export accounting.

Symptom routing: Reference — Troubleshooting.

DEBUG [ParameterIntegrity] lines usually mean raw evidence was preserved. Hover Stats Parameter Integrity rows. Log lines with Wiki: Reference#…: Parameter integrity messages.

Ingestion error catalog

OpenSearch does not, on its own, generate errors users commonly hit during normal use. Parsing/storage limits (Lucene immense term, nested document limit, Jackson string limit) surface in the Log panel at ingestion time, or in Dashboards/Kibana at view time — search by the message you actually see.

OpenSearch Dashboards / Kibana: Discover can fail on very large nested bodies (especially findings with many evidence pairs). Not an export failure — writes and _doc fetches still work. See Dashboards — Known limits.

Export retries and outage

All index pushes go through IndexingRetryCoordinator.

• Single-doc (traffic, settings, exporter): One attempt; on failure offer to per-index queue. No blocking on HTTP thread.
• Bulk (findings, sitemap): Up to 3 attempts with exponential backoff; then queue failed items only (from BulkResponse).
• Retry fidelity and size classification: The centrally byte-bounded retry queue keeps the original PreparedExportDocument. Each send derives a search-only fitted copy, preserving the original for later recovery attempts and the Files sink. If the live budget shrinks while a bulk waits in the offered-load governor, the sender re-fits and re-splits the derived search copies before HTTP instead of reporting a transport failure. A document that misses only the current adaptive budget remains transient; one that still cannot fit the absolute 5 MiB ceiling is a deterministic max_fit_exceeded Permanent Drop and is not re-queued forever.
• Capacity pressure (soft outage):
  • Triggers — HTTP 429/502/503/504, timeout / failed-to-respond transport failures, and per-item circuit_breaking / throttled results (even on HTTP 200) on prepared and chunked bulk paths. Classified as transient CAPACITY.
  • Shared cooldown — Recorded by the response handler without sleeping on the HTTP connection; the next bulk send waits once. Escalates 5s → 15s → 30s → 60s (honors Retry-After up to 60s).
  • Soft outage behaviour - Database destination stays enabled; export paces and drains retries. Repeated AUTH (401/403) enters Authorization Recovery, retains queued work, and probes automatically instead of auto-disabling or force-stopping the run.
  • Batch / recovery — BatchSizeController shrinks the next batch on failure. Chunked live-traffic bulks that fail after draining the in-memory queue hand failed prepared documents to IndexingRetryCoordinator (same path as snapshot prepared bulks).
  • Shared AIMD (all search destinations) - Every adaptive destination starts near 1 MiB with one snapshot flush in flight. Healthy completed bulks can grow toward 5 MiB and 1 / 2 / 3 in-flight snapshot flushes; hard pressure floors the budget near 512 KiB and serializes flushes. Cooldown waits ≥ 1 s log INFO (Waiting N ms for shared bulk rate-limit cooldown...). Stop-path cooldown waits are capped at 2 s. Capacity-symptom WARNs on Amazon include a CloudWatch verify hint. Line catalog: Amazon OpenSearch signals.
• Bounded queue: Per-index cap (e.g. 10k docs); when full, reject new docs and record drop counters.
• Overflow summaries: Throttled panel lines — Pressure and overflow.
• Drain thread: Daemon every 5s (or 30s in outage); batch size is adaptive (Contributor Guide - Adaptive batch size); on success updates ExportStats.
• Classic outage (unreachable): When health probes see the destination as unreachable (not soft capacity pressure), docs still queue; log once then throttle probes; clear when reachable and the queue drains. Soft outage vs AUTH classification is under Capacity pressure above - AUTH pauses for automatic recovery; capacity gateway timeouts use shared pacing. Start flow: On Start, upstream OpenSearch, Elasticsearch, and Amazon OpenSearch run a preflight connection test, create selected indexes explicitly before any documents are pushed, then use shared bulk HTTP paths for indexing. Existing indexes are accepted when their deployment-relevant shard, replica-allocation, refresh settings, and required mapping fields match the bundled definition; extra dynamic mapping fields are allowed. A confirmed mismatch fails Start without modifying or deleting the index. When a least-privilege principal receives HTTP 401/403 specifically on the optional _settings read, Log warns that compatibility was not verified and Start continues. Amazon OpenSearch IAM requests are SigV4-signed with es for hosted/domain endpoints and aoss for serverless/collection endpoints. This keeps mappings stable before export begins. OpenSearch Dashboards or Kibana Discover may still hit highlighting limits on very large body fields. If index creation or a completed compatibility validation fails, the UI reverts to stopped.

Body-field mapping parse errors: The index may have been created under an older extension version. Recreating the affected index on the next Start applies the current bundled mappings. Body shape (body.b64, optional body.decoded_b64, body.content_encoding.*, and optional body.text): Config Panel - Body Content-Encoding.