Recommended resources
The freely available resources this lesson will direct you to.
Hello again. Last time, you compared the same export across two authorized accounts while keeping the other conditions steady. That test could reveal an account-related pattern, but the result is only useful to others if you preserve the right evidence—without carrying a customer’s secrets or personal information into a ticket.
In this lesson, you’ll learn to choose evidence that answers a specific troubleshooting question, then check what is safe to share. Allow about 35–40 minutes, including the readings and a worked support case.
Start with the question, not the attachment
Suppose a customer says that Weekly usage, Last 30 days displays “Export failed.” Asking immediately for a screen recording, complete browser log, and HAR file might produce plenty of material, but most of it may be irrelevant. It may also expose information the investigation never needed.
Instead, identify the uncertainty you are trying to reduce. Is the error visible only in one browser? Does the export request receive an HTTP error? Does it fail only for one account? Each question suggests different evidence. Often, the smallest useful starting set is the time and time zone, the conditions used, the exact error text, and the outcome of each attempt. A request identifier or HTTP status can be added if available and relevant.
Cloudflare Support’s guide is useful here because it matches kinds of web issues to diagnostic tools. You do not need to learn how to operate every tool in its list today; focus on why you would choose one.
Gathering information for troubleshooting sites · Cloudflare Support docs
Read Cloudflare Support’s guide to see how the symptom determines the evidence worth collecting—and why a full browser capture contains more than a simple error note.
Near the top of the page, before “Browser-based troubleshooting,” read the tool table. Compare its recommendations for a page-loading issue, a JavaScript error, and an HTTP error. Then, under “Browser-based troubleshooting,” read the introductory paragraph of “Generate a HAR file,” from what a HAR records. Skip the browser-specific export steps for now. Finally, under “Export Console Log,” read when console output helps. We’ll practice browser capture and HAR handling in a later module.
A useful rule is collect enough to distinguish between plausible explanations, but no more than the question requires. For example:
| Question | Useful starting evidence | Why not collect everything? |
|---|---|---|
| Did the export fail consistently in the controlled comparison? | Attempt times, account aliases, report and range, browser, observed outcome | A screenshot of every page may add no answer. |
| Did a particular web request fail? | Relevant request’s time, method, path, status, and an approved request ID, if present | A complete URL or body may contain customer data or credentials. |
| Did the page fail before making the expected request? | Relevant console error text, with sensitive values removed | A HAR may not explain a browser-side error on its own. |
An account alias here means a label such as “account A” used consistently in the investigation note. It lets a colleague understand the comparison without automatically copying a customer’s name or identifying account details into every attachment. Your organization may have an approved way to link that alias to the real account in a restricted system.
Useful detail and sensitive detail can sit side by side
An error message, timestamp, and result status can help an engineer locate a failed operation. The same log line or browser request can also contain a password, a session cookie, a token, or a person’s email address. Being present in a diagnostic tool does not make a value appropriate for a support ticket.
OWASP’s logging guidance distinguishes useful event attributes from information that generally should not be recorded directly. Although it discusses application logs, its data-minimization principle also helps when selecting excerpts for support records.
Logging - OWASP Cheat Sheet Series
Read OWASP’s “Event attributes” and “Data to exclude” sections to develop two filters: what helps reconstruct an event, and what should not be copied into an investigation record.
In “Event attributes,” start at the event details. Focus on the “when, where, who and what” framework, particularly timestamps, application context, action, result, and status. You do not need every listed attribute in every support case. Then find “Data to exclude.” Read the exclusion guidance, including its discussion of names, phone numbers, and email addresses. Notice that an identifier can aid investigation while still requiring careful handling.
For day-to-day support work, apply a strict boundary:
- Do not request or copy passwords, API keys, bearer tokens, session IDs, or cookie values into a ticket or escalation. A token can grant access even when it looks like an opaque string rather than a recognizable password.
- Exclude personally identifiable information (PII) unless an approved process specifically requires it. Names, email addresses, phone numbers, and customer records may appear in screenshots, URLs, request bodies, exports, and error messages.
- Evaluate identifiers rather than assuming they are harmless. A request ID may be useful for finding server-side events, but share it only through channels your organization permits. A customer account ID may also be identifying information.
- Preserve diagnostic meaning. “Request failed at 10:08 UTC with status 500” is useful; replacing the status and time with “[redacted]” would defeat the purpose. Remove sensitive values, not the entire explanation.
The boundary matters particularly for HAR files. Cloudflare’s guide explains that a HAR can contain request and response headers and bodies—not just timings. A private browsing window may reduce unrelated browser activity, but it does not sanitize a captured request. Its cookies, authorization headers, URL parameters, or body can still be sensitive.
Work through the export case
Return to the controlled comparison. Imagine your notes say that account A’s thirty-day export failed at 10:04, an authorized account B’s succeeded at 10:06, and account A’s failed again at 10:08. All three attempts used the same browser, report, range, and environment. The UI displayed “Export failed” on the unsuccessful attempts.
Before gathering anything else, ask what this already establishes. The sequence supports an account-related pattern at that time. It does not identify a faulty database row, an access-control problem, or a particular API failure. A concise record of the three outcomes may therefore be more valuable initially than a large attachment.
Now suppose you can inspect the specific request associated with the final failed attempt. If it returned an HTTP 500, the status and time would be useful additional evidence; if it exposed an approved request ID, that might help an engineer find the matching server event. Those are hypothetical new observations, not facts established by the earlier comparison. Check them before adding them to a real ticket.
A suitably minimized excerpt could read:
Issue: Weekly usage, Last 30 days; production; Safari 17 on macOS 14.
Comparison: account A failed at 10:04 UTC; authorized account B
succeeded at 10:06 UTC; account A failed again at 10:08 UTC.
UI on failures: "Export failed".
Additional request evidence, if verified: export request at 10:08 UTC
returned HTTP 500; approved request ID recorded in the restricted case.
Not included: credentials, cookies, full URLs, request/response bodies,
customer names, email addresses, or exported report data.
The time zone is explicit so someone else can look in the right period. The note also distinguishes an observed outcome from a possible additional observation. Do not invent an HTTP status because one would be helpful, and do not infer that a 500 proves the cause of the account difference.
Sometimes the missing detail really does matter. If engineering needs to know whether the report’s date range affects the failure, record the selected dates. If they need to examine a particular customer record, use your organization’s approved restricted workflow rather than pasting that record into a broadly visible ticket. Escalate the need for sensitive evidence; do not solve it by casually widening distribution.
Check the evidence before it leaves your workspace
Think of every attachment or pasted excerpt as something that will be read by another person—and perhaps retained or forwarded. Before sharing it, make a final pass:
- Confirm relevance. Can you state which troubleshooting question each item answers? Keep the relevant error and its surrounding context; omit unrelated browsing activity, customer records, and repeated captures.
- Inspect every surface. In a screenshot, check visible tabs, names, notifications, and the address bar. In text or structured files, check URLs and query parameters, headers, cookies, request and response bodies, and error messages. A shortened-looking URL can still contain a token.
- Remove sensitive values without hiding the result. Keep the HTTP status or error category when useful. Replace an unnecessary personal value with a clear label such as
[email removed]; do not substitute a real person’s details with another real person’s details. - Verify the version you will actually share. Reopen the sanitized file or review the final pasted text. Do not attach the original alongside it or assume that a preview of a screenshot or HAR showed every field.
- Use the approved channel and access level. Follow your company’s rules for storing and retaining diagnostic material. If you cannot safely remove a value that engineering genuinely requires, pause and use the designated secure process.
This check applies even when a customer supplied the file voluntarily. Their willingness to send a capture does not mean every credential or other person’s data inside it should be copied into Jira, Freshdesk, chat, or an escalation.
Key takeaways
Choose evidence by the question it can answer: a controlled-test outcome, exact error, relevant timestamp, status, or approved request identifier may be enough. Treat full logs, screenshots, and HAR files as potentially sensitive until you have inspected and minimized them. Keep diagnostic facts; exclude passwords, tokens, cookie values, and unnecessary personal information.
In the next lesson, you’ll use those carefully selected facts to document an investigation so another engineer can reproduce the issue and pick up from the next logical step.