How to run network diagnostics from your iPhone

Something's down. You're not at your desk. All you have is your phone and a connection that may or may not be the problem.

Most network troubleshooting guides assume you're sitting at a laptop with a terminal open. You're not always. On a job site, in a server room, at a client's office, or just away from your desk — a lot of the first-pass diagnosis you'd do from a shell, you can do from a phone. Here's the workflow, and what each check actually tells you.

Ping — is it reachable at all?

Ping is the first question: can I even get a packet there and back? A reply means the host is up and routable. No reply means it's down, blocking ICMP, or the path is broken somewhere between you and it. The round-trip time is your first read on latency; wildly inconsistent times point at a congested or flaky link.

Start with something you know is up (8.8.8.8) to confirm your connection works, then ping the thing you actually care about. If the first works and the second doesn't, the problem isn't you.

Traceroute — where does it break?

If ping fails or latency is bad, traceroute shows you the path — every hop between you and the destination. When the trace dies at a certain hop and never recovers, that hop (or the link after it) is where things fall apart. When one hop's latency jumps and stays high for the rest of the route, you've found your bottleneck. It's the difference between "the internet is slow" and "the third hop out of my ISP is the problem."

Port scan — is the service actually listening?

A host can be up while the service you need is dead. Ping answers "is the machine alive"; a port scan answers "is the thing I'm trying to reach actually accepting connections." Check 443 for HTTPS, 22 for SSH, 3306 for MySQL, whatever you're chasing. An open port means something's listening; closed or filtered means the service is down, bound to the wrong interface, or a firewall is in the way.

DNS lookup — are you even going to the right place?

Half of "the site is down" turns out to be DNS. A lookup tells you what a name actually resolves to right now — and whether that matches where it should point. Stale records after a migration, a propagation delay, a typo in a zone file: all of it shows up here. If the IP is wrong, nothing downstream matters until you fix the name.

SSL check — is the certificate the problem?

For anything on HTTPS, an expired or misconfigured certificate breaks the connection in a way that looks like an outage but isn't. Checking the cert tells you the expiry date, the issuer, and whether the chain is valid. An expired cert is one of the most common "the whole site is down" causes, and one of the fastest to confirm from a phone.

WHOIS — whose is it, and is the domain still yours?

When you're chasing something further out — a domain that stopped resolving, an IP you don't recognize — WHOIS tells you who owns it and, for domains, when the registration expires. Domains that lapse silently take everything on them down with no warning. It's worth a look before you assume the problem is technical.

Doing all of this from one place

I built NetOps because this was the toolkit I kept wishing I had on my phone — ping, traceroute, port scan, DNS lookup, SSL inspection, and WHOIS, in one app with a terminal aesthetic and no accounts. It started on a job site with a flaky connection and nothing but my phone to figure out why.

If you do this kind of work, it's on the App Store: Download NetOps. One-time purchase, no subscription.

The commands above are universal — you can run most of them from any decent network tool. The point isn't the app; it's that you don't need a laptop to answer the first five questions of "why is this down." You just need to know which question to ask first.