How Fixback works

Capture — the SDK on the page

The SDK installs with a single script tag or npm package. It adds two things to any web app: a sleek feedback overlay and always-on session tracing. Two sibling SDKs capture the rest of your product with the same contract: @fixback/expo for a mobile app, and @fixback/node for the server that answers it.

The overlay lets a reporter, from a subtle launcher on the page:

• Select an element on the screen — its DOM path and computed context ride along with the report.
• Draw on a screenshot of the current view, and write a comment attached to what they mean.
• Report in one tap — the captured context does the talking; the reporter never has to write a good bug report.

Underneath, the SDK keeps a ring-buffered Trace so the moments before a report are never lost: console output at every level, JS errors with stack traces, every network request (failures flagged), and the click/scroll trail — plus a buffered replay of the lead-up. When a report is submitted, that recent window is bundled with the annotation and shipped.

Analyze — the cloud brain

Every incoming report flows through an analysis pipeline that:

• Deduplicates and clusters. The same bug reported by ten people, or the same crash recurring across sessions, becomes one Issue with an occurrence count and all the evidence attached.
• Enriches into a Brief. Replay + console trace + annotation become repro steps, expected-vs-actual behavior, and — for improvements — a suggested approach. The Issue arrives pre-thought-through, not just recorded.
• Applies light labels. A Kind (bug / improvement / idea) and occurrence counts. There's deliberately no automated severity engine — you scan the queue and decide what ships.

If you upload sourcemaps for a release, captured stack traces are symbolicated against that exact build, so the Issue also carries a code-area pointer — the likely original file and line.

Queue — the Issue board

Analyzed items land in the Fixback dashboard as Issues with a human key — FIX-140. Each opens to its Brief, its Evidence (replay, console, network, and annotation — as tabs), its merged duplicates, and a properties rail: Kind, reporter tier, project, platform, connected repo, code-area pointer, assignee, and labels. Saved Views and a project scope selector keep the queue legible whether you run one site or many.

You don't have to be watching it. An Alert emails your team when an Issue is filed — after analysis, so it carries the real title and a summary rather than a stack frame — and Mute silences one Issue without resolving it. See Issues & triage and Alerts & email.

Act — from click to live

Connect your GitHub repository, and an Issue becomes actionable — two ways, both driven from the Issue's split action button:

• Ship it starts a Run: a Fixback-hosted coding agent picks up the whole Evidence bundle, implements the change in an isolated sandbox, and drives it as far as your trust settings allow — branch → PR → merge — streaming every stage on the Runs page. It runs on an Agent connection your org configures.
• Hand off a pre-contexted prompt to your own coding agent — Open in Claude Code (cloud), or Copy prompt — assembled from the Brief, the Evidence and the code-area pointer, with the reporter's own words fenced as data.

Either way, the return path is already live. Fixback watches the connected repo read-only: a fixback/FIX-140 branch or a Fixback: fixes FIX-140 trailer links the work, the Issue's Linked work and Activity follow the branch and the pull request, the merge closes the Issue as resolved, and the person who reported it gets an email saying so. See GitHub & the return path.

Merge is the finish line. Your existing CD (Vercel, Netlify, whatever you already run) takes it live; Fixback watches the deploy and marks the Issue live. It never deploys for you.