What this prompt does
This prompt makes the AI write a network diagnostics script that walks connectivity problems in a fixed, sensible order instead of guessing. You set the context with [server_role] and [network_topology], then the script tests basic reachability by pinging [gateway_ip], public DNS, and your [critical_endpoints] with configurable timeout and packet count, reporting latency and packet loss.
The structure works because it isolates failures layer by layer. After ping it verifies DNS for [dns_test_domains] against local and public resolvers, tests raw TCP to [service_endpoints] to tell open from filtered ports, runs traceroute to [trace_targets] to find the slow or dropping hop, and inspects local firewall rules and interface state. Each check feeds a traffic-light summary, so a vague "it's down" becomes a specific finding: the host, the route, or a security group. Because the targets are all variables, the script is tailored to the exact box you're debugging rather than a generic ping test.
When to use it
- A server suddenly can't reach a dependency and you need to localize the fault fast.
- You want a repeatable diagnostic instead of typing ad-hoc ping, dig, and nc commands each time.
- You're debugging in a cloud VPC where security groups or routes are the likely culprit.
- DNS is suspect and you need to compare local resolver answers against public ones.
- You need to know whether a port is open, closed, or filtered without installing extra tooling.
- You want a shareable report with a clear per-category status to hand to a teammate or client.
Example output
Expect a single shell script that, when run, produces a structured diagnostic report: a section per check (connectivity, DNS, TCP, traceroute, firewall, interfaces/routes) each tagged green, yellow, or red, with the raw measurements (latency, packet loss, connection time, the offending hop) and a suggested next step per failure. The traffic-light summary sits at the top for a quick read.
Pro tips
- Fill
[critical_endpoints]with host:port pairs you actually depend on (database, cache, payment API) so the TCP checks test real failure paths, not just generic internet access. - For
[dns_test_domains], include both internal and external names — split-horizon DNS issues only show up when you compare the two resolvers. - Set realistic
[gateway_ip]and[trace_targets]; a traceroute to the wrong target tells you nothing about the actual outage. - The firewall check is most useful when you point it at the specific problem destinations — scope it to
[service_endpoints]rather than dumping every rule. - Run the script from the affected host itself; the same checks from your laptop won't reveal host-local routing or firewall problems.
- Treat yellow results as worth investigating, not safe — partial packet loss or slow DNS often precedes the hard red failure.
