An Error Report Is A Data Collection Decision

Attaching a screenshot to every error report is a data collection decision, not a debugging tweak. It will make bugs dramatically easier to reproduce, and I think it is usually worth doing. But the moment a picture of the screen travels with the stack trace, your error pipeline stops being a technical log and becomes a copy of whatever your user was looking at. If you do not tell people that, you have changed the deal without asking.

Why it is tempting

A stack trace tells you where code failed. It rarely tells you what the person was trying to do, what state the screen was in, or whether a dialog was sitting on top of everything. UI bugs are the worst for this. Someone says "it went wrong", the report says a null reference happened somewhere in a page, and you spend an hour trying to recreate a state you cannot see.

A screenshot collapses that hour. You see the half-finished form, the odd layout, the error dialog the user dismissed before they told anyone. For a small team trying to ship quickly, that is a real saving, and engineering time has a cost. I would not argue against it on principle.

What it actually collects

The trouble is that a screenshot is the least selective thing you can capture. Most of the care teams put into error reporting is about stripping things out: scrubbing fields, dropping text from breadcrumbs, de-duplicating noise. Those filters work on structured data because you know where the sensitive parts live. A picture has no structure. It contains whatever was rendered, and that is exactly the content the earlier filters were designed to keep out.

If the product handles anything personal, such as notes, goals, conversations or health-adjacent information, then the screens where people write about their own lives are among the most likely places for an error to occur. They are long-lived, interactive and complicated. An error report taken there will contain what the person had just typed.

There is also a quieter assumption worth testing. Many apps protect sensitive screens from the operating system's screenshot feature, or blur them in the app switcher. It is natural to assume that covers this too. In my experience it often does not. Protections aimed at the system capturing the screen from outside are frequently irrelevant to code that draws the screen from inside the app. Those screens may be precisely the ones that show up in reports. I would treat "probably not covered" as "covered until proven otherwise", and say so plainly rather than hope.

Change the promise in the same change

The part I care most about is the order of operations. A privacy policy is not paperwork that trails the code. It is the statement of what you do with what people trust you to hold. If the code starts sending screen images, the wording has to say so in the same release: that error reports include a screenshot, that the screenshot is not filtered, and that it can therefore show whatever was on screen.

That last clause is the uncomfortable one, and it is also the honest one. "We scrub personal data from error reports" is a sentence that quietly stops being true the day a screenshot is attached. A vague version of the policy is worse than a blunt one, because it lets the team believe a protection exists that does not.

It is worth deciding deliberately whether the change counts as material for your users. Reasonable people can land on different sides, depending on the product and the jurisdictions involved. The point is that someone decided, with the facts in front of them, rather than discovering later that nobody had.

Make the capture earn its place

Once you accept it is a collection decision, a few design habits follow. Capture only for genuine errors, not every event. Do the capture at the last responsible moment, after filtering, scrubbing and de-duplication, so you are not drawing pictures for reports that would have been dropped anyway. Put a time limit on the capture, and if it fails or is slow, send the report without the picture. A debugging aid that can block the report it exists to support has the priorities upside down.

It is also worth asking who will look at these images and for how long they are kept. A screenshot sitting in a tool that half the company can open is a different thing from one visible to two people for a few weeks. Access and retention are part of the decision, and they are far cheaper to set before the first image arrives than after the thousandth.

Say what you have not seen

One more habit I have come to value: write down what you have not verified. Local testing of a change like this tends to prove the capture works and the report still goes out when the capture fails. It usually cannot prove that the first real report arrives with a sensible picture in the real destination, because local builds often have nowhere to send anything. Saying "check the first reports after deploy" in the change description turns an assumption into a task.

Taken together, none of this is a reason to avoid screenshots. It is a reason to treat them with the seriousness of any other thing you ask users to hand over. People forgive software for breaking. They are much less forgiving when they learn it was watching more than they were told, and the cost of telling them is a few sentences in a policy and a bit of care in the pipeline.