Dashboard
The BugPort dashboard at app.bugport.dev is your operations console — the place where every bug, no matter how it was captured, lands as a structured, reviewable report. It is where you triage incoming issues, read the evidence behind them, set status and severity, leave context for teammates, and hand work off to your tracker. If the browser extension and widget are how bugs enter BugPort, the dashboard is where they get understood and resolved.
This guide walks through signing in, finding your way around workspaces and projects, working the bug list, reading a bug detail view zone by zone, sharing reports externally, and keeping an eye on storage. It closes with practical guidance for triaging quickly without missing what matters.
Signing in
BugPort uses Supabase Auth. You can sign in three ways:
- Google — one-click social sign-in.
- GitHub — one-click social sign-in.
- Email and password — classic credentials.
Social sign-in requires that the provider is enabled for the workspace and that your origin's /auth/callback is on the redirect allowlist. In hosted BugPort this is already configured; if you are running a self-hosted instance and a social button fails, that allowlist is the first thing to check.
If this is your first time, you will not land directly on a bug list — you will be guided through onboarding first.
Onboarding for new accounts
A brand-new account has no workspace yet, so BugPort walks you through creating one. Onboarding:
- Creates your first workspace — the top-level container that holds projects, members, storage, and billing.
- Prompts you to create your first project — the unit a bug belongs to (typically one app, site, or service).
- Points you at a capture method so you can get a real bug flowing in.
Every plan includes unlimited team members, so you never need to ration invites. The Free plan starts with 1 GB of workspace storage; you can scale up later (Starter 25 GB, Team 100 GB, Growth 500 GB, Scale 1 TB) without changing how the dashboard works.
Dashboard anatomy
The dashboard is a three-region layout: a persistent left sidebar for navigation, a central bug list for scanning and filtering, and a bug detail view that expands when you open a single report.
Workspace and project navigation
The sidebar is anchored by the workspace switcher at the top. A workspace is fully isolated — its bugs, members, storage, and billing never bleed into another workspace. Switching workspaces re-scopes everything below it.
Under the switcher are your projects. Selecting a project filters the bug list to that project; selecting the workspace root shows bugs across all of its projects. Below projects, the sidebar carries navigation to cross-cutting areas:
- MCP Connections — manage scoped tokens and copy client setup snippets (see MCP).
- Integrations — connect issue trackers. In progress
- Settings — members, invites, widget keys, storage, and billing.
The bug list
The bug list is the triage surface. Each row is a compact summary of one report, designed to be scanned quickly. The columns that carry the most signal are the source badge, status, and severity.
Source badges
Every bug shows where it came from. The source shapes what evidence you can expect inside:
create_bug_comment context, or surfaced via MCP tooling. See MCP.Because sources produce different report shapes, the dashboard adapts the detail view per report. A widget bug submitted without a screenshot renders its annotations, page path, and feedback cleanly — you never see a broken image panel where a screenshot would have been.
Status and severity
- Status moves a bug through its lifecycle — typically new, in review, and resolved states. Status is the field you change most during triage.
- Severity signals impact and urgency. Set it deliberately; it is the field teammates sort and filter by when deciding what to pick up next.
Filters and scoping
The list can be narrowed several ways at once:
- By project — pick a project in the sidebar to scope the list.
- By status — focus on what is unresolved, or review what has been closed.
- By severity — surface the high-impact reports first.
- By source — isolate, say, only widget-submitted feedback or only extension captures.
Combine these to build the working view you want — for example, "open, high-severity, in this project" is a strong default triage queue.
The bug detail view
Opening a row expands the full report. The detail view is organized into zones, each answering a different debugging question. Read it top-to-bottom the first few times; with practice you will jump straight to the zone that matters for a given bug.
Media and evidence rail
The evidence rail leads with the screenshot because it is usually the fastest path to understanding a bug. Annotations overlay the image so you see what the reporter meant, not just what they saw. Screenshots, videos, thumbnails, and any heavy attachments are stored in Cloudflare R2 and streamed in — they never pass through Postgres — which keeps the dashboard responsive even for large evidence.
Reproduction and page context
Below the evidence, the page context tells you where and how the bug happened: the exact page path and URL, the viewport size, and the user agent. Combined with the reporter's feedback text, this is normally enough to reproduce the issue or rule out an environment-specific cause.
Console and network logs
Console logs show what the browser was complaining about; network logs show what the app was asking for and getting back. For extension captures these are rich. Network rows expand to reveal request detail, and where the capture could read it, the response body is attached so you can inspect the actual payload that triggered a failure.
Response bodies are only captured for responses the browser allowed the extension to read. Opaque, cross-origin, and binary responses are not captured — you will see the request and its status, but no body. This is a privacy and browser-security boundary, not a bug.
Activity timeline and comments
The activity timeline is the bug's history — every status change, severity change, comment, and export, in order. It answers "who changed what, when." Comments are where the human conversation happens: repro confirmations, questions for the reporter, and handoff notes. Together they keep a bug self-documenting so anyone picking it up later has the full story.
Triaging efficiently
Triage is a queue-management problem: many reports arrive, and your job is to route each one to its right next step quickly. A consistent flow keeps the queue moving.
- Scan the source badge first — it tells you how much evidence to expect before you open the report.
- Set severity early, even if roughly; it is what teammates sort by.
- Leave a one-line comment when you park a bug, so the next person knows why it is waiting.
- Use filters to build a focused queue (open, high-severity, one project) instead of scrolling everything.
- Confirm the page context matches the reported environment before chasing a phantom repro.
- Don't resolve a bug without reading the evidence rail — the screenshot often contradicts the title.
- Don't expect response bodies on cross-origin or binary requests; their absence is normal.
- Don't rely on memory for handoffs — put repro steps in comments, not chat.
- Don't leave severity unset on a high-impact bug; it will sink in the list.
Sharing reports
Sometimes the person who needs to see a bug is not in your workspace — a contractor, a vendor, or a stakeholder. BugPort lets you create a read-only share link for a single bug.
- Share links are public and read-only. Anyone with the link can view the report; no one can edit it.
- Share pages respect the same display rules as the dashboard — a widget bug without a screenshot renders annotations and context cleanly, with no broken panels.
- Share links surface the bug's evidence, context, and logs, but never expose your workspace, other bugs, or any write actions.
Create and manage share links from the bug detail view. Because they are public, treat them like any unguessable-but-shareable URL: share deliberately, and revoke when a report no longer needs an external audience.
For AI-assisted debugging inside your own tools, prefer a scoped MCP token over a public share link. MCP access is workspace-scoped, revocable, and audit-logged, and it never serves public-share data.
Storage awareness
BugPort pricing is based on workspace storage, not seats — every plan includes unlimited members. Screenshots, videos, attachments, thumbnails, large logs, HAR files, and heavy debug payloads are stored in Cloudflare R2 and counted toward your workspace's storage usage. Lighter metadata, small logs, comments, and activity live in Postgres.
The dashboard surfaces your current workspace storage usage so you can see how much of your plan's quota you are consuming:
- Free — 1 GB
- Starter — 25 GB
- Team — 100 GB
- Growth — 500 GB
- Scale — 1 TB
When you approach a limit, upgrade the plan or add storage from billing in Settings — your members, projects, and workflow stay exactly as they are.