How to report a problem so it gets fixed fast

"My website isn't working" is a completely honest description of the problem, and it's also one that almost never gets fixed on the first reply — not because support doesn't want to help, but because that sentence alone doesn't say enough to act on. Someone has to write back and ask what "not working" actually means, which URL, since when, and what's already been tried. Each of those questions is a delay you can remove up front, and doing so is genuinely one of the highest-leverage few minutes you can spend on a broken site.

Why detail is the whole game

A support ticket gets resolved faster in direct proportion to how quickly the person reading it can reproduce or locate the fault. A vague report starts a round trip: they ask a clarifying question, you answer, they ask another. A detailed report lets them go straight to the relevant log, the relevant file, or the relevant setting on the first read. The difference between those two experiences is almost entirely about what you include the first time, not about how fast anyone is working.

The five things worth including every time

1. The exact URL

Not "my site" or "the homepage" — the full, exact address of the specific page where the problem happens. If it happens on more than one page, list a couple of examples rather than describing them generally. A precise URL means support can go and look at the exact thing you're describing rather than guessing which page you mean.

2. The exact time

As precisely as you can manage, including your time zone. Server logs are timestamped, and a fault reported as "just now, around 14:20 UTC" can be matched against a log entry directly. "Earlier today" or "a little while ago" usually can't be matched to anything specific, which forces a search through a much wider window of log activity — or no search at all, if the log has already rotated past that point.

3. The exact error text

Copy it, don't paraphrase it. "It said something about a database" and "Error establishing a database connection" point in genuinely different directions, and the exact wording of an error message is frequently specific enough on its own to identify the cause before any further digging is needed. If there's no visible error message at all, say exactly what you see instead — a blank white page, a spinning loader that never finishes, a page that looks fine but a specific button does nothing.

4. What changed recently

An update, a new plugin, an edit to a file, a DNS change, a new piece of content, a certificate renewal — anything you did, or anything that might have happened automatically, in the period before the fault started. This is frequently the single most useful piece of information in the entire report, because most faults trace directly back to a specific recent change rather than appearing from nowhere.

If you genuinely can't think of anything, say so — that's still useful, because it tells support to look at automatic changes (a scheduled update, an expiring certificate) rather than searching for a manual one that didn't happen.

5. What you've already tried

Cleared your cache? Tried a different browser? Checked from another network? Looked at the error log? List it. This does two things: it stops support suggesting something you've already ruled out, which wastes a full reply cycle, and it narrows down what's left to check, since you've already eliminated some possibilities yourself.

Putting it together

A well-written report doesn't need to be long. Something like this, adjusted to your actual situation, covers everything above in a few sentences:

URL: yourdomain.com/checkout
Time: today around 15:40 UTC
Error: "503 Service Unavailable" shown on the page, screenshot attached
Recent change: updated a payment plugin about an hour before this started
Already tried: hard refresh, tested in a private window and on mobile
  data — same result both times

That's five short lines, and it's already enough for support to check the error log around 15:40, look specifically at the plugin you named, and skip straight past the troubleshooting steps you've confirmed don't fix it.

A few things that don't help, even with good intentions

• Guessing at the cause instead of describing the symptom. "I think my hosting is down" is less useful than the actual error message, because the guess can point support in the wrong direction before they've even looked. Describe what you see; let support work out what it means.
• Combining several unrelated issues into one ticket. A slow page and a broken contact form are two separate problems, most likely with two separate causes. Reporting them separately gets each one resolved on its own timeline rather than one confusing thread with two open threads inside it.
• Leaving out the "small" detail that only you know. Something that seems too minor to mention — "it only happens on my phone", "it started right after I changed a DNS record for something unrelated" — is very often exactly the detail that solves it.

Before you even open a ticket

A quick pass through our guide on troubleshooting any website problem takes a few minutes and often either resolves the issue outright or, at minimum, gives you two or three of the five details above for free — what changed, whether it's affecting everyone or just you, and what the error log actually says.

When you're ready

Reach us through contact us with the detail above included. It reads as more effort up front, but it consistently means fewer replies overall — which is a better outcome for everyone, not just a faster one for you.