GitLab bug tracking with the evidence already on the issue

The bug is captured once, and the GitLab issue is created from that capture: the page it happened on, the browser, the first console error and one link to the recording, the console output and the network trace.

Install ExtensionSee how it works

5,0 de 17 avaliações na Chrome Web Store

What gets lost between the report and the issue

The evidence exists. Retyping it into GitLab is where most of it stops.

Today somebody reads the report in one window and writes the issue in another. They copy the address across by hand, describe the browser from memory, and summarise in a sentence what the console said in full.

Every hop loses something. The console line is paraphrased, the window size never travels, and what reaches the project is a description of evidence rather than the evidence. The engineer who picks it up asks for the half that went missing, and the bug waits another day for an answer that already existed.

Filing from the report removes the hop. The issue arrives carrying the report link, the page it happened on, the browser it happened in and the first console error, so the project holds what was captured rather than somebody's account of it.

A shared report showing the reporter's note, the console output and the browser it was captured inA shared report showing the reporter's note, the console output and the browser it was captured in

Three steps to file into GitLab

Connect the account and pick the project

A team admin authorises GitLab on gitlab.com, chooses the project to file into, and binds it to one of your domains or to all of them. Nothing is installed into the project itself, and what the connector asks for is written out on the GitLab card on the connectors page.

Capture the bug

Whoever hits the bug opens the side panel on the page that is misbehaving and records or screenshots it. The browser, the window size, the console output and the network log are gathered with it, so nobody has to remember them afterwards.

Press the button and the issue exists

Anybody looking at the report files it in one press, and the issue arrives in the project with the report link, the page, the browser and the first console error already in the body.

What lands in GitLab

The issue body the connector writes, as the project receives it.

What arrives
Creates an issue in the project you chose, carrying the report and a link to it. Nothing is filed automatically: an issue is created only when somebody presses the button on a report.
The first line of every issue is the report's link, and that link is public. Anyone who can read issues in the project can open the report without signing in, and in a public project that is everybody.
What connecting takes
A team admin connects GitLab on gitlab.com, chooses the project to file into, and binds it to one of your domains or to all of them. Session Replay never edits, closes or deletes anything, and never reads your code.
In the project
[Open report](https://session-replay.com/replays/8f3c1ab9d24e)

### What the reporter wrote

> The discount code applies but the total does not change.

- Page: https://shop.example.com/checkout
- Browser: Chrome 139
- Operating system: macOS 15.5
- Reported by: Anonymous
- Severity: Major

12 console lines · 34 requests, 1 failed

First error:
```
Uncaught TypeError: discount is null (cart.js:214)
```

GitLab is one of several destinations a report can be sent to. What each of the others does with a report, and what connecting it takes, is on the connectors page.

What this does not do

The connector carries a report outward and stops there. So that you can judge it fairly before wiring it up:

  • Nothing is filed automatically. An issue exists only when somebody presses the button on a report, never because a report arrived.
  • The capture is never in the payload. The recording, the console output and the network log stay behind the link the issue carries, and the issue carries the details rather than the files.
  • A report's share link is public, and it is the first line of every issue. Anyone who can read issues in the project can open the report without signing in, and in a public project that is everybody.
  • We ask GitLab for the api scope and nothing more, because read_api can create nothing. Nothing is edited, closed or deleted, and your code is never read.
  • Nothing is read back and nothing syncs. Closing the issue does not close the report, and comments written on the issue do not come back.
  • gitlab.com only. A self-managed or GitLab Dedicated instance is not a destination this connects to.
  • Setup belongs to a team admin, once, for the whole team, and nothing is captured until somebody presses a button.

Questions teams ask before connecting GitLab

The report's title becomes the issue title, truncated at 255 characters, and the body carries the report's link on its first line, then what the reporter wrote, the page it happened on, the browser and operating system, who filed it and how severe they called it, how many console lines and requests were recorded, and the first console error in a fenced block. The recording and the full logs stay behind that link rather than travelling as attachments.

No. An issue exists only when somebody looking at a report presses the button on it. The issue number is kept on the report afterwards, so the next person to open it can see it was already filed rather than filing a second one.

The api scope and nothing more, used to list the projects you can file into and to create issues in the one you chose. GitLab offers no issue-only grant: read_api can create nothing, so api is the narrowest scope that can file an issue. Nothing is edited, closed or deleted, and your code is never read.

Any project on the connected account where you hold at least Reporter access and issues are switched on. A project with issues disabled cannot be filed into, and the setup screen says so while you are choosing rather than failing the first time somebody presses the button.

The first line of every issue is the report's link, and that link is public. Anyone who can read issues in the project can open the report without signing in, and in a public project that is everybody. File into a private project if the reports should not be readable by anyone who finds the issue.

No. The connector talks to gitlab.com, so self-managed and GitLab Dedicated instances are not destinations it can file into today. The webhook connector is the route for those: it posts every report event to any HTTPS endpoint you name.

Stop retyping the bug into the issue

Capture the page once, connect the project once, and let the issue arrive with the recording, the console and the browser already behind one link.

Install ExtensionSee pricing

5,0 de 17 avaliações na Chrome Web Store