Uptime Checks From Outside the VPS Machine

Blackbox exporter on the same VPS is blind to the failure you care about most: the machine is off, the public NIC is gone, or the route to Lucknow DC01 is broken. The probe process dies with the host. Prometheus cannot scrape it. Alertmanager cannot send. You find out from a user, or from SSH hanging. Observability that lives entirely inside the guest has a hole the size of the guest.

The fix is not a second metrics cluster. It is one check that runs somewhere else and pages you when HTTPS stops. That somewhere else can be a tiny probe on another VPS, a cron job at home, or a commercial uptime ping. The requirement is independence: different machine, different network path, different failure domain.

What the external check must prove

It must speak like a user. TCP 443 open is not enough if nginx returns 502. DNS resolution must use public DNS, not the host file on the VPS. TLS must validate. A 200 on /health is the contract. If /health is too cheap (it never hits the database), add a second path that does, or accept that you are only checking the proxy.

Do not ICMP-ping and call it uptime. ICMP can be filtered by L3/L4 DDoS rules or by a provider policy while HTTPS still works, and the reverse is also true. Probe the port and the URL. Measure status code and latency. Store the result off the target.

#!/usr/bin/env bash
set -euo pipefail
URL=https://example.com/health
code=$(curl -sS -o /tmp/health.body -w '%{http_code}' --max-time 10 "$URL" || true)
if [ "$code" != "200" ]; then
  echo "health failed code=$code"
  exit 1
fi

Run that from a second machine every minute via cron or a systemd timer. On failure, send mail or a webhook. Two or three consecutive failures is a page; one failure is the internet being the internet. If you only have one VPS, a Raspberry Pi at home or a cheap extra instance is the second machine. The extra instance should not share the same credentials disk as the target, and it should not be the same plan you just rebooted.

A second VPS is the clean version

A small Ubuntu box whose only job is Prometheus plus blackbox_exporter, targeting the public URL of the app VPS, is the same software you already know. Scrape from the probe host, alert from the probe host, send from the probe host. When the app host dies, the probe host still talks to Alertmanager. That is the entire architectural insight.

Keep the probe host boring: no application, no Docker playground, automatic updates, SSH keys only. Bind Prometheus to localhost. The probe host can live in the same Lucknow datacenter and still catch guest death, kernel panic, and disk-full-ssh-dead. It will not catch a facility-wide path failure if both machines share the path. If that risk matters, the check must leave the facility: a cron at home, or an uptime service on another network. Same-DC probes are still worth having because most outages are the guest, not the building.

scrape_configs:
  - job_name: remote-http
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://example.com/health
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

Page on probe_success == 0 for 2m from this job, not from the on-box job. The on-box job still catches local nginx mistakes while the guest is up. Both jobs can coexist. Name them so 2 a.m. you knows which failure domain tripped.

Status pages and third parties

A public status page is optional. An external checker that only emails you is enough for a one-person app. If you use a SaaS ping, point it at /health, require 200, and do not leak admin URLs. Confirm it validates TLS. Confirm the From address is not a mailbox you never read.

DNS is part of uptime. If the name expires or the A record points at an old IP after a rebuild, on-box blackbox against localhost still looks green. The external check uses the name. After you rebuild a VPS, watch the external probe until it is green; that is the proof the world sees the new IP.

Do not wait for the probe to replace SSH. When the external check fires, try SSH, try the console, try whether it is DNS. The probe says "users cannot reach it." It does not say why. Why still lives in journalctl, node_exporter, and the provider console.

Takeaway

A probe that lives on the target cannot report the target's death. Add one external HTTPS check with TLS validation and a for duration, then keep on-box metrics for the why. Netbay VPS instances in Lucknow boot in under 60 seconds if you want a dedicated probe host — netbayhosts.in.