Guide

What to send your hosting provider during an outage (templates)

Copy-paste messages for the three situations you'll actually face — written to skip the “have you cleared your cache?” round-trip.

Published · Updated

When your site is down, the fastest way through hosting support is a first message that contains facts they can act on: the exact domain, timestamps in UTC, what an outside check observed (connection refused vs timed out vs an error code), and what you have already ruled out. Below are three literal templates you can copy, fill in and send — one for a site that is down right now, one for intermittent errors, and one for asking what caused an outage after it's over. Each is followed by what to fill in and why each line makes the reply faster.

Why the first message decides how fast you get help

Support desks triage. A ticket that says “my site is down, please fix it” gives the first-line agent nothing to check, so you get the script: clear your cache, try another browser, is it just you? Each round-trip costs half an hour to half a day. A ticket that says what failed, when in UTC, and from where can be matched against their own logs and status dashboards immediately — it often skips straight to someone who can see your server.

Template 1 — the site is down right now

Subject: Ongoing outage on [yourdomain.com] — connection refused since [14:32 UTC]

Hi,

My website [yourdomain.com] (account: [your account email or ID]) is down
right now and I need help finding the cause on the hosting side.

What external monitoring observed:
- First failure: [2026-07-15 14:32 UTC]
- Symptom: [connection refused / connection timed out / HTTP 502]
- Still failing as of: [2026-07-15 14:55 UTC]
- The domain still resolves to [203.0.113.7], so DNS looks unchanged.

What I've already ruled out:
- It's failing from outside my own network, not just for me.
- I haven't deployed or changed anything since [date/time].

Could you check:
1. Is there a known issue on this server or in this data centre?
2. If not, can you check whether the web service on my server is running?

Thanks,
[Your name]

What to fill in, and why each line matters

  • The subject line carries the symptom and the time. Whoever scans the queue can route it without opening it.
  • Timestamps in UTC. Host support desks operate in every timezone, and their server logs are almost always in UTC. “About an hour ago” forces them to ask when; 2026-07-15 14:32 UTC lets them grep.
  • “Refused” vs “timed out” is a real diagnostic. Connection refused means the machine answered and said nothing is listening — the server is up but the web service is down. Timed out means nothing answered at all — the machine, network or firewall is the suspect. Using the right word points support at the right subsystem before they run a single check.
  • “From outside my network” kills the it's-just-you script. Saying an external check saw the failure removes the cache-clearing round-trip entirely. (If you haven't verified this yet, an outside is-it-down check takes ten seconds.)
  • “I haven't changed anything since…” answers their first internal question — was it the customer's deploy? — before they ask it.

Template 2 — intermittent errors

Intermittent failures are the hardest to get taken seriously, because by the time someone looks, the site is up again. The pattern is your evidence — times, frequency, and the exact error seen:

Subject: Intermittent [HTTP 503] errors on [yourdomain.com] since [14 July]

Hi,

My website [yourdomain.com] (account: [your account email or ID]) is up,
but some requests fail. I'd like help working out whether the cause is on
the hosting side.

The pattern external monitoring shows:
- Error seen: [HTTP 503 / HTTP 502 / connection timeout] on [https://yourdomain.com/]
- Occurrences so far: [2026-07-14 22:10 UTC], [2026-07-15 03:41 UTC],
  [2026-07-15 09:02 UTC]
- Roughly [1 in 10] requests fail; the rest return 200 normally.
- Each episode lasts [30–90 seconds], then recovers on its own.

Nothing changed on my side around when this started ([date]).

Could you check, around the timestamps above:
1. Resource limits on my account (memory, CPU, process caps) being hit?
2. Any restarts, migrations or maintenance on my server in those windows?

Thanks,
[Your name]

What to fill in, and why each line matters

  • List real occurrence times, plural. One timestamp is an anecdote; three is a pattern they can correlate against overnight backup jobs, noisy neighbours, or resource-cap enforcement — the usual culprits.
  • Name the exact error. A 502 (a proxy got a bad answer from your app) and a 503 (the server is refusing work — overload or maintenance) point at different causes. Copy the code exactly as observed.
  • Estimate the failure rate. “1 in 10 requests” tells them it's a capacity or pool problem rather than a hard outage, and how urgent it is.
  • “Recovers on its own” is a clue, not a reassurance. Self-recovering episodes suggest restarts or throttling — both of which show up in host logs at exactly the times you listed.

Template 3 — asking what caused an outage, after recovery

Once the site is back, it's tempting to move on. Send this anyway — if the cause was on the host's side, you want it acknowledged, and if it was on yours, you want to know what to fix:

Subject: Request for cause of outage on [yourdomain.com] ([15 July])

Hi,

My website [yourdomain.com] (account: [your account email or ID]) was down
from [2026-07-15 14:32 UTC] to [2026-07-15 15:18 UTC] — about [46 minutes].
It has recovered, but I'd like to understand what happened so I can prevent
a repeat.

What external monitoring recorded:
- [2026-07-15 14:32 UTC] — requests began failing with [connection refused]
- [2026-07-15 15:18 UTC] — the site started returning 200 again

Could you tell me:
1. What caused it — was it on the host side, or something in my account?
2. Was action taken to resolve it, or did it recover on its own?
3. Is there anything you'd recommend I change to avoid a repeat?

Thanks,
[Your name]

What to fill in, and why each line matters

  • The exact window, with duration. Start and end in UTC lets them pull logs for precisely that slice; the duration signals how seriously to treat it.
  • “Did it recover on its own?” is the key question. If someone at the host restarted something, there was a host-side cause worth naming. If nothing was done, the cause is likely still latent — on their side or yours.
  • Asking for a recommendation invites a real answer. Support can often tell you “your plan's memory limit was hit” or “that node was migrated” when asked directly — information they won't volunteer.

PingStuff writes this note for you

Everything the templates ask you to fill in — first-failure time, refused vs timeout, confirmation from outside, recovery time — is exactly what monitoring records during an incident. On paid PingStuff monitoring, every incident includes a “What to send your host” note generated automatically from that incident's real data, with the timestamps already in UTC and the symptom already worded correctly. You copy it, add your account ID, and send it.