A useful website bug report lets someone else reproduce the problem without asking you to explain it again. Give them the starting conditions, the smallest set of steps that triggers it, and the difference between what you expected and what happened. Use the template below in your issue tracker, a shared document, or your feedback widget.
A website bug report template you can use today
Report one failure per ticket. A title such as ‘Checkout — Continue button does nothing after address entry’ is easier to find and assign than ‘Checkout broken’. Fill in what you know; explicitly mark unknown details instead of guessing. An engineer can investigate a clear report even when you cannot explain the cause.
Title: [Page or feature] — [specific failure] Environment and build: [staging/production + release] Page URL: [exact page, with sensitive values removed] Browser / OS / viewport: [versions and dimensions] Preconditions: [account role, test data, relevant settings] Steps to reproduce: 1. [Starting point] 2. [Action] 3. [Action that triggers the failure] Expected result: [observable outcome] Actual result: [what happened instead] Frequency: [always / sometimes + attempts] Impact and workaround: [who is blocked; any safe alternative] Evidence: [screenshot / short recording / relevant error] Owner and status: [person + next action] Verification: [build tested + result after the fix]
Download the bug report template (.txt)
The preconditions matter as much as the clicks. A new account, an expired session, a particular locale, or an empty basket can change the result. Record the conditions you used and the release you tested. If the URL contains a token or personal data, replace those values before sharing it.
A completed example: checkout fails on a narrow screen
This is a fictional example, not a defect in Annot8. Notice that the report describes an observable failure without diagnosing a JavaScript bug or blaming a browser.
Title: Checkout — Continue button is covered by the cookie banner Environment and build: Staging, release candidate rc-12 Page URL: https://shop.example/checkout Browser / OS / viewport: Safari 18 / iOS 18 / 390 × 844 Preconditions: Guest checkout; one item in basket; consent not yet chosen Steps to reproduce: 1. Open the staging storefront in a fresh browser session. 2. Add one item and open checkout. 3. Enter a valid delivery address and try to press Continue. Expected result: Continue is visible and advances to delivery options. Actual result: The cookie banner covers the button. Tapping the visible edge opens cookie settings instead of the next checkout step. Frequency: 3 out of 3 attempts with the banner open. Impact and workaround: Guest shoppers cannot continue until they dismiss the banner. The same journey works after choosing a consent option. Evidence: Screenshot showing the overlapping controls. Owner and status: Checkout team — awaiting triage. Verification: Repeat with the banner open and closed after the layout fix.
The final line tells the tester what to verify after the fix. Check both consent states, then nearby viewport sizes and other controls in the affected area. A fix that reveals the button but prevents the banner from scrolling has moved the problem rather than resolved it.
Keep severity separate from priority
Severity describes the effect of a failure. Priority describes when the team should address it. Your team should agree on labels rather than treating the table below as a universal standard. A minor typo in a legally required disclosure may be urgent; an unusual visual defect may be severe on a page that is not part of this release.
| Failure | Impact to record | Decision to discuss |
|---|---|---|
| Payment cannot be completed | Shoppers are blocked; no safe workaround | Release blocker for the checkout journey |
| Primary button is hidden at one viewport | A supported mobile journey needs a workaround | Fix before release or explicitly accept the risk |
| Heading has extra spacing | Content and actions remain usable | Schedule polish unless it breaks an agreed design requirement |
Record how often it happens and who it affects. ‘Intermittent: 2 of 10 attempts on a slow connection’ is more useful than ‘random’. Keep passwords, access tokens, customer records, and payment details out of attachments.
Capture evidence that answers a question
- Use a screenshot for a static problem: the missing text, overlapping control, or wrong state. Include enough of the page to show where it happened.
- Use a short recording for a sequence: open the menu, select the option, show the unexpected result. End once the failure is visible.
- Include relevant console errors or failed requests when available. An error near the same time is evidence, not proof of the root cause.
- Review the evidence before sharing. Test with synthetic accounts and remove confidential values from URLs, logs, and screenshots.
Browser developer tools provide a console and network inspector for investigating page behavior. Ask a technical teammate for help if you are unsure what an error means; reporters should not need to debug the application to submit a useful report.
MDN: what browser developer tools can show
Annot8 pins reports to page elements and records page and browser context. Reporters can attach screenshots; screen recording and tracker integrations are available on paid plans. Use the captured context alongside your reproduction steps, not as a replacement for explaining the expected result.
Hand off the report and verify the fix
Give each accepted report one owner and one next action. Link duplicate reports to the original while preserving any new conditions or evidence. If more detail is needed, ask a specific question such as ‘Did this happen before or after signing in?’ instead of reopening the entire investigation.
After a fix, repeat the original steps on the intended release. Record the build, browser, and result, and test the neighboring path that the change could affect. Close the report when the acceptance criterion passes; keep it open if the result is only partly fixed.
Plan the rest of your release with the website UAT checklist
