How the category compares
An honest table across the tools people shortlist together, sourced from each vendor's own published pages and dated.
A BugHerd alternative for the bug nobody can reproduce
Pinned feedback tells you where. This tells you why: the console output, every request the page made, the response bodies inside them and a first view of what went wrong.
The report that nobody can reproduce
A pin on the page says where to look. It cannot say what the browser was doing at that moment.
A client pins the broken thing, writes a clear sentence about it and files it. On the developer's machine the page works. The pin is accurate, the description is accurate, and neither of them holds the one fact that would explain it, because that fact was in the browser rather than on the page.
So the task sits in a column and the thread starts. Which browser was it. Did anything appear in the console. What did the checkout request come back with. The client is not the person who can answer any of those, which is why the task goes quiet and comes back a fortnight later with the same screenshot.
A deeper capture removes the thread rather than shortening it. The console output goes with the report, along with every request the page made while the capture ran, the bodies those requests came back with when you have switched them on, and the browser, the operating system and the window size it happened in. Nobody has to ask the client to open DevTools.
What comes back with the report
Collected around the capture, with nothing to fill in by hand.
The network log as a HAR file
Every request the page made while the capture ran, with method, status and timing, and the whole log downloadable as a HAR file to open in Chrome's own Network panel.
Response bodies
What the server actually sent back, not only the status it sent it with. Opt-in per recording, because a response body carries whatever the page was given, and capped by plan.
A likely cause and a severity
A model reads the whole capture the first time somebody opens the report and writes back steps to reproduce, a likely cause and a suggested severity, quoting the line it argued from. It can be wrong, and what was recorded sits beside it.
Console output
Errors and warnings from the page with their stack traces, so the reply to a report does not have to begin by asking somebody to open DevTools.
The environment it happened in
Browser and version, operating system, screen and window size. The four questions a reply usually opens with, answered before it is sent.
One link, no account
A report is a link. It opens for whoever you send it to, with no sign-in at either end, so a client can hand a bug to a developer without either of them buying a seat.
Where the reports go
There is no board here, so a report has to land somewhere your team already looks: Slack, Microsoft Teams, Jira Cloud, Webhooks, GitHub and Linear. What each destination does with a report, and what connecting it takes, is on the connectors page.
What this does not do
This captures a page deeply and hands you a link, which is where the comparison starts and also where it stops. So that it is a fair one:
- There is no project board. No columns, no assignment, no client workflow. If the board is the thing you are buying, a tool built around one will serve you better than this will.
- Chrome and Chromium only. The capture is a Chrome extension, and there is no Firefox or Safari build for a reporter to use.
- Capture is deliberate. Somebody presses the button when the bug happens. Nothing is recorded in the background and there is no session that was already running.
- Nothing is read back. Closing the issue in your tracker does not close the report, and comments written there do not come back here.
- Report links expire. Thirty days by default, ninety on Professional, and then the link is gone.
- There are six destinations a report can be sent to. If the one your team depends on is not among them, the other tool very likely has it, and that is the better reason to choose it.
BugHerd is a trademark of its owner. We are not affiliated with, endorsed by or connected to it.
Questions people ask when they arrive from BugHerd
No, and that is the honest difference. There is no kanban board, no assignment and no project workflow here. A report is captured deeply, opened on a link, and pushed into the tracker your developers already work in. If what you want is the board itself, the other tool is built for that and this one is not.
The console output with its stack traces, every request the page made while the capture ran, the response bodies inside those requests when they are switched on, and the whole network log as a downloadable HAR file. That is the evidence for a bug that only happens on somebody else's machine.
The capture is done by the Chrome extension, so the first time, yes. The report button handles it: a visitor without the extension gets an overlay explaining what it is and a link to the Chrome Web Store, and on Safari or Firefox the overlay says so rather than offering an install that would not work.
Chrome and Chromium browsers, because the capture is a Chrome extension. There is no Firefox or Safari build, and that is a real limit rather than a roadmap line.
30 days on the free and Starter plans, and 90 days on Professional, after which the link expires. Share pages are marked so search engines do not index them, but the link itself needs no password.
Nothing. Capturing a report and sharing the link is free with no account at either end. Paid plans start at 19 dollars a month and are about what happens afterwards - claiming a domain so reports reach your dashboard, longer recordings, and more of the team.
The rest of the category
Marker.io alternative
The same comparison against the other tool people shortlist here, where the argument is about how deep the capture goes.
Send the evidence, not the symptom
Install it, capture the bug once, and send a link that already answers what the reply would have asked.