How to report a bug when you're not technical
You clicked "Save" on the settings page and nothing happened. You open the bug tracker, look at the empty description box, and freeze. You are not sure what a developer wants, and you are worried you will sound silly.
So the bug sits in your head, or in a chat message nobody reads again. Here is the good news: you already have everything you need.
Short version
- A developer needs to see the bug happen on their own screen. Your job is to give them a path back to it.
- You never have to guess the cause. Guessing makes reports worse, not better.
- Capture six things: your goal, the page address, your steps, expected versus actual, a picture, and the basics.
- Copy error messages word for word. Do not summarise them.
- File one bug per ticket, in one message, with real details instead of the word "urgent".
The one idea that matters
A developer cannot fix what they cannot see. Before they write a single line of code, they need to make the bug happen on their own computer. This is called "reproducing" the bug.
So think of your report as a set of directions. You are not diagnosing anything. You are drawing a map to the place where things went wrong. If a developer can follow your map and see the same broken thing, you have done your job perfectly. That is the whole test.
The six things to capture
1. What you were trying to do
One sentence about your goal, in normal words. Not the steps yet, just the intent.
"I was trying to change the email address on my account."
This tells the developer what the feature was supposed to achieve. Sometimes they find the feature works but is confusing, which is also a bug worth fixing.
2. The exact page address
The page address is the text in the bar at the top of your browser, usually starting with https://. Click it once, copy it, and paste it into the ticket.
https://staging.example.com/settings/account?tab=profile
Do not type "the settings page" from memory. The part after the question mark can be the difference between a page that works and one that does not.
3. Your steps, numbered
Write what you did, one action per line. Start from a fresh state — logged out, or on the home page — so the developer can follow from zero.
- Go to
https://staging.example.comwhile logged out.- Log in as [email protected].
- Click "Settings" in the top right menu.
- Click the "Profile" tab.
- Change the email field to
[email protected].- Click "Save changes".
Five or six short lines is usually enough. If you cannot remember a step, say so instead of inventing one.
4. What you expected versus what happened
Write both. This sounds obvious, and it is the part people skip most.
Expected: The page shows "Profile updated" and the new email appears in the field.
Actual: The page stays still for about three seconds, then shows a red bar with the text "Something went wrong. Please try again."
Copy any on-screen message exactly. Developers search their code for that string. Change one word and the search finds nothing.
5. A screenshot or short recording
A picture removes a lot of doubt. Take a screenshot of the whole browser window, including the address bar, so the URL is visible in the image too.
If the problem involves movement — a button that flashes, a menu that closes too early, a page that jumps — record your screen for ten or fifteen seconds instead. Most computers can do this without extra software.
6. The basics
These four details answer most follow-up questions before they are asked:
- Browser and version. For example, Chrome 126.0.6478.127.
- Device and system. For example, MacBook Air, macOS 15.4. Or iPhone 14, iOS 18.
- The account you used. For example, [email protected]. Say the role too if you know it, such as "Viewer" or "Admin".
- Date and time. For example, 29 July 2026, around 14:20 UK time. Servers keep records by time, so this helps a developer find your exact request.
How to find your browser version
People skip this because they think it is hard. It takes about eight seconds in Chrome.
- Click the three dots in the top right corner.
- Hover over "Help", then click "About Google Chrome".
- Read the line that says "Version 126.0.6478.127".
- Copy that whole number into your ticket.
Firefox, Edge, and Safari hide the same thing under a menu called "Help" or "About". You do not need to understand the number. You just need to paste it.
Say it the way a developer needs it
Most reports are not wrong. They are just too short.
| What you might say | What a developer needs instead |
|---|---|
| "Save is broken." | "Clicking Save on /settings/account shows 'Something went wrong. Please try again.' and the email does not change." |
| "It gives an error." | "The red bar says exactly: 'Something went wrong. Please try again.'" |
| "It's slow." | "The report page took 22 seconds to load. I timed it twice." |
| "It happens sometimes." | "It failed 3 times out of 5 attempts, always on the second save in a row." |
| "The site is down for a client." | "Blocked: Acme Ltd cannot check out. They have tried since 09:00 today." |
| "Probably a database problem." | "I do not know the cause. Here are the steps and the screenshot." |
The right column never explains why. It only describes what happened, in more detail.
How often does it happen?
Developers treat "always" and "once" very differently. Try the steps two or three more times and count. Then use plain words:
- Every time. You repeated the steps five times and it broke five times.
- Sometimes. It broke 2 times out of 5. Say what was different, if anything.
- Once. You cannot make it happen again.
A bug that happened once is still worth filing. Say so clearly, and include the time so the developer can look in their records.
Check a second browser before you file
One extra minute here saves hours for the whole team.
- Open a different browser, or a private window. In Chrome this is "Incognito", opened with Shift + Ctrl + N (Shift + Command + N on a Mac).
- Run through your steps again.
- Write down whether the problem appeared there too.
If the bug happens everywhere, it is in the product. If it happens only in your normal Chrome window, something on your machine may be involved, like an old saved file or an extension. Either answer is useful. Write down what you found: "Also happens in Firefox 128" or "Works fine in Incognito". If a phone is nearby, try it there too.
What the console is, in plain words
The console is a hidden panel in your browser where the page writes notes about itself, including error text that never appears on screen. Developers read it because it often names the exact line of code that failed, with something like TypeError: Cannot read properties of undefined.
You do not need to understand any of it. You may just be asked for it. The easy way to hand it over: press F12 (or Command + Option + I on a Mac), click the tab named "Console", take a screenshot of whatever is there, and attach it. Red lines are the interesting ones. That is all anyone expects from you.
Tools like Crosscheck capture those console messages, network requests, and browser details for you when you report a bug straight from the page.
Five things not to do
Do not guess the cause. Writing "I think the database is down" sends the developer to the wrong place. If you have a hunch, put it at the bottom under "My guess, might be wrong".
Do not write "urgent" with nothing behind it. Say who is blocked and since when. "Acme Ltd cannot check out since 09:00" moves faster than the word urgent.
Do not send five separate messages. One ticket beats a chat thread that scrolls away. Add new findings as comments on the same ticket.
Do not put three bugs in one ticket. They get fixed at different speeds by different people, so two of the three get forgotten. One bug, one ticket.
Do not apologise for not being technical. Clear observation is the skill that matters here, and you already have it.
A template you can copy
Paste this into your ticket and fill in the blanks. Delete any line you cannot answer.
Title: [What broke] on [page] when [action]
What I was trying to do:
[One sentence]
Page address:
[Paste the full URL here]
Steps:
1.
2.
3.
Expected:
[What should have happened]
Actual:
[What happened, with the exact message text in quotes]
How often:
[Every time / 2 out of 5 tries / Once]
Other browser check:
[Also happens in ___ / Works fine in ___ / Not checked]
Environment:
Browser: [Chrome 126.0.6478.127]
Device: [MacBook Air, macOS 15.4]
Account: [[email protected]]
Date and time: [29 July 2026, 14:20 UK time]
Attached:
[Screenshot or recording]
Keep it in a note on your desktop. After three or four reports you will fill it in without thinking about it.
Frequently asked questions
Do I need to know how to code to report a bug? No. You need to describe what you did and what you saw. Coding is the developer's part of the job, and diagnosis is theirs too.
What if the developer cannot reproduce it? That is normal and not a failure. Send your exact browser version, the account you used, and the time it happened. Small differences in setup explain most of these cases.
Should I report something that might be my own mistake? Yes. If a smart person using the product got confused, that is useful information. A quick "this may be my error" line at the top is enough.
How much detail is too much? Extra environment details cost nothing. Long stories do. Keep your steps to short numbered lines and put everything else in the fields where it belongs.
What if I cannot take a screenshot? Describe the screen in order: what is at the top, what the message says word for word, and what is missing. Written detail is far better than no report.
Add to Chrome