Uptime Monitoring for Tor Hidden Services: 2026 Setup Guide

Standard uptime services (UptimeRobot, Pingdom, Better Uptime) monitor by making HTTP requests from their servers to your URL. They cannot make requests to .onion addresses because they do not run Tor. The monitoring server would need a Tor client to reach a .onion address. Self-hosted monitoring is the solution: run a monitoring tool on a server with Tor installed, configure the monitoring tool to use Tor's SOCKS5 proxy for .onion checks, and alert when the check fails. This requires owning the monitoring infrastructure, which has the additional benefit of keeping monitoring data private (not disclosed to a third-party monitoring service).

Uptime Kuma is the leading open-source self-hosted monitoring tool with .onion support. Setup: install Uptime Kuma (Docker: docker run -d --name uptime-kuma -p 3001:3001 louislam/uptime-kuma:1), add a monitor pointing to http://youraddress.onion, and in the monitor settings enable 'HTTP(s) monitor with proxy: SOCKS5'. Configure the SOCKS5 proxy to point to the Tor daemon (127.0.0.1:9050 if Tor is on the same server, or the Tor daemon's network address if on a different server). Uptime Kuma will route the .onion check through Tor and record the response time and status. Alerting: configure notifications (Telegram, Signal, email, PagerDuty) to fire when the .onion service is down. Dashboard: Uptime Kuma's web interface shows status history, response time graphs, and incident history.

For detailed metrics beyond uptime (response time percentiles, error rates, system metrics): Prometheus scrapes metrics from exporters; Grafana visualizes them. Node exporter: runs on each hidden service server, exposes system metrics (CPU, RAM, disk, network) to Prometheus. Blackbox exporter: performs HTTP probes against URLs and exposes the results as Prometheus metrics. Configure Blackbox with a SOCKS5 proxy (use the `socksProxy` configuration option) to probe .onion addresses. Scrape configuration in prometheus.yml: - job_name: onion_probe, metrics_path: /probe, params: {module: [http_2xx]}, static_configs: [{targets: ['http://youraddress.onion']}], relabel_configs: [{target_label: __param_target, source_labels: [__address__]}, {target_label: instance, source_labels: [__address__]}, {replacement: localhost:9115, target_label: __address__}]. This routes Blackbox probes through Tor via the Blackbox configuration.

Alertmanager (Prometheus component) routes alerts to notification channels. Configuration: group related alerts (group_by: [onion_service, severity]), add debounce (for: 5m for service-down alerts - avoids flapping), and route to appropriate channels (Telegram, PagerDuty, email). Alert rules for .onion: probe_success == 0 for 5 minutes triggers 'service down' alert, probe_duration_seconds > 30 for 10 minutes triggers 'service degraded' alert. Runbook links in alerts: add annotations with runbook URLs pointing to your incident response documentation. Incident response: on receiving a 'service down' alert, standard response procedure: (1) verify by manual check from a different Tor circuit, (2) check server health (SSH in, check application process, check Tor process), (3) check Tor logs for circuit or introduction point errors, (4) restart services if needed, (5) post-incident review for root cause.

Uptime monitoring checks whether the service is reachable. Synthetic monitoring checks whether user flows work end-to-end. For .onion services: Playwright-based synthetic monitoring scripts simulate user actions (log in, submit a form, access a key feature) and alert if any step fails. Running via Tor: configure Playwright to use Tor's SOCKS5 proxy (playwright.chromium.launch({args: ['--proxy-server=socks5://127.0.0.1:9050']})) for actual .onion browsing in automation. Schedule via cron: run synthetic tests every 5-10 minutes. Alert on test failure (non-zero exit code from Playwright). This catches application-level failures (successful HTTP response but broken functionality) that uptime monitors miss.