Monitoring a homelab from outside it

Most homelab monitoring has a structural weakness: it runs on the thing it is monitoring. Prometheus, Grafana and an uptime checker are all excellent, and all of them are containers on your server, watching other containers on your server, from inside your network.

That answers "is the container healthy." It does not answer "can anyone actually reach this," which is a different question with a different failure list. A certificate that expired, a tunnel that dropped, a DNS record pointing at an address that moved, an ISP address that rotated: none of those make a container unhealthy. The stack stays green while the service is unreachable for everybody.

You want a second vantage point, outside the system, that you always have with you. A phone works remarkably well for this.

What an internal stack cannot see

Six failures that leave every container green:

• A certificate expired. The service runs, the proxy runs, and every browser refuses it. Renewal hooks fail quietly more often than anyone expects, usually because the proxy was never reloaded.
• DNS points somewhere else. A record was edited, a provider changed, or your dynamic DNS client stopped updating after a restart.
• Your public address changed. Residential addresses rotate. Anything that referenced the old one is now pointing at a stranger.
• A tunnel dropped. The container is running and the tunnel inside it reconnected to nothing, or never reconnected at all.
• Your ISP started blocking a port. Rare, but it happens, and nothing internal will ever tell you.
• It works at home and nowhere else. The single most common self hosting failure, and by definition invisible from inside.

Every one of those is caught by checking from outside. On a phone that means turning Wi-Fi off, which gives you a different address, a different route, a different resolver and a different ISP in one action.

The five layers worth checking

Loading a self hosted service means completing five steps, and each fails independently. Checking them in order means the first failure tells you which layer is broken, instead of a browser giving you one undifferentiated error.

Check	Answers	A failure here means
DNS lookup against 1.1.1.1	Does the name resolve, and to what?	Record is wrong, dynamic DNS stalled, or the domain lapsed
TCP connect to 443	Is anything listening there?	Refused means the service is stopped. Timed out means a firewall or a dead tunnel
TLS inspection	Is the certificate valid, and for how much longer?	Expired, wrong hostname, or a missing intermediate
HTTP(S) check	What status code and redirect chain?	502 or 503 means the proxy is up and the application is not
Ping or a latency baseline	How does it feel from out there?	Reachable but degraded, which nothing else reports

The TLS check is the one that earns its place fastest. It reports days remaining, so a certificate problem becomes something you see coming rather than something you discover from a message on a Sunday morning.

Building it as one tap

Five checks by hand is tedious enough that you will stop doing it. Chained into a single automation it is one tap and one screen.

1. Make one automation per stack, not per service

   If eight services sit behind one reverse proxy, most of them share a fate. Check the proxy hostname thoroughly, then add a quick HTTP check for two or three services that have their own failure modes, such as anything with a separate container or database.

2. Point the checks at the public name, not the internal IP

   The whole value is testing the path your users take. An automation aimed at 192.168.1.50 tests something you were not worried about.

3. Add an internal variant too

   A second automation using internal names and addresses. Running both tells you immediately whether a problem is the service or the path to it, which is the distinction that takes longest to establish by hand.

4. Include a DNS check against a public resolver

   Your own resolver may answer from cache or from a split horizon record, so it will happily tell you everything is fine while the outside world sees something else entirely.

5. Run it on cellular data

   Wi-Fi off. It takes a second and it is the difference between testing your service and testing your LAN.

Home screen buttons and Shortcuts

Automations can be triggered by URL, which is where this gets genuinely convenient. A saved automation has its own deeplink:

# Run a saved automation and export the result
https://netdebug.app/open/automation/homelab-external?autorun=true&export=pdf

# Individual checks work the same way
https://netdebug.app/open/tls?target=home.example.com
https://netdebug.app/open/http?target=https://home.example.com

That URL is the building block for a few useful things:

• A home screen icon. Add the link to your home screen and the whole check is one tap from the lock screen.
• A Shortcut, and therefore Siri. Wrap it in a Shortcut and you can ask for it by name, or trigger it from any of the Shortcuts automation conditions.
• An arrival or time trigger. Run the internal check when you get home, or the external one every morning.
• A link in your own documentation. If you keep runbook notes, a link that runs the right diagnostic for that service is more useful than a paragraph describing which tools to open.
• The export parameter. Adding export=pdf brings up the share sheet with the finished report attached, which is what you want when the next step is sending it to an ISP or a hosting provider.

You do not have to build these URLs by hand. Any tool or automation screen has a Copy Deeplink action in its share menu that produces the link with your current settings already in it.

The part that pays off later

A single check tells you whether something is up right now. That is the less useful half.

Running the same checks repeatedly builds a record, and the record is where the interesting things show up. Run History saves every run on device and charts the results over time, which surfaces three things a point in time check never will.

Certificate expiry approaching. Days remaining is a number that counts down. Watching it go from 60 to 30 to 14 is how a renewal problem becomes a calendar item rather than an incident.

Latency creeping up. A service that answered in 40ms three months ago and answers in 180ms today is degrading, and nobody notices that gradually by feel. A chart makes it obvious.

When something actually changed. When a housemate says the service has been slow "for a while", having identical checks with timestamps turns that into a date. That matters both for your own debugging and for anything you need to escalate to a provider, where a chart of repeated identical tests carries far more weight than a description.

What this does not replace

Worth being straight about, because overselling it would be the wrong lesson.

This is not alerting. Nothing wakes you at 3am. A check you have to run is a check you will forget during the week you most need it. If you need to know within minutes, use an external uptime service, and run one hosted somewhere other than your own network, because an uptime checker inside the thing it watches is not an uptime checker.

This is not application monitoring. It tells you a service answered on port 443 with a 200. It does not tell you that a database is filling a disk, a queue is backing up, or a backup job has been silently failing for three weeks. That is what your internal stack is for, and the two are complementary rather than competing.

What the phone gives you that neither of those does is an independent vantage point that survives your network being the problem. When the internal dashboard is unreachable because the thing hosting it is down, a check from cellular data still works, and that is exactly the moment you need one.

A routine worth keeping

• After every change to a proxy, certificate, DNS record or tunnel: run the external automation. Thirty seconds, and it catches the mistake while you still remember what you changed.
• Weekly: run both automations and glance at the certificate expiry numbers.
• When someone says it is broken: run the external one first, from cellular. That single result tells you whether to debug the service or the network.
• Before you travel: confirm remote access works from a network that is not yours, while you are still somewhere you can fix it.

The short version

Monitoring that runs inside your homelab cannot see the failures that matter most to anyone outside it: expired certificates, stale DNS, dropped tunnels and a rotated public address. Chain a DNS lookup, a TCP connect, a TLS inspection, an HTTP check and a latency test into one automation, point it at your public hostname, and run it from cellular data. Keep the history, because the trend catches problems earlier than any single result. And do not mistake it for alerting, which still belongs somewhere other than your own network.