Bug Reports

A bug report is the central object in BugPort: a single record that bundles the evidence, technical context, page context, and collaboration around one issue so that anyone on your team can reproduce and fix it without a back-and-forth. Reports arrive from several sources — the browser extension, the npm widget, the API, and MCP — and how a report was captured determines what it contains. This page explains every element a report can hold and how its shape varies by source.

WHAT'S IN A REPORT

Anatomy of a report

Not every report has every field. The elements below are the full set; which ones are present depends on the capture source and on what the reporter triggered.

Source badge

Where the report came from — Plugin (browser extension), Widget, API, or MCP. The badge tells you immediately how much fidelity to expect.

Screenshot

A still image of the page at capture time. Always present from the extension; optional from the widget; usually absent from API/MCP reports.

Annotations

Marks drawn on top of the page or screenshot — boxes and highlights that point at the problem area.

Feedback text

The reporter's written description of what went wrong and what they expected.

Console logs

Captured browser console output (errors, warnings, logs). Captured by the extension; large logs are stored as files in Cloudflare R2.

Network requests

A list of Fetch/XHR/API calls made during capture, with status, timing, and headers (sensitive headers filtered).

Response bodies

The actual response payloads for captured requests, when available. Opaque, cross-origin, and binary responses cannot be captured.

Page path & context

The URL/path where the issue occurred, plus viewport, user agent, and environment metadata.

Replay (optional)

A short session replay of the steps leading to the bug. Captured by the extension only, when enabled in advanced settings.

Status

The triage state of the report — for example open or closed — that drives your workflow.

Severity

How serious the issue is, used to prioritize.

Comments

Discussion threaded on the report.

Activity

A timeline of changes — status updates, comments, exports, and shares.

Share links

Read-only links that expose the report to people outside your workspace.

Where the data lives

Lightweight metadata, small logs, comments, and activity live in Supabase Postgres. Heavy media — screenshots, replay videos, attachments, thumbnails, large logs, and HAR files — is stored in Cloudflare R2 and served through presigned URLs. Binaries never pass through Postgres.

Report anatomy, visualized

How the source shapes the report

A report's source is the single biggest factor in what it contains. The dashboard renders each report adaptively — it shows the panels that have data and cleanly omits the ones that do not, so a report with no screenshot does not render a broken image frame.

Browser extension (Plugin)

Full fidelity. Captures screenshot plus annotations, console logs, network requests including response bodies, page context, and optional session replay. This is the richest report shape.

NPM widget

Reporter-driven and lightweight. Captures feedback text, annotations, and page path; a screenshot is optional. Widget reports with no screenshot render annotations, page path, and feedback cleanly — no broken image panel.

API / MCP

Programmatic. Created by integrations or automation, these may be metadata-only (feedback, page path, severity) or carry media that was uploaded explicitly. Useful for piping external signals into the same triage flow.

What each source typically includes

Element	Extension (Plugin)	Widget	API / MCP
Screenshot	Yes	Optional	Rare (explicit upload)
Annotations	Yes	Yes	No
Feedback text	Yes	Yes	Yes
Console logs	Yes	No	No
Network requests	Yes	No	No
Response bodies	Yes	No	No
Page path & context	Yes	Yes	Often
Session replay	Optional	No	No
Status & severity	Yes	Yes	Yes
Comments & activity	Yes	Yes	Yes
Share links	Yes	Yes	Yes

💡

If you need console, network, and response-body detail, capture with the browser extension. The widget is the right tool when you want every user to be able to report, and you mainly need feedback, annotations, and the page they were on.

Triage: status, severity, comments, and activity

Once a report exists, it becomes a working item. Status moves it through your workflow (open through closed). Severity sets priority. Comments keep the discussion attached to the evidence instead of scattered across chat. The activity timeline records what changed and when — status updates, new comments, exports to issue trackers, and share-link creation — so the history of a report is always auditable.

These collaboration features are available on every report regardless of source, and they are all included on every plan — BugPort never charges per seat, so unlimited team members can triage together. (Plans differ on workspace storage, not on people.) See the dashboard for the triage experience.

Sharing a report

Sometimes the person who needs to see a bug is outside your workspace — a contractor, a vendor, or a stakeholder without a BugPort account. Share links solve this without granting workspace access.

1. Create a share link

   From a bug's detail view, create a share link. This produces a public, read-only URL backed by the share endpoint (GET /v1/public/share/bug/{share_id}).

2. Send it to anyone

   Anyone with the link can open a read-only view of the report. They cannot change status, comment, or see anything else in your workspace.

3. Revoke when done

   Share links are revocable. Revoke a link from the dashboard at any time to immediately cut off external access.

The public share page respects the same display rules as the dashboard — it shows the panels that have data and omits the ones that do not, so a screenshot-less widget report shares just as cleanly as it displays internally. Share links are strictly read-only: they never expose comments-as-editable, never allow status changes, and never leak other reports or cross-workspace data.

✓ Do

• Use share links for read-only stakeholders who should not have workspace access
• Revoke a link once the external reviewer is finished
• Remember screenshots may contain whatever was on screen — review before sharing externally

✕ Don't

• Treat a share link as private — anyone with the URL can view it until revoked
• Use share links to grant editing or triage; they are read-only by design

Treat share URLs as semi-public

A share link is read-only but not access-controlled beyond the URL itself. Anyone who has the link can view the report until you revoke it. Share deliberately, and revoke when the work is done.

Next steps

📊Dashboard

Filter, prioritize, and resolve reports in one place.

Triage reports🧩Browser extension

Get screenshot, console, network, and replay fidelity.

Capture full reports🔌Integrations

Turn a report into an issue in GitHub or GitLab.

Send to trackers