Bug reporting for GitHub

Every bug becomes a GitHub issue.

FeedBug adds a visual bug reporting widget to your website. Testers click the bug, your developers get an issue in the repository with the screenshot, the diagnostics and a link straight to the source code.

Free forever for solo teams. No credit card.

Setting it up on GitHub.

1

Sign in with GitHub

Use the button above. FeedBug asks for access to your repositories so it can open issues on your behalf, and for your email so the account can be created.

2

Create a project and pick a repository

In the dashboard, create a project, open its Destinations card, choose GitHub, then pick the repository that should receive the issues. You can add several destinations and let reporters choose.

3

Paste the snippet on your site

Copy the script tag from the project page and drop it before the closing body tag. It carries your project key, so there is nothing else to configure.

4

Nothing to configure for status sync

FeedBug installs the repository webhook for you when you pick the repository, with its own signing secret. Closing an issue on GitHub marks the report resolved without you touching a settings page.

5

Optional: pin the deployed commit

Add <meta name="feedbug-commit" content="YOUR_COMMIT_SHA"> to your page head, or a data-commit attribute on the script tag. FeedBug then links to the exact version of the file that was live when the bug was reported, instead of whatever the default branch has become since.

6

Restrict the domains

In Configuration, list the domains allowed to send reports. Anything else gets rejected, so nobody can post issues to your repository from a site you do not control.

The snippet looks like this:

<script
  src="https://cdn.feedbug.app/w.js"
  data-project="pk_your_project_key"
  data-pins="true"
></script>

Attached to every issue.

Viewport screenshot embedded in the issue body
Console logs and JavaScript errors
Failed network requests with status and timing
OS, browser, screen size and pixel ratio
Page URL and DOM snapshot around the pin
30-second session replay before the report
Custom cookies, localStorage and sessionStorage keys
Labels applied automatically per destination

Frequently asked questions

How does FeedBug create GitHub issues from bug reports?

You sign in with GitHub via OAuth and pick a repository. When a tester submits a report through the widget, FeedBug opens an issue in that repository with the screenshot embedded in the body, the page URL, the browser diagnostics and a link back to the live pin on the page.

Do my testers need a GitHub account?

No, and that is the point. Reporters click the bug on your site and write a sentence. Only the person setting FeedBug up connects GitHub, so designers, clients and QA testers never need a seat on your repository.

Does it work with private repositories?

Yes. The OAuth scope covers private repositories, and the repository picker lists everything you own, collaborate on, or have through an organisation.

What gets attached to each issue?

A viewport screenshot, the page URL, OS, browser, screen size, console logs, JavaScript errors, failed network requests, a 30-second session replay, and any custom data keys you configure. Everything lands in the issue body as markdown, so it is readable directly on GitHub.

Does the status sync back from GitHub?

Yes, and you do not have to set it up. FeedBug installs the repository webhook when you add the destination, so closing an issue on GitHub marks the report resolved and updates the pin on the page. Note that GitHub issues only have two states, open and closed, so there is no in-progress step the way there is with Linear.

Can I apply labels automatically?

Yes. Each destination can carry a list of labels that FeedBug applies to every issue it opens, so bug reports land in the views and filters your team already uses.

Does FeedBug tell me which file the bug is in?

It tries. FeedBug reads the component name from the page, looks it up in your repository and adds the most likely source files to the issue as links. It works best on Vue, where component names survive the production build. On a minified React bundle the name is often lost, and no link is added rather than a wrong one.

Does the status follow my pull requests?

Yes. When a pull request references the issue, the report moves to In review, and to Merged once the pull request lands. A pull request closed without merging sends the report back to open. That gives GitHub the intermediate state its issues do not have.

Can my AI agent fix the bug from the issue?

Yes. FeedBug ships an MCP server your coding agent connects to. Claude Code or Cursor reads the report with its screenshot, console logs and DOM context, and traces it to the source file to propose a patch.

Start in two minutes.

One script tag, one repository, and bug reports your team can ship from.

Using Linear instead? See the Linear guide