Client errors must report themselves

What it is

Most failures never become a ticket. People retry, leave, or assume it was them. Automatic client error reporting sends those unspoken failures where the product can see them; otherwise the recovery system only improves the talkative few. This entry is only about sending automatically. It is not about whether the payload includes a reproduction path, how rate alarms work, or how content is redacted.

Why it happens

Feedback has a cost: describe it, find the entry, admit something went wrong. When that cost is higher than retrying on the spot, the product’s count of the failure is zero. Automatic reporting changes the count from voluntary to “it happened, so it is recorded,” so diagnosis tracks the real distribution rather than the chatty-user distribution. The report fires when an error surface appears or an unhandled exception is caught; it does not wait for “tell the developers.” An opt-out can exist; default off is a choice not to see. Without this pipe, prevention and copy changes orbit tickets, and tickets are not a sample.

Studying it

Compare tickets-only, automatic reporting, and reporting plus an optional note, and count distinct failure kinds in the same window.

Independent variables: whether send is automatic, whether it is on by default, whether a note is optional. Dependent variables: count of distinct error kinds, overlap with tickets, share of failures that never appear in tickets.

Do not use lab participants who were told “please report problems” as the main sample. What matters is how many failures are recorded when no one is asked.

Where it stops holding

When the user has opted out of diagnostics, or the jurisdiction requires opt-in, it cannot be turned on quietly. Enterprise devices may force on or off by policy; the app obeys and says so on an about page. Logging only in development builds, production off, still leaves production failures invisible. Sensitive sessions (banking, clinical) should still report, but payloads follow redaction; do not kill the whole pipe because the scene is sensitive.

Applying it

• Send an event when an error is shown or an uncaught exception fires; do not require an extra button.
• Diagnostics on by default, with opt-out in settings; after opt-out the person can still see their own local failure log.
• Read report volume next to ticket volume: kinds that appear only in reports enter the fix queue without waiting for a complaint.
• Verify by creating a failure that never asks “please send feedback,” and checking that a remote event appears in the agreed time. No event means automatic reporting is not on this user path.

Related

• Within the group: H3.14.2 Reports need the path, not only the stack · H3.14.3 A spike in reports is itself an alarm · H3.14.4 User content in reports has to be redacted
• Adjacent: H3.02 Three elements of error messages · A10.16 Incident investigation and error reports · Q3.08 Error rate and help-seeking rate
• Search terms: crash reporting · client telemetry · unreported error