Does Tor latency affect real-time monitoring dashboards?

For viewing dashboards: Tor adds 500-2000ms page load latency compared to a directly accessible dashboard. For time-series data: metric data is collected by exporters at the source and only viewed via the dashboard, so collection frequency is not affected by Tor latency. Real-time dashboards (Netdata updates every second): the dashboard display in Tor Browser updates every second but each update loads through Tor, so the perceived real-time experience may feel slightly delayed. For operational monitoring (reviewing current system state, not reaction-time-critical operations): the Tor latency is acceptable.

Can Prometheus scrape metrics from servers via Tor?

Yes. Configure Prometheus with proxy_url: socks5://127.0.0.1:9050 in the scrape_config section. Prometheus then routes scrape requests through Tor's SOCKS5 proxy. Each monitored server needs to expose its metrics endpoint (Node Exporter port 9100) as a Tor hidden service. Prometheus scrapes http://monitoredserver.onion:9100/metrics through Tor. Scrape interval should account for Tor latency: set scrape_interval: 60s instead of the default 15s to avoid accumulating timeout failures from slow Tor connections.

How do I configure alerting that works over Tor?

Grafana alerting can send to: Telegram (configure Telegram bot, Grafana sends messages via Telegram API through Tor if Grafana is configured with HTTP proxy 127.0.0.1:9050), email via an SMTP relay accessible from the monitoring server, Slack or other webhook endpoints accessible via Tor exit nodes. For the monitoring server to send outbound alerts: install Tor on the monitoring server, configure Grafana to use it as an HTTP proxy (in grafana.ini: [smtp] and [external_image_storage] sections support proxy configuration). Alternatively: configure alerting to write to a log file and have a separate script send alerts via an already Tor-proxied channel.

Is Grafana authentication sufficient security for a .onion dashboard?

Authentication is sufficient for many deployments. The .onion transport already restricts access to anyone who knows the address. Grafana's built-in authentication (username/password) provides per-user access control. For enhanced security: enable Grafana's multi-factor authentication (built-in TOTP support since Grafana 9.0), use Tor v3 client authorization (cryptographic key requirement before any connection is made), and restrict Grafana's user permissions (view-only users cannot modify dashboards or alerting rules). The .onion + authentication combination is significantly more secure than a clearnet Grafana with authentication alone.

Can I monitor .onion services specifically with Uptime Kuma?

Yes. Configure a SOCKS5 proxy in Uptime Kuma (Proxy Management section) pointing to your local Tor SOCKS5 port (127.0.0.1:9050). Create monitors of type HTTP for .onion URLs. Assign the SOCKS5 proxy to those monitors. Uptime Kuma will check the .onion URL availability via Tor at the configured interval. This allows monitoring both your clearnet infrastructure and your .onion services from a single dashboard, with alerts when any service becomes unavailable.

Infrastructure Monitoring Dashboard as a Tor Hidden Service

Infrastructure monitoring dashboards expose sensitive operational intelligence: server hostnames, IP addresses, service names, performance baselines, and alerting thresholds. A monitoring dashboard accessible on the internet (even password-protected) reveals the existence and structure of monitored infrastructure to anyone who can reach it. Running monitoring as a Tor hidden service eliminates this exposure: Grafana, Netdata, or Uptime Kuma dashboards accessible only via .onion cannot be discovered by external parties even if they know the monitoring software is in use. This guide covers deploying popular monitoring tools as .onion hidden services with appropriate security configurations.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

Why Monitoring Dashboards Are Sensitive

Infrastructure monitoring dashboards contain operationally sensitive information: server IP addresses and hostnames, service names and versions (useful for targeted vulnerability exploitation), performance baselines (an attacker who knows normal performance can detect anomalies or plan timed attacks), alerting thresholds (knowing when alerts trigger allows attackers to stay just below detection limits), and infrastructure topology (which services depend on which others). A monitoring dashboard leaked to an attacker provides reconnaissance data equivalent to an internal network map. Exposing Grafana or similar on a public port - even with authentication - creates a target for credential brute-force, known authentication vulnerabilities in dashboard software, and information leakage through unauthenticated API endpoints. Running monitoring as a .onion hidden service eliminates the attack surface: no public port, no discoverable IP, no authentication bypass attempts from the internet.

Grafana as a .onion Hidden Service

Grafana is the most widely deployed metrics visualization platform. Install Grafana: apt install grafana. Configure /etc/grafana/grafana.ini: set http_addr = 127.0.0.1 (not the default 0.0.0.0 which binds to all interfaces) and http_port = 3000. Configure Tor: HiddenServiceDir /var/lib/tor/monitoring/ and HiddenServicePort 3000 127.0.0.1:3000. Access Grafana via Tor Browser at the .onion URL. Configure dashboards: connect Grafana to Prometheus (running locally on the monitoring server), InfluxDB, or other data sources. For distributed monitoring (monitored servers sending metrics to the Grafana server): Prometheus can scrape metrics from servers via Tor (configure Prometheus to use Tor SOCKS5 proxy for scraping remote targets). Alerting via Grafana: configure alerts to send to a private Telegram bot or email via Tor-accessible SMTP.

Netdata for Real-Time .onion Monitoring

Netdata provides real-time, high-resolution system metrics with a built-in dashboard. Install Netdata via the official script. By default, Netdata listens on port 19999. Configure Netdata to listen only on localhost: in /etc/netdata/netdata.conf set bind to = 127.0.0.1 under the [web] section. Configure Tor: HiddenServicePort 19999 127.0.0.1:19999. Access the Netdata dashboard via Tor Browser at the .onion URL. Netdata streaming: configure monitored servers (with Netdata installed) to stream metrics to the central Netdata server via Tor. In the monitored server Netdata configuration: configure the [stream] section with destination = yourcentral.onion:19999 and api key = . The streaming connection uses Tor SOCKS5 proxy (configure proxy_host = 127.0.0.1 and proxy_port = 9050 in Netdata stream configuration).

Uptime Kuma for .onion-Accessible Status Monitoring

Uptime Kuma is a self-hosted uptime monitoring tool with a clean dashboard. Install via Docker: docker run -d --restart=always -p 127.0.0.1:3001:3001 louislam/uptime-kuma:1. Configure Tor: HiddenServicePort 3001 127.0.0.1:3001. Uptime Kuma monitors: website availability (HTTP/HTTPS checks), TCP port availability, DNS resolution, Docker container status, and database connections. For monitoring .onion services: Uptime Kuma can monitor .onion addresses if configured to use Tor's SOCKS5 proxy for its HTTP checks. Set SOCKS5 proxy in Uptime Kuma settings (Proxy Management section): add a SOCKS5 proxy at 127.0.0.1:9050 and enable it for monitors that check .onion URLs. This creates a monitoring setup where Uptime Kuma (behind .onion) checks both clearnet and .onion services and presents results via the .onion dashboard.

Distributed Monitoring Architecture Over Tor

For organizations with infrastructure in multiple locations: establish a central monitoring server running Grafana + Prometheus + Tor (as .onion hidden service). Deploy Prometheus Node Exporter on each monitored server. Configure Prometheus on the central server to scrape remote Node Exporters via Tor: add to prometheus.yml scrape_configs with proxy_url: socks5://127.0.0.1:9050. This requires each monitored server to expose its Node Exporter as a Tor hidden service (HiddenServicePort 9100 127.0.0.1:9100). The central Prometheus scrapes metrics from each server's .onion:9100 address via Tor. All monitoring traffic routes through Tor - no clearnet connection between monitored servers and the monitoring server. Benefits: the monitoring server's IP is hidden from monitored servers (they see Tor exit IPs), and the monitoring architecture does not create clearnet connections that could be tracked.

Related Services

Offshore VPS from $17.90/mo Dedicated Servers DevOps Services

Why Anubiz Host

100% async — no calls, no meetings

Delivered in days, not weeks

Full documentation included

Production-grade from day one

Security-first approach

Post-delivery support included

Bulletproof Hosting Providers

DMCA-Ignored Servers

Offshore VPS Hosting

Anonymous Hosting Solutions

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Start a Brief Iceland VPS I - $29.99/mo