An exact error message is often more useful than a broad description such as “not working.” It can identify the operation that failed and preserve a code the maintainer recognizes. Record it before dismissing the dialog or changing several settings.
Keep the context with the message. The same short wording can appear during sign-in, guide retrieval or programme opening. Without the action and application identity, the recipient may investigate the wrong layer.

Capture the observation faithfully
Write the message exactly or keep a focused screenshot. Do not improve its grammar or substitute a remembered explanation. If the text is truncated, note that limitation rather than inventing the missing portion.
Review the screenshot or log for secrets. An error can repeat a private URL, account name or token. Redact a copy while preserving the non-secret code and relevant sequence. A masked password field elsewhere on the screen does not make the whole image safe.
Build a small error record
Do not infer account expiry from generic rejection wording alone. A configuration mismatch, unexpected response or another condition can produce a similar symptom. Keep explanations as hypotheses until the evidence identifies the cause.
- Name the genuine player and installed version.
- State the specific action immediately before the error.
- Preserve the exact non-secret wording or code.
- Record the full date and relevant time context where needed.
- Note the result of one controlled retry or relevant check without multiplying changes.
Make the report reproducible
Describe the starting state sufficiently for the task: active source, profile or content type where relevant. A maintainer should know whether the error affects one entry or the whole catalogue. That scope information can be more useful than several additional screenshots.
If the issue no longer occurs, say so and preserve the earlier observation as historical. Do not present a past error as a current live failure. Likewise, a single successful retry does not establish that an intermittent issue is permanently resolved.
A useful error record lets the next person understand what happened without receiving the entire account export. It supports a focused investigation and avoids turning an ambiguous message into a confident claim about service downtime, device incompatibility or account status that the message alone cannot establish.
Useful answers
Should error text be paraphrased from memory?
Preserve the exact wording where possible and state any uncertainty.
Can an error screenshot contain account secrets?
Yes. Review URLs and surrounding fields before sharing.
Does one successful retry prove a permanent fix?
No. It is one observed result.