When a website breaks, "It isn't working" tells a support provider that something is wrong but gives them no safe place to begin. You do not need to diagnose the technical cause before asking for help. You do need to preserve the conditions that make the problem visible.
A useful incident evidence packet is short, factual, and reproducible. It shows what happened, who is affected, when it happened, what changed, and what has already been tried without exposing credentials or rewriting the evidence through guesswork.
State the business impact first
Begin with the affected outcome. Can visitors still view the site? Are leads failing to arrive? Is checkout unavailable? Are editors blocked? Is the issue cosmetic, intermittent, or security-sensitive?
This helps the responder prioritize correctly. A misspelled heading and a payment failure can both be called "a website problem," but they require different urgency, authority, and recovery decisions. If personal, payment, or account data may be exposed, stop casual testing and escalate through the site's incident process.
Capture a precise timeline
Record:
- the first known occurrence and timezone;
- the most recent successful use, if known;
- whether the problem is continuous or intermittent;
- exact times of your controlled tests;
- recent WordPress, plugin, theme, hosting, DNS, email, analytics, or content changes.
Do not rewrite "we noticed it Tuesday" as "it began Tuesday." The failure may have started earlier. Separate what you observed from what you infer. That distinction lets logs and change records be matched to the right window.
Give the shortest reliable reproduction path
List the page URL, device, browser, login condition, and exact steps that produce the problem. Include the expected result and the observed result. If only one account, product, form option, or page is affected, say so.
For a quiet contact form, use the contact-form proof chain to report whether the visitor confirmation, stored entry, notification, and human handoff succeeded. That is far more useful than reporting only that "the email never came."
Preserve safe evidence
Useful evidence may include a screenshot of the visible error, an exact error message, a request or order ID, a sanitized console message, a supported status export, and relevant log lines from the recorded window. Keep originals when possible and note the source of each item.
Remove or obscure passwords, application keys, session cookies, authorization headers, personal customer details, payment data, and private server paths before sending evidence outside the authorized team. Do not paste an entire configuration file or database export into a support ticket merely because it might contain a clue.
If deeper WordPress debugging is needed, the official debugging guidance explains how errors can be logged while display to visitors remains disabled. Configuration changes should be made only by an authorized person with staging or recovery protection, and debug output should not be left publicly exposed.
List what has already been tried
Write down cache clears, browser tests, restarts, updates, deactivations, DNS changes, or other actions already taken, including their time and result. "We tried everything" hides the evidence and invites the next person to repeat risky steps.
Avoid making new broad changes just to make the packet look complete. If you do not have authority or a rollback path, preserve the state and say that the suspected test was intentionally deferred.
Include access and recovery boundaries
Tell the responder which systems can be inspected through the approved path, who can authorize changes, and what backup or rollback evidence exists. Do not send credentials inside the incident packet. Share access through the site's approved credential process after the exact need is established.
The site's ownership map should identify the responsible host, domain, DNS, email, and WordPress accounts without becoming a password list.
Use a one-page incident summary
Your packet can begin with:
- Business impact and urgency
- Affected URL or workflow
- First observed and last known good time
- Reproduction steps
- Expected and observed results
- Recent relevant changes
- Evidence attached and sanitized
- Actions already tried
- Approved access and authority boundary
- Recovery state and immediate question
The packet is not supposed to prove the cause. It is supposed to let someone investigate the right system without destroying the clues or spending the first hour reconstructing the report. If you need technical help, contact TechDex with that summary and keep secret material in the approved access channel.