Fixback docs

The dashboard

GitHub & the return path

Connect a repository and Fixback starts watching what happens to your Issues in it: the branch, the pull request, the merge, the deploy. The Issue closes itself, and the person who reported it hears back — without anyone updating a tracker by hand.

Connecting a repository

  1. Install the Fixback GitHub App

    On the Project, choose Connect repository from its Repository card — or take the offer at the end of guided setup. GitHub asks which account or organization to install on, and which repositories to grant. The installation belongs to your workspace, so a second Project can reuse it without a second install.

  2. Pick the repository

    Choose one repository for this Project. Staging and production are separate Projects if you run them separately, and each points at its own repository.

  3. Ship it, or hand it off

    With a repo connected, you can Ship the Issue to a Fixback-hosted Run, or Hand off a pre-contexted prompt to your own agent — Open in Claude Code (cloud) or Copy prompt. The prompt gains an instruction block telling the agent how to name its branch and what trailer to write, so from then on work links itself.

How work proves it belongs to an Issue

Fixback only sees what webhooks carry, so linkage is a convention rather than an API call. Two signals, either one sufficient:

A trailer in a commit message or the PR description — the primary signal, and the one that survives a squash-merge:

commit message 
Fix the rounding mismatch between the Revenue card and the export.Fixback: fixes FIX-140

A branch name — the secondary signal, which links work before any PR exists:

shell 
git switch -c fixback/FIX-140-revenue-rounding

Both accept the Issue's human key (FIX-140) or its UUID. The keyword is case-insensitive, and several trailers in one message link several Issues. The Handoff prompt emits both forms for you, so in practice you never type either.

Linked work

Each branch working on an Issue becomes one Linked work row in the Issue's rail, moving through these states:

StateReached when
branchA branch matching the convention was pushed. No PR yet.
PR openA pull request exists — number, URL, title and base branch are recorded.
mergedThe PR merged, or trailered commits landed straight on the default branch.
closedThe PR was closed without merging. Nothing happens to the Issue.
liveYour CD reported a successful deployment of the merged base branch.

A push of trailered commits straight to your default branch counts as the fix landing — no pull request required. That is the solo path, and it links exactly as well as a PR does.

Beside it, Activity is the append-only trail of what happened: branch pushed, PR opened, merged, closed, deployed, auto-closed, reporter notified. It records events; it is never a second state machine.

Closing on merge

When linked work reaches merged:

  • An Open Issue closes as resolved, and the Activity records the auto-close.
  • An Issue you had already closed keeps its state — the linkage and Activity still record.
  • If you reopen after an auto-close, it stays reopened. A later deploy only ever stamps it live; a second merge closes it again, correctly, because the fix landed again.

The reporter gets an email at the moment of that transition, at the address they supplied themselves. See Alerts & email.

Live

Merge is the finish line for Fixback. Your existing CD — Vercel, Netlify, whatever you already run — takes it from there. When a successful deployment of the merged base branch arrives, the Linked work row gains a live marker and a link to the deployment, so the Issue reflects that the fix is actually out.

Preview deployments never match: they deploy the head branch, not the merged base. Failed deployments are your CD's business and are ignored. And live is a marker, not a third Issue state — an Issue is still only Open or Closed.