The public portal is a page at /p/your-project-slug where anyone can view your project's tasks and follow the ones they reported.
It is off by default.
Why enable it
A user who reports a bug and hears nothing concludes that reporting accomplishes nothing. That is a reasonable inference from the evidence they have. Next time something breaks, they work around it silently — and you lose the signal.
A user who watches their task move from Confirmed to Done learns the opposite. They report the next one.
The portal is the cheapest way to close that loop. There is nothing to maintain — it reflects your board automatically.
Enabling it
In your project settings, turn on portal enabled. Changing project settings requires OWNER or ADMIN.
Once on, the portal is live at /p/your-project-slug, and the widget automatically shows a "View reports" link in its footer. No SDK change is needed.
The extended report setting
A separate setting, portal extended report, controls how much of each report the public sees.
Off (default) — visitors see tasks and basic report information. Technical telemetry stays private.
On — visitors see fuller report detail.
Think carefully before enabling extended reports. Reports contain console logs, network requests, and session replays gathered from real user sessions. That data can include internal endpoint names, error messages revealing implementation details, and — if captureNetworkBodies is on — payloads.
The reporter is not the only audience for a public page. Anyone can read it.
A reasonable default: portal on, extended reports off. Reporters get status, which is what they actually want, and telemetry stays internal.
Consider extended reports when your project is open source, or when your reporters are technical users who benefit from the detail — a developer tool with a developer audience is the case where it earns its place.
What the portal shows
Tasks and their board position, so reporters see whether their bug is open or resolved. Individual tasks have their own public page at /p/your-project-slug/tasks/{publicId}.
Board columns map to open or closed, and that state is what communicates progress. Column names are visible to the public, so name them for an outside audience — Investigating reads better to a customer than Backlog (triage-2).
What to keep in mind
Task titles are public. Write them for the audience. "Checkout fails for EU customers" is fine; "fix Dave's broken migration again" is not.
Comments may be visible. Keep internal discussion appropriate for an outside reader, or hold it somewhere else.
Won't Fix is visible too. That is not necessarily bad — a closed task is more respectful than silence — but the title should not read dismissively.
Turning it off
Disable the setting and the portal stops serving immediately. The widget's "View reports" link disappears on its own.
See also
Working with tasks and the board
Feature toggles and handling sensitive data