September 13, 2017 · Izumi Mitsui

How to write a great bug report (with checklist and example)

Updated October 2026

Quick answer: a great bug report tells the support team where the problem is (the exact web address), what you did, what you expected and what happened instead, when it started, how serious it is, and how to reproduce it, ideally with a screenshot or short video. The more of these you include, the faster the problem gets fixed.

At Itomic we love helping our clients, and most of them love being able to email our support address to raise a ticket. The catch is that the first email often doesn’t include what we need, so our first reply is a list of questions. That slows everyone down.

So we’ve written down what makes a great bug report. Here it is, for anyone who reports problems with a website or app.

Bug report checklist

  1. Where is the problem? Copy and paste the exact web address (URL) where it happens.
  2. What did you do, what did you expect, and what happened instead? For example: “I clicked Submit on the contact form. I expected a thank-you message. Instead the page went blank.”
  3. Can you reproduce it? List the steps that make the problem happen again. This is the single most helpful thing you can provide (see below).
  4. A screenshot or screen recording. A picture really is worth a thousand words. Both Windows and Mac have built-in screen recording.
  5. The exact error message, if there is one and it isn’t in the screenshot.
  6. When did it start? Even roughly. It may line up with an update, a content change or a server change.
  7. How serious is it? Is the site down or are customers unable to pay, or is it an annoyance that can wait?
  8. Is it constant or intermittent?
  9. Do you need to be logged in to see it? If so, which account or user role?
  10. What device and browser are you using? For example, Chrome on Windows, or Safari on iPhone.
  11. Has anything changed recently? New plugins, major content edits, new users, or changes to email or other connected systems.
  12. Is the whole website down? Check whether it’s down for everyone or just you with our uptime checker. See why a website can be down for you but not for others.

Why reproducing the bug matters so much

A mechanic needs to hear the strange noise before they can fix it. Developers are the same: if they can see the problem happen, they can usually find and fix it quickly, and confirm the fix works. If they can’t, they’re working in the dark.

If we can’t reproduce a problem, it’s often specific to one computer, browser or network. Clearing your browser cache, trying another browser or device, or checking with your IT team can help narrow it down.

Example of a great bug report

Subject: Checkout error when paying by card on the shop

Where: https://www.example.com.au/checkout/

Steps: Add any product to the cart, go to checkout, choose “Pay by card”, enter card details, click “Pay now”.

Expected: Order confirmation page.

Actual: Red message “Payment could not be processed”. Screenshot attached.

When: Since about 9am today. Two customers have called.

Impact: High. Nobody can pay by card.

Device: Chrome on Windows 11; also happens on my iPhone.

When a bug can’t be reproduced

Sometimes, despite everyone’s best efforts, a problem can’t be reproduced. That doesn’t mean it isn’t real. It may depend on a particular device, network or third-party service, or happen only occasionally. In those cases:

  • Keep a note of each time it happens: date, time, page and what you were doing.
  • Capture a screenshot or video if it happens again.
  • Ask whether others see it, and on which devices.
  • Your support team may suggest a workaround while they keep investigating.

Tips for teams receiving bug reports

  • Reproduce first, before trying a fix.
  • Ask for what’s missing, politely and specifically.
  • Keep a record of what you tried, so the next person doesn’t start from scratch.
  • Keep the reporter informed, even if there’s no fix yet.

Frequently asked questions

What’s the difference between a bug report and a feature request?

A bug report describes something that isn’t working as intended. A feature request asks for something new or different. Both are welcome. See why your team should make more feature requests.

What should I put in the subject line?

A short, specific description, such as “Contact form not sending emails”, rather than “Website problem”.

Need reliable support for your website or app?

Itomic supports websites and custom web applications for organisations across Australia, with a ticketing system that keeps every request on track. Talk to us about support for your site.

Ready to start your next web project?

Talk to us