Skip to main content

BUG REPORTING

Visual bug reporting, with the evidence attached

A reporter clicks the broken thing and types what went wrong. Annot8 captures the rest — screenshot, console errors, failed requests, browser, viewport, URL — and pins the whole report to the exact element it happened on.

One script tag. No browser extension. Reporters never need an account.

CAPTURED AUTOMATICALLY

What a report carries

Page and browser context come from the widget. Reviewers describe the expected result and choose attachments; screen recording is available on paid plans.

  • A screenshot of the moment

    The visible viewport is rendered automatically — no browser extension, no screen-share permission prompt — and cropped to the pinned element when that tells the story better.

  • A screen recording, when words fail

    Reporters can record their screen and narrate the bug as it happens. The recording lands on the thread next to the comment.

  • Console errors

    Recent console error messages and available source locations help the team investigate what went wrong.

  • Failed network requests

    Requests that errored or returned failure codes are recorded too — the 500 behind the blank screen is in the report before anyone opens DevTools.

  • Browser, viewport, and URL

    Every thread carries the browser, the viewport size, and the exact URL, so “works on my machine” becomes a reproducible starting point.

  • The element itself

    Reports record the DOM element and its CSS selector, preserving page context alongside the screenshot.

  • A voice note, if typing is slower

    Reporters can attach a spoken note instead of an essay — often the fastest way for non-technical reviewers to explain what they expected.

  • Structured fields for triage

    Issue type, priority, expected vs. actual behaviour — filled in on the thread so triage sorts on data, not vibes.

  • No account required to report

    Guest reviewers report through a share link without signing up — and they never consume a seat on any plan.

AFTER THE REPORT

From reported to fixed

Capture is half the job. The other half is getting the bug to the person who will fix it, in the tool where they work.

It lands in one inbox

Bug reports arrive in the same inbox as feedback, board posts, and chats — labelled, assignable, and filterable by page, priority, and status.

It pushes to your tracker

Send a report into Linear, Jira, GitHub, GitLab, Asana, or Trello as an issue that links straight back to the pinned element — automatically for every new thread, or on demand.

It announces itself

Route arrivals to Slack, Teams, Discord, email, or a webhook the moment they land, so the team that watches the channel sees the bug before the standup.

A REPORT WORTH FIXING

Start with a reproducible report

Capture shows what happened. A clear expected result and reproduction steps tell the team what to do next.

The template includes a completed checkout example, a severity-versus-priority guide, and a downloadable file you can use in any tracker. For release reviews, pair it with the website UAT checklist so each fix is verified against a clear acceptance criterion.

The next bug report arrives ready to fix

Paste one script tag and every report shows up with the screenshot, the console, and the exact element — instead of a cropped screenshot in Slack.

Free forever plan · No credit card · 3 guest reviewers included