Bug tracking in Jira, with the evidence already attached
Notarus creates a Jira issue from a bug report and carries the evidence with it: the annotated screenshot, the session replay link, the console errors, the failed network requests and the reporter's browser and operating system. Status flows both ways afterwards, so a Jira transition moves the Notarus ticket and the reverse holds.
Jira integration
Every integration is on every plan, the free one included. No credit card.
Discount code accepted but total unchanged
- Issue summary and description
- Media
- Technical context
- Environment
- Status
What reaches Jira
-
Issue summary and description. The report title and body, with the steps to reproduce as the reporter entered them.
-
Media. The captured screenshot as an attachment; a screen recording as a signed link when present.
-
Environment. Browser and version, 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.
-
Status. Status flows both ways. Moving the ticket on the Notarus board moves it in the tracker, and moving it in the tracker moves it back, through a state map an admin sets once per project.
How Notarus and Jira fit together
The usual Jira bug-tracking problem is not Jira. It is that the issue arrives underspecified, because the person who found the bug is rarely the person who knows what a developer needs. They write a sentence, and the first comment on the issue asks which browser they were using. That round trip is what makes triage slow, and no amount of workflow configuration inside Jira fixes it, because the missing information was never captured.
Notarus captures it at the moment of the report and sends it with the issue. The reporter marks the page they are looking at; the widget attaches the screenshot they annotated, the replay of the minutes before, the console output, the failed requests and the environment. What lands in Jira is an issue somebody can act on without a follow-up question.
Connecting is an OAuth flow against your Jira site, after which you choose the project issues are created in. Jira requires an explicit project and issue type before it will accept a create call, so those are chosen rather than guessed. The state map between the Notarus pipeline and your Jira workflow is set once by an admin, and it is deliberately not automatic beyond a first suggestion, because a wrong guess silently moves other people's tickets.
The reporter never touches Jira, which is worth its own line because Jira seats are the expensive part of most teams' tooling. A customer, a designer or a support agent reports from the page they are on and then follows the ticket through the Notarus portal from a link, with no account and no licence. What reaches Jira is the issue; who filed it stays outside.
Common questions
Does Notarus create Jira issues automatically?
It creates one when a report is pushed to Jira, into the project and issue type chosen during setup. Whether that happens on every report or on the ones you select is a project setting, since teams differ on whether unfiltered reports belong in an engineering backlog.
Does the status sync both ways?
Yes. An admin maps the Notarus pipeline to your Jira workflow states once per project, and after that a transition in either system moves the other. The map is set rather than inferred: Jira workflows are custom, and a wrong guess would move tickets nobody asked to move.
What happens to the session replay in Jira?
It travels as a link back into Notarus rather than as an attachment, because a replay is an interactive recording rather than a file Jira can render. A teammate with access to the Notarus project can follow the ticket link to watch the available recording.
Other trackers
Terms on this page: bug triagebug severity vs prioritybug life cycle
Send your first report to Jira.
Every integration is on every plan, the free one included. No credit card.