What Information Should You Include in a Hosting Support Ticket?

Your website is down, your domain won't connect, or something broke after an update — and now you need help. You open a support ticket, type "my website is not working," hit send… and wait. Hours later, the reply comes back: "Can you please provide your domain name and the exact error message you're seeing?"

That round trip was avoidable. Support teams fix well-written tickets dramatically faster than vague ones, because the technician can start diagnosing immediately instead of playing twenty questions. This guide shows you exactly what to include — with a copy-paste template — so your first message is the one that gets the fix.

Why the Details Matter: Good Tickets Get Fixed Faster

What happens when you write "my website is broken"

Put yourself in the support technician's shoes. They handle dozens of tickets a day covering hundreds of possible problems: DNS, SSL, server errors, hacked sites, billing, email. A ticket that says "it's not working" gives them zero starting points. They must reply asking for the domain, the error, and when it started — and every back-and-forth adds hours (sometimes a full day) to your resolution time.

The two-exchange rule — answer before they ask

Aim for this: your ticket should contain everything the technician would ask for in their first reply. Domain name, error message, when it started, what you changed, what you tried. When the first response is a diagnosis instead of a question, you've cut your wait time in half.

The 8 Things Every Good Ticket Includes

1. Your domain name and account identifier

Always state the affected domain — e.g. example.com. If you manage multiple domains, this is non-negotiable; support can't guess which one you mean. Include your account username or the email on the account (not the password) so they can locate your services quickly.

Example: "Domain: example.com — Account email: me@example.com"

2. A clear subject line that describes the problem

The subject is the first thing support sees. Make it specific:

A good subject often gets your ticket routed to the right specialist immediately.

3. When the problem started (and what changed)

Timing is a diagnostic goldmine. "It broke at 2 PM today, right after I updated WordPress" tells the technician exactly where to look. Always include:

• When it started (date and approximate time, with your timezone)
• What changed just before — a plugin update, a DNS edit, a new theme, a migration
• Whether it ever worked — "it worked fine until yesterday" vs "it's never worked" point to completely different causes

4. The exact error message — copy it, don't paraphrase

Error messages are precise for a reason. "Something about a database error" could be ten different problems; Error establishing a database connection is one. Copy the full text of the error, including error codes (500, 403, ERR_CONNECTION_TIMED_OUT). If the message appears in the browser, copy it from the page; if it's in an email or log, paste the relevant lines.

5. Steps to reproduce (or what you were doing)

Tell them how to see the problem themselves:

1. Go to https://example.com/wp-admin
2. Log in
3. Click "Plugins" → white screen appears

Numbered steps are ideal. If the problem is intermittent ("sometimes the site loads, sometimes it doesn't"), say so — and note any pattern you've spotted (only on mobile, only in the evening).

6. What you've already tried

List what you did before contacting support: cleared cache, tried a different browser, disabled plugins, checked DNS propagation. This does two things: it stops the technician from suggesting things you've done, and it shows them what's been ruled out — which narrows the search.

7. Screenshots that show the problem

A screenshot of the error is worth a paragraph of description. Capture:

• The full browser window (URL bar visible — it proves which page and whether it's HTTP or HTTPS)
• The exact error on screen
• For email/DNS issues, the relevant settings page

Most ticket systems let you attach images. Keep them focused: one or two clear screenshots beat ten blurry ones. Redact anything sensitive before attaching (see the security section below).

8. Your environment (browser, device, location if relevant)

Some problems only happen in specific conditions. Include:

• Browser and version (e.g. Chrome 131 on Windows 11)
• Device if mobile is involved
• Location/network if relevant ("works on my home WiFi but not on mobile data" points to a network or DNS issue, not a server problem)

Copy-Paste Support Ticket Template

Here's a template you can reuse. Fill in the brackets and send.

``` SUBJECT: [Your domain] — [short problem description]

Domain: [example.com] Account email: [you@example.com]

PROBLEM: [One or two sentences describing what's wrong.]

STARTED: [Date and time, e.g. "Today, 16 Oct 2026, around 2:30 PM PKT"]

WHAT CHANGED BEFORE IT BROKE: [Plugin update / DNS change / nothing — be honest]

EXACT ERROR MESSAGE: [Paste the full error text or code here]

STEPS TO REPRODUCE:

1. [Step one]
2. [Step two]
3. [What happens]

WHAT I'VE TRIED:

• [Cleared browser cache — no change]
• [Tried different browser — same error]
• [Checked on mobile data — same error]

SCREENSHOTS: [attached] ```

Filled example: website-down ticket

``` SUBJECT: example.com — 500 error on all pages since this morning

Domain: example.com Account email: me@example.com

PROBLEM: Every page on the site shows "500 Internal Server Error", including wp-admin.

STARTED: Today, 16 Oct 2026, around 9:00 AM PKT. The site was fine last night.

WHAT CHANGED BEFORE IT BROKE: I updated three WordPress plugins last night around 11 PM.

EXACT ERROR MESSAGE: 500 Internal Server Error (on a plain white page, no other text)

STEPS TO REPRODUCE:

1. Open https://example.com — 500 error
2. Open https://example.com/wp-admin — 500 error

WHAT I'VE TRIED:

• Cleared browser cache — no change
• Tried Firefox and Chrome — same error
• Checked on mobile data — same error

SCREENSHOTS: [attached — full browser window showing the error] ```

Filled example: domain/DNS ticket

``` SUBJECT: example.com — nameserver change not working after 30 hours

Domain: example.com Account email: me@example.com

PROBLEM: I changed nameservers 30 hours ago but the site still shows the old host's parking page.

STARTED: Nameservers changed on 15 Oct 2026, around 10:00 AM PKT.

WHAT CHANGED BEFORE IT BROKE: Changed nameservers from [old host] to [new host] in the domain panel.

EXACT ERROR / CURRENT STATE: WhatsMyDNS shows the new nameservers in most locations, but my ISP still resolves the old ones.

STEPS TO REPRODUCE:

1. Open https://example.com on home WiFi — old parking page
2. Open on mobile data — new site loads correctly

WHAT I'VE TRIED:

• Flushed local DNS (ipconfig /flushdns) — no change
• Checked WhatsMyDNS — mixed results by location

SCREENSHOTS: [attached — WhatsMyDNS results] ```

What NOT to Include (Security Matters)

Good tickets are detailed — but never at the cost of your security.

Never send passwords — use reset links instead

Support technicians should never need your account password, your WordPress admin password, or your email password. Legitimate support will never ask for them either — if someone claiming to be support asks for your password, that's a red flag. If access is genuinely needed, reputable hosts have secure ways to grant it (temporary access links, support PINs) that don't involve you pasting a password into a ticket.

Don't share full credit card numbers

For billing issues, the last four digits are enough to identify a payment. Never paste a full card number, CVV, or expiry date into a ticket or chat.

Trim logs: show the error, not your whole file

Error logs can be long. Paste the relevant section — the lines around the timestamp when the problem occurred — not a 5,000-line dump. Long pastes bury the signal. If support needs the full log, they'll ask.

Also redact before you attach: blur or crop out API keys, tokens, personal email addresses, or anything you wouldn't post publicly. Screenshots live in ticket systems for a long time.

After You Submit: How to Follow Up Well

One ticket per issue — don't open duplicates

Opening three tickets about the same problem doesn't make it faster — it splits the conversation across technicians and slows everything down. One issue, one ticket.

Reply in the same thread, add new information

When support asks a follow-up question, reply in the same ticket thread so the full history stays together. If something changed since you wrote ("the error is different now — here's the new message"), say so clearly rather than assuming they noticed.

How to escalate politely if it's stuck

If a ticket has gone quiet beyond the stated response time, a polite bump works better than anger:

"Hi, just checking in on this — the site is still down and it's affecting orders. Is there an update or anything else I can provide?"

Mention business impact factually ("checkout is down, we're losing sales") — it helps support prioritize honestly. If the issue is genuinely unresolved after reasonable back-and-forth, ask: "Could this be escalated to a senior technician?" That's a normal request, not a complaint.

Frequently Asked Questions

How long should I wait before following up on a ticket?

Check the support page for stated response times first. If none is published, 24 hours is a reasonable window for a first follow-up on a non-urgent issue; for a site-down emergency, follow up within a few hours if there's been no acknowledgment. Always reference your ticket number.

Should I use live chat instead of a ticket for urgent issues?

Generally yes — if live chat is available, it's the faster channel for urgent problems like a down website. Tickets are better for complex issues that need investigation, logs, and screenshots, because everything stays documented in one thread. Use the channel that matches the problem's urgency and complexity.

What if I don't know the technical terms for my problem?

Describe what you see in plain words — that's completely fine. "The page is blank white when I click Plugins" is more useful than a guessed-at technical term. Screenshots fill the gaps. A good support team translates symptoms into causes; your job is just to describe accurately.

Is it safe to attach screenshots to a support ticket?

Yes, with one precaution: check what's visible before you attach. Crop out passwords, API keys, personal addresses, or full payment details. The URL bar and the error itself are exactly what support needs to see.

Why does support keep asking for information I already gave?

Usually one of two things: the ticket got transferred to another technician who skimmed instead of reading, or your details were spread across multiple messages. Keep everything in one thread, and when replying, briefly restate the key facts ("Still seeing the 500 error on example.com since this morning") so the new reader is oriented.

Can I ask support to just log in and fix it?

You can ask, but expect them to need your permission first — and they'll use a secure method, not your password. Many hosts can access the server side directly (that's their infrastructure), but anything inside your application (WordPress admin, email accounts) typically requires you to grant temporary access or make the change yourself with their guidance.

Stuck on a hosting or domain problem? Contact XYZREG support — and use the checklist in this guide when you write your ticket. A clear ticket with the domain, the exact error, and what you've tried gets you a clear answer, faster.