Annoture
FeaturesHow it worksPricingCompareAbout
Notify me
Use case — Bug Reporting

Automatic bug reports with screenshots developers actually want

Stop the back-and-forth. Every report includes an automatic screenshot, the exact URL, browser version, OS, and DOM element — captured in one click, no manual write-up required.

Get early access →

Why most bug reports waste everyone's time

A developer receives a bug report. Before they can even start working on it, they have four questions.

❓

"What URL was it on?"

The most common follow-up question in every bug report. The answer is obvious to the person who filed it — but they forgot to write it down.

🖥

"What browser were you using?"

Developers need to reproduce the issue in the same environment. Without browser and OS details, they're guessing.

🗓

"Can you show me where exactly?"

A vague description of "the button on the checkout page" forces a back-and-forth that adds days to the resolution time.

📎

"Can you send a screenshot?"

Even when there is a screenshot, it's often a cropped phone photo, a tiny area of the screen, or missing the element entirely.

A complete report, captured automatically

Every Annoture bug report includes six pieces of information that are automatically captured — without the reporter having to do anything extra.

🔗

Page URL

The exact URL at the moment the bug was captured — including query parameters and fragments.

🌐

Browser & version

Full browser name and version number. Chrome 124.0, Safari 17.4, Firefox 125 — always accurate.

💻

Operating system

macOS, Windows, or Linux — with the full version. Reproduce edge cases that only occur on specific OS builds.

📐

Viewport size

The exact pixel dimensions of the browser window. Identify layout bugs that only appear at certain screen sizes.

🎯

DOM element

The specific element that was clicked — including its ID, class, tag name, CSS selector, and XPath.

📸

Full-page screenshot

A complete screenshot of the page at the time of capture, with the clicked element automatically annotated.

Before and after Annoture

The difference between a typical bug report and an Annoture bug report.

AspectTypical reportAnnoture
URL capturedOften missingAlways included
Browser & versionUsually missingAuto-captured
Operating systemRarely includedAuto-captured
ScreenshotSometimes attachedEvery report
Element locationVague descriptionCSS selector + XPath
Time to report5–15 minutesUnder 10 seconds
ReproducibilityHit or missFirst time, every time
FOR DEVELOPERS

Fewer back-and-forths.
Faster fixes.

When a bug report lands in your board with the exact URL, the browser version, the OS, a full screenshot, and the CSS selector of the broken element — you can start working immediately. No questions, no waiting.

Reproduce it first time All the context you need is there from the start.
See the exact element CSS selector and XPath mean no hunting through the DOM.
Prioritise by severity Critical bugs are clearly marked so you know where to start.
Everything in one place Backlog, In Progress, Done — the full picture on one board.
IN PROGRESSassigned to you
screenshot.png
!

Payment form crashes on Safari 17 — checkout page broken for macOS users

URL: app.annoture.com/checkout
Browser: Safari 17.4 · macOS 14.4
Element: button#pay-now
Critical#042 · 2 hours ago

Everything a developer needs to fix it — right there.

Bug reporting questions

Common questions from teams looking to improve their bug reports.

What makes a good bug report?
A good bug report includes the exact URL where the bug occurred, the browser name and version, the operating system, a screenshot showing the issue, the specific element involved, and clear steps to reproduce. Annoture captures all of this automatically in one click — the only thing you write is a one-line description.
Why do developers always ask follow-up questions after receiving a bug report?
Because most bug reports are missing the technical context needed to reproduce the issue. The most common gaps are: missing URL, no browser or OS info, no screenshot, and a vague description of which element was broken. Annoture fills all of these automatically so developers can start working immediately.
Can non-technical team members file useful bug reports?
Yes. Because Annoture captures all the technical details automatically, product managers, designers, and stakeholders can file complete, developer-ready reports with just a one-line description. The tool handles the technical context — they just describe what went wrong.
How does Annoture capture the DOM element?
When you click on an element in capture mode, Annoture reads the element's tag name, ID, class names, CSS selector, and XPath from the DOM and attaches them to the report. Developers can use the CSS selector or XPath to find the exact element without hunting through the codebase.
Does Annoture capture the full page or just what's visible?
Annoture captures a full-page screenshot — including content below the fold — not just the visible viewport. The element you clicked is automatically annotated with a marker so developers can see exactly where the issue is.
What if the bug only happens on a specific browser or OS?
Because Annoture automatically records the browser name and version plus the operating system and version on every report, environment-specific bugs are immediately identifiable. Developers can filter the board by environment and know exactly which configuration to test.

Better bug reports start here

Give your team the context they need to ship fixes fast. Get early access to Annoture — free to start.

Get early access →