What to Do With a Bug Report You Cannot Act On

Most advice about bug reports is addressed to the person writing one. This is about the other side of it: a report has arrived, it is almost certainly describing something real, and there is not enough in it to do anything with.

You have three honest options, and the one most teams reach for is the worst of them.

The three options

Close it. Fast, and occasionally right. It is right when the report is a duplicate, when it describes intended behaviour, or when it is so vague that no question you could ask would change that.

Ask for more. The default, and the one that quietly costs the most. Every question is a round trip measured in days, and each one spends a little of the reporter’s willingness to tell you anything next time.

Answer it yourself. Go and find the missing information without involving the reporter: in logs, in error tracking, in whatever you can reproduce from the fragment you were given. Slower for you today. Usually the only one that ends.

The reason the middle option is treated as free is that its cost is paid by somebody else, later, and never shows up beside the ticket.

Before you ask, work out what the answer would change

This is the whole discipline, and it takes thirty seconds.

For each question you are about to ask, finish the sentence: “if they say X, I will …” If you cannot finish it, the question is decoration and you are asking it because the form has a field.

Weak

"Can you tell us your browser, OS, screen size, what you were doing, and whether it happens every time?"

Better

"Does it still happen in a private window? If yes I will look at the server; if no it is a cached build and I will ship a cache-busting fix today."

The second one asks for a single bit and both answers lead somewhere. The first is a form, and a form gets answered when somebody has time, which is not today.

Ask one question, not five. Five questions in one message reliably returns two answers, and you cannot tell which three were ignored because they were unclear, irrelevant, or simply the fourth thing in a long paragraph.

What to do while you wait, which is most of the work

The report is a fragment, but it is rarely nothing. There is usually more in it than it looks.

A timestamp is a key into everything you already collect. Even “yesterday afternoon” narrows your logs to a few hours, and if the person is named in your system you can find their requests inside that window. Half the time the failing request is sitting there with its status code, and you never needed to ask anything.

A screenshot carries more than the screenshot. The URL is in the address bar, the window size is implied by the layout, and the browser chrome usually gives away the browser and the operating system. People send one thinking they have sent you a picture of a broken button.

The phrasing tells you which surface they were on. “The app” and “the site” and “the page” are not synonyms in most products, and somebody saying “it logged me out” has told you the failure had a session in it.

“It worked last week” is a bisect. If it is true, whatever changed is in a known window, and your deploy history is a list of suspects ordered by time.

If you exhaust all of that and are still stuck, you have earned the right to ask a question, and you now know exactly which one.

Closing one without lying about it

Sometimes the answer really is no. There is a way to do it that keeps the reporter and a way that loses them.

The version that loses them is “cannot reproduce”, with nothing else. It reads as “I do not believe you”, because from where they are sitting that is what it says: they watched it happen.

The version that keeps them says what you did, what you found, and what would change the answer. “Checked the logs for Tuesday afternoon and found no failed requests for your account, and it works on Chrome 141 and Safari here. Reopening this the moment it happens again is genuinely useful, and the browser’s console text would settle it.” That is the same decision, and it leaves somebody willing to tell you next time.

That matters more than any individual ticket, because the people who report bugs to you are a small and entirely voluntary group, and each unanswered or dismissively closed report removes one of them. A quiet tracker is not the same as a working product, and by the time you cannot tell those apart it is too late to ask.

What to take from it

An unactionable report is a fragment, not a failure, and the work is deciding whether the missing piece costs less to find than to request.

Ask one question with a consequence attached, or none. Mine the fragment first, because the timestamp and the screenshot usually carry more than the sentence does. And when you do close one unsolved, close it in a way that makes the next report more likely rather than less, since the supply of people willing to write them is the thing you are actually managing.