Collecting the right evidence before opening a ticket

A ticket gets solved on the first reply when it carries your observations, and drags on when it carries your theory. Five things do almost all the work: what you saw, when you saw it, the exact address involved, what you already tested, and whether it happens again on demand. Writing those takes two minutes. Leaving one out reliably costs a full exchange.

The arithmetic of a vague report

Support runs in round trips. Every detail missing from your first message becomes a question, and every question is another turn before anyone starts looking. Omit the timestamp, the URL and the reproduction state and you have not lost a few minutes, you have spent three exchanges, with your ticket idle in the gaps while you are away from your desk.

Evidence also decays. Logs rotate, caches expire, a transient routing fault leaves nothing behind once it clears. By the time someone asks for the exact minute, the line that explained it may have aged out. The best evidence you will ever hold is the evidence you had at the moment you noticed.

What to include

• The observation, not the diagnosis. "Checkout returned a blank 500 on three of four attempts" is workable. "Your PHP workers are exhausted" is a guess that narrows the search before it starts, and a wrong guess sends the first hour the wrong way. Give your theory if you have one, but after the facts and labelled as a theory.
• The time, with an offset. 2026-07-28 14:05 UTC+3 is searchable. "Yesterday afternoon" is several thousand log lines.
• The exact address. Full URL including scheme and path, or the precise mailbox, or the IP if your account holds several. On an estate of similar sites, "my site is down" identifies nothing.
• What you ruled out. Second browser, second device, mobile data instead of the office connection, a check from another country, cache cleared, no recent deployment.
• Whether it reproduces. Every time, intermittently at some rough frequency, or once and never since. Each state sends the investigation down a different path.

Paste error text as text rather than describing it, and include any reference string the error page prints. For mail faults, the full bounce with its headers is worth more than the rest of the ticket.

What to leave out

• Several unrelated problems in one message. Each blocks the others from closing.
• Urgency adjectives in place of impact. "The store cannot take orders" is information; capitals are not.
• A cropped screenshot that hides the address bar. Send the whole window.
• Backstory about a previous provider, unless it explains configuration still in place.

Never put a password or a key in a ticket

Ticket text is stored, quoted into replies, forwarded between people, mirrored into email that crosses networks in the clear, and readable long after the fault is forgotten. Never paste account or mail passwords, database credentials, API tokens, SSH private keys, TLS private keys, recovery codes or card numbers. Strip them from configuration files and log excerpts before attaching anything: wp-config.php, .env files and connection strings all carry live secrets in plain sight.

If access is genuinely needed, wait to be asked, use the route you are offered, and change the credential afterwards. If you have already pasted a secret anywhere, treat it as disclosed and rotate it now. Deleting the message is not a remedy.

Weak report, rewritten

Weak:
Site is down again, please fix ASAP. Same as last time I think.

Strong:
Subject: HTTP 500 on checkout only, example.com, from 14:05 UTC+3

Observed: https://example.com/checkout returns a blank page reading
"HTTP ERROR 500" on about 3 of 4 loads. Every other page is normal.
When: 2026-07-28, first seen 14:05 UTC+3, still failing at 14:30.
Ruled out: same in Firefox and Chrome, on mobile data, and from a
second country. Cache cleared. No plugin, theme or code change in
the last 8 days.
Reproducible: yes, refresh a few times and it appears.
Impact: no orders can be completed.

The weak version is not lazy, it is written from inside your own head where the context is obvious. The strong one costs three minutes and hands over a problem someone can pick up cold.

A short check before you send

1. Could a competent stranger reach the screen you saw, using only this message?
2. Is every identifier exact rather than approximate?
3. Have you re-read the message, attachments included, for anything secret?
4. Is this one problem, or should it be two tickets?

The rest of the diagnostics section covers the checks worth running before you write at all, so what you send is already narrowed. When you are ready, open the ticket through our contact page with those five points at the top.