Bug reports that become GitHub issues with their evidence
Notarus creates a GitHub issue from a bug report, carrying signed media links, captured console and network summaries, and available browser context. A backlink leads to the full ticket and its replay. The sync uses open and closed issue states plus its own labels for Received, WIP and QA, mapped to your Notarus pipeline in both directions.
GitHub integration
Every integration is on every plan, the free one included. No credit card.
Discount code accepted but total unchanged
- Issue title and body
- Media links
- Technical context
- Environment
- Issue state and stage labels
What reaches GitHub
-
Issue title and body. The report title and body, with steps to reproduce as the reporter wrote them.
-
Media links. Signed links to a screenshot or screen recording when captured; no file upload to this provider.
-
Environment. Browser, operating system, viewport and the url the report came from.
-
Technical context. Captured console and network summaries in the issue body, plus a Notarus ticket backlink for the full evidence and replay.
-
Issue state and stage labels. Open and closed, plus pulseback:received, pulseback:wip and pulseback:qa labels for mapped active stages. Other repository labels are preserved.
How Notarus and GitHub fit together
GitHub Issues is the tracker your code already lives next to, which is its advantage and the reason bug reports from non-engineers sit badly in it. A designer or a support agent is not going to open a repository to file an issue, and when somebody files it on their behalf, the details get lost in the retelling.
Notarus is the front door for those reporters. They report from the page they are on, and the issue that appears in your repository includes captured technical summaries and signed media links, with the full evidence available through its Notarus backlink. The person who reported it never sees GitHub, and never needs an account there.
The state model is the thing to know about this integration. GitHub issues are open or closed, and Notarus adds its own labels to distinguish active stages: pulseback:received, pulseback:wip and pulseback:qa. Your Notarus pipeline maps to these provider states, so intermediate progress is visible in the repository as a label while completion closes the issue. These are issue labels, independent of any status field in GitHub Projects.
Existing labels on a repository carry meaning the integration has no way to read: they route triage, drive automations and feed release notes. Notarus preserves those labels and manages only its own three stage labels. When Notarus moves a ticket between active stages, it replaces its managed label; when Notarus completes it, it closes the issue and removes that label. Your team can keep its own labels alongside the synchronized stage without making them part of the Notarus state map.
Common questions
Does this work with GitHub Projects?
The sync targets Issues, which is what Projects is built on, so an issue created by Notarus can be added to a project board like any other. Notarus synchronizes the issue’s open or closed state and its own stage labels. A GitHub Projects status field is separate and is not synchronized.
Do reporters need a GitHub account?
No, and that is most of the point. Reporters use the widget and follow their report through the Notarus portal from a link. GitHub seats stay for the people writing the code.
What about private repositories?
The integration is authorised against the repositories you grant it, private ones included. The issue body includes captured technical summaries and signed screenshot or video links; the full ticket and replay stay in Notarus behind project access.
Other trackers
Terms on this page: bug life cyclebug triageregression testing
Send your first report to GitHub.
Every integration is on every plan, the free one included. No credit card.