Skip to main content

BugPort

BugPort turns vague, hard-to-reproduce bug reports into rich, reproducible context. Instead of a one-line "it's broken" message, your team gets the screenshot, the annotations, the console logs, the network requests (including response bodies), and the exact page where the issue happened โ€” captured at the moment it occurred and ready to triage, share, or send to your issue tracker.

This page explains what BugPort is, who it's for, the problem it solves, and how the whole product fits together end to end.

OVERVIEW

What BugPort doesโ€‹

BugPort is a bug reporting and debugging platform. It gives you several ways to capture a problem from wherever it's noticed, stores the heavy context safely, and presents it as a structured report your team can act on.

  • Capture the issue from a browser extension, an embedded widget, the API, or an MCP client.
  • Store screenshots, videos, attachments, thumbnails, large logs, HAR files, and heavy debug payloads in Cloudflare R2 โ€” while metadata, small logs, comments, activity, and usage live in Supabase Postgres.
  • Triage in the dashboard: read the report, comment, set status and severity, and follow the activity timeline.
  • Share a read-only link with anyone, or export the bug to an issue tracker.
๐Ÿ’ก

The core idea: capture the context once, at the source, so nobody has to chase "can you reproduce it?" follow-ups for days.

Who it's forโ€‹

BugPort is built for the people who live with bugs day to day:

Product teams

Collect structured feedback from real usage, prioritize by severity, and keep a clear paper trail of what was reported and decided.

Engineering teams

Get the console logs, network calls, response bodies, and page context needed to reproduce a problem without a back-and-forth.

QA & test

File detailed, annotated reports during test passes โ€” every report carries the evidence attached, not described.

Support

Turn a customer's "something went wrong" into a report engineers can actually work from.

Pricing is storage-based, and every plan includes unlimited team members. You are never charged per person, so inviting QA, support, contractors, or your whole product org costs nothing extra. You pay for the workspace storage your captured media uses. The Free plan includes 1 GB; paid tiers scale up (Starter 25 GB, Team 100 GB, Growth 500 GB, Scale 1 TB), with storage add-ons available when you need more.

The problem it solvesโ€‹

Plain-text bug reports lose the most important thing: the state the application was in when it broke. By the time a developer reads "the dashboard crashed," the screen is gone, the console is cleared, and the failing request is untraceable. Reproduction becomes guesswork, and the report bounces back and forth before anyone can act.

BugPort captures that state at the moment the issue happens, so the report is self-contained.

โœ“ Do

A BugPort report carries the evidence

  • Screenshot with annotations pointing at the problem
  • Console logs from the session
  • Network requests and response bodies for failing calls
  • Exact page path, viewport, and user agent
  • Status, severity, comments, and an activity timeline
โœ• Don't

A plain-text report describes it

  • "It crashed on the dashboard" (which dashboard? what state?)
  • No logs โ€” the console was already cleared
  • No network detail โ€” nobody knows which call failed
  • No page context โ€” which build, which screen, which user
  • Days of "can you send a screenshot / steps to reproduce?"

Four ways to capture a bugโ€‹

Pick whichever capture method fits where the issue is noticed. They all feed the same dashboard and produce the same kind of structured report โ€” just shaped to what each source can capture.

Every report records which source it came from with a source badge (Plugin, Widget, API, or MCP), and the dashboard renders each report to fit its source โ€” for example, a widget report without a screenshot shows annotations, page path, and feedback cleanly, with no broken image panel.

Pricing positioningโ€‹

BugPort does not bill per seat. Two things follow from that:

Unlimited members

Invite everyone who touches bugs โ€” engineers, QA, product, support, external collaborators โ€” on every plan, including Free. Adding people never changes your bill.

Pay for storage

Your cost is driven by how much captured media (screenshots, videos, attachments, HAR files, debug payloads) your workspace stores in Cloudflare R2. Plans range from Free (1 GB) up to Scale (1 TB), with add-ons for more.

This keeps the incentives aligned: bring your whole team, and manage cost by managing what you capture and retain.

How it works, end to endโ€‹

A report flows from the moment a user hits an issue all the way to triage and hand-off:

Under the hood, the "stores context" step splits the data by type:

  • Cloudflare R2 holds the binaries โ€” screenshots, videos, attachments, thumbnails, large logs, HAR files, and heavy debug payloads. Media is uploaded directly to R2 with presigned URLs and never passes through Postgres.
  • Supabase Postgres holds the metadata โ€” the bug record, small logs, comments, activity timeline, usage, and billing.

From the dashboard, the team reads the full report, comments, sets status and severity, and then either shares a read-only public link or exports the bug to an issue tracker. Issue-tracker export through connectors is In progress โ€” GitHub Issues and GitLab are the active targets โ€” so treat that hand-off as still being built out.

Where to nextโ€‹