The details that help most are the affected domain, exact error text, relevant DNS records, and traceroute or MTR results with timestamps. Those four items let support separate a DNS fault from a routing problem or a server failure.
DNS, the Domain Name System, maps domain names to server addresses. Vague tickets like "site is down" force extra back-and-forth and slow fixes for stores, blogs, and client sites. A short, complete report with domain, location, and test output lets the technician reproduce the issue and act faster.
Table of Contents
- What should every ticket include first?
- Which DNS details actually resolve issues?
- How do you document a connection failure?
- What site details help WordPress and Drupal checks?
- What should you leave out for faster replies?
- Frequently Asked Questions
What should every ticket include first?
Start with identifiers support can search and reproduce. Give the full domain, exact URL, time with time zone, and where you tested from.
These five lines cover most triage: Exact text beats paraphrase because many failures look alike. "Error establishing database connection" points to the database, while "ERR_NAME_NOT_RESOLVED" points to DNS.
- Affected domain and full page URL, including http or https and www or non-www.
- Date, time, and time zone when the problem occurred.
- Your location, network, and ISP, plus whether others see the same issue.
- Exact error text or screenshot, and browser or tool used.
- Hosting account or ticket reference if you have more than one site.
Which DNS details actually resolve issues?
Paste the current authoritative records, not just what you intended to set. Include nameservers, A and AAAA records, CNAMEs for www, and MX and TXT records if mail is affected. Copy them from a public lookup tool and name the tool and location you used. Note any recent change, with old and new values and the time you made it.
Add the TTL for each changed record. TTL, or time to live, tells resolvers how long to keep the old answer in cache. Cached records explain why an edit works in one city and fails in another. Tell support where you tested and whether the old address still appears. That detail keeps the ticket focused on propagation rather than a server fault.
How do you document a connection failure?
Run simple network tests from the failing location and paste full text output. Use ping for basic reachability, traceroute or MTR for the path, and curl -v for HTTP response details. MTR combines ping and traceroute and shows packet loss at each hop. Include the source IP, destination host, test time, and 50 to 100 MTR packets when possible.
Do not trim the middle hops because the pattern of loss matters. Add whether you used home broadband, mobile data, office network, or VPN. A single failed ping does not prove the server is down. Many hosts block ping while the website still works, and VPNs can hide a local routing fault. Full MTR and curl output prevents that misreading.
What site details help WordPress and Drupal checks?
Name the platform and version, such as WordPress or Drupal, plus theme and key plugins. List recent changes like updates, migrations, DNS moves, or new firewall rules. Mention cache layers such as a plugin cache, CDN, or host cache. For HTTPS or redirect faults, give the exact URL chain and certificate warning.
Mixed content means a secure page loads an insecure file, which browsers may block. Marketing pages suffer fast because broken forms and tracking tags waste ad clicks. Add relevant log lines or status codes, such as 500, 502, 503, or 525, with timestamps. State whether the admin login area also fails. That tells support whether only public pages or the whole application is affected.
What should you leave out for faster replies?
Keep the ticket to one domain and one symptom. Long threads with several sites force support to guess which failure matters now. Trim logs to the minutes around the incident and highlight the matching lines.
Never paste full passwords or private keys in plain ticket text. Use the host's secure credential field or reset access after the fix. Close the ticket by stating what you need: DNS correction, routing check, or server fix.
Frequently Asked Questions
Do I need to include my public IP address?
Yes. It lets support check blocks, allowlists, and firewall hits tied to your address.
What if the site works on mobile data but not office Wi-Fi?
Send tests from both networks with timestamps. That contrast often points to office DNS or filtering rather than hosting.
Should I send a WordPress or Drupal admin login in the first message?
No. Describe the failure first, then create a temporary admin user only if support asks for one.
