How to Report a Bug So It Gets Fixed Fast
By CodexierPublished 5 min read
'The form doesn't work' is the most common bug report developers receive, and the slowest to fix. Before anyone can repair anything, they need to see the problem happen, and that takes questions, waiting and more questions. A good report answers those questions up front. This guide gives you a template that works for websites, webshops and apps, and explains why each part matters.
What developers need to reproduce it
Most bugs only appear under certain conditions: a specific browser, a logged-in user, a product with a variant, a form filled in a certain order. If the developer cannot reproduce it, they are guessing. That is why the best bug reports read like a recipe.
| Field | Example |
|---|---|
| Title | Checkout: Klarna option missing for orders over a certain amount |
| Where | Checkout page, step 2 (payment) |
| Steps | Add product X, go to checkout, enter a Stockholm address, choose standard shipping |
| Expected | Klarna appears as a payment option |
| Actual | Only card and Swish appear |
| Device and browser | iPhone, Safari, latest iOS |
| When | Today around 10:15, still happening |
| Impact | Customers who want to pay by invoice leave the checkout |
Steps, device and browser
Write the steps as if the developer has never seen the site. Start from a URL, list each click and each value entered, and stop at the moment it goes wrong. Then try it again yourself. If it only happens sometimes, say so and describe what was different when it worked.
- The full URL of the page, not just the page name
- Logged in or not, and with which type of account
- Device model and operating system version
- Browser and version; 'latest Chrome' is usually enough
- Whether it also happens in another browser or on another device
- Exact date and time, so logs can be checked
Screenshots and recordings
A picture removes ambiguity. A short screen recording is even better for problems that depend on a sequence of steps. Both iPhone and Android have built-in screen recording, and on a computer tools built into Windows and macOS do the job.
- Capture the whole screen, including the address bar
- Copy error messages as text as well as in the image
- For forms, show the values entered, but blur personal data such as personal numbers or card details
- Do not send passwords in the report; share access separately and securely
Expected vs actual behaviour
This is the part most reports skip, and it matters more than it seems. Sometimes what looks like a bug is how the system was built, and what is needed is a change request, not a fix. Stating what you expected makes that difference clear and avoids arguments about whether the work is covered by the maintenance agreement.
Keep one problem per report. A list of five unrelated issues in one email is hard to prioritise, track and confirm as done. Our guide on change requests and scope creep explains why the distinction between fix and change matters for cost.
Priority and business impact
The developer cannot judge how much a problem costs you. Tell them. A broken checkout on a Friday evening and a misaligned footer icon are both bugs, but they are not equally urgent.
| Priority | Typical examples | Expected response |
|---|---|---|
| Critical | Site down, checkout or booking broken, security issue | Immediately, per your agreement |
| High | A key feature broken for some users | Within a working day or two |
| Normal | Something wrong but a workaround exists | Planned into the next batch |
| Low | Cosmetic issues, typos | When convenient |
Your maintenance agreement should define these levels and response times.
If you suspect a security problem, such as unknown admin users or a page redirecting to strange sites, do not wait for the normal channel. Call your supplier and read our guide on a hacked website's first 24 hours.
Making it a routine
Save the template somewhere everyone who reports problems can find it, or put it in a form that creates tickets directly. Our monthly maintenance package includes a reporting channel with agreed priorities and response times; see pricing.
When you do not need a maintenance agreement: if your site rarely changes and you can wait a few days for fixes, ad-hoc hourly help may be cheaper. Book a short call if you want to compare the two.
Frequently asked questions
What if I cannot reproduce the bug myself?
Report it anyway, but say so, and give everything you know: who saw it, when, on what device, what they were doing. Intermittent bugs are often found through server logs, which is why the time matters.
Should I report bugs by email or phone?
In writing, whatever the channel. A phone call is right for critical problems, but follow it with a written report so nothing is lost and the fix can be confirmed against it.
Is a bug fix included in my maintenance plan?
That depends on your agreement. Fixes for things that used to work are usually included; changes to how something was designed to work usually are not. Stating expected behaviour helps settle which it is.
How do I know when it is fixed?
Ask for confirmation against your original steps, then repeat them yourself. Close the report only when you have seen it work.
Tired of chasing fixes?
On a short call we go through how problems are reported and handled today, and whether a maintenance plan with clear priorities would help.
Book a free 15-minute call