How to report a network problem so it gets fixed
What to put in a message to IT support or your provider so the first reply is a fix rather than a question — with a template to copy.
Updated 2026年9月25日3 min read
Shown in English
Before you run anything
Most support tickets about networks go back and forth three times before anyone looks at the actual problem: when did it start, is it just you, what have you tried. Answer those in the first message and the first reply can be a fix.
Before you write anything
Work out the scope. It changes who should receive the report as much as what goes in it.
- One site, or everything? If one site is slow or down and others are fine, the problem is that site. Report it to them, not your provider.
- One device, or all of them? If your phone works and your laptop does not, the network is probably fine and the laptop is not.
- Wi-fi, or cable too? If a cable fixes it, it is a wireless problem inside your building.
A checking order for a bad connection walks through this properly. Five minutes there often means the report goes to the right people first time.
What to include
- What you expected, and what happened instead. “Pages time out” is less useful than “
github.comshows ERR_CONNECTION_TIMED_OUT after about 30 seconds; other sites load normally.” Quote error messages exactly, or attach a screenshot. - When it started, and whether it is constant. An exact time lets someone find the matching entry in their logs. “Every evening from about 8pm” points at congestion; “since Tuesday’s maintenance window” points at a change.
- What else is affected. Other devices, other people in the building, other networks — does it work on mobile data?
- Your public IP address and provider. They may need it to find your connection in their systems. The network report collects it, along with your browser, connection type and latency, and can mask the address if you are posting somewhere public.
- Evidence. Two or three short command outputs are worth more than a paragraph of description:
- a ping to your router and to
1.1.1.1, which separates a local fault from a wider one; - a DNS lookup of the failing name, which separates a name problem from a connection problem;
- a traceroute or
mtrto the failing destination and to one that works, run two or three times. A single trace proves very little — see reading traceroute for why.
- a ping to your router and to
- What you have already tried. Restarted the router, tried another DNS server, used a cable. This saves them asking you to do it again.
A template
Problem: <what fails, with the exact error message>
Expected: <what should have happened>
Since: <date and time it started> Constant / intermittent: <which>
Affects: <this device only / all devices / everyone on this network>
<works on mobile data: yes / no>
Network: <provider>, public IP <address or "attached report">
Tried: <router restart, other DNS, cable, other browser...>
Evidence:
ping <router> -> <loss %, typical time>
ping 1.1.1.1 -> <loss %, typical time>
DNS lookup <name> -> <answer or error>
traceroute to failing destination (x3) and to a working one: attached
Before posting in public
If you are asking in a forum rather than a private ticket, remove anything that identifies your network or grants access to it:
- your public IP address (the network report can mask it for you),
- internal hostnames and addresses that reveal how your network is laid out,
- anything resembling a password, token or API key — these turn up in pasted logs more often than people expect.
Who to send it to
- A single website or service misbehaving — that site’s support or status page.
- Your connection at home — your internet provider.
- Your connection at work — your IT team, who can see logs you cannot.
- Email bouncing or landing in spam — the provider that sends the mail, and check its DNS records first with the SPF, DKIM and DMARC check.