en
Tor Relay Uptime Monitoring and Alerting
Tor relay uptime is critical for maintaining the Stable flag - a relay that frequently goes offline loses the Stable flag, which reduces its assignment to circuits that require long-duration stability (hidden services, long downloads). Operators who care about relay quality and network contribution need monitoring that alerts them to downtime quickly and ideally triggers automated recovery. Beyond the Stable flag, relay uptime directly affects users whose circuits include the relay - if the relay goes offline mid-circuit, all circuits using it are disrupted and users must establish new circuits. This guide covers monitoring approaches for Tor relay uptime, from simple uptime checks to comprehensive operational dashboards.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
The Stable Flag and Uptime Requirements
The Tor Stable flag is assigned to relays that have demonstrated consistent uptime. The authority consensus algorithm considers: weighted time between circuit failures, historical uptime (online time vs total time observed), and recent uptime stability. A relay that has been offline for a period loses Stable flag consideration - it needs to demonstrate sustained uptime again before regaining the flag. The minimum uptime for Stable flag consideration is approximately 95% over a 30-day window, though the exact threshold varies as the network averages change. For hidden service and long-session circuit selection: Tor preferentially selects relays with the Stable flag. A relay with Stable flag is more useful to the network than an equivalent relay without it. Monitoring and maintaining uptime above 95% is directly tied to relay quality and network utility.
Tor Metrics External Monitoring
Tor Metrics (metrics.torproject.org) provides historical uptime data for all public relays. Use Tor Metrics to check your relay's: uptime percentage over the last 30 days, current flags (including Stable), bandwidth history, and consensus weight history. Tor Metrics updates approximately every hour. For near-real-time status: Atlas (another Tor relay information site) shows current relay status. To be alerted when your relay goes offline via Tor Metrics: set up a cron job that queries the Tor Metrics API. The Tor Metrics API endpoint for relay status: curl https://metrics.torproject.org/api/details?lookup= returns relay status including running, last_seen, and flags. Parse the JSON response and alert if running is false or last_seen is more than 2 hours ago.
Self-Hosted Monitoring with Prometheus
For comprehensive local monitoring: enable Tor's built-in metrics export via MetricsPort. Add to torrc: MetricsPort 127.0.0.1:9035 and MetricsPortPolicy accept 127.0.0.1. This exposes a Prometheus-format metrics endpoint. Install Prometheus and configure a scrape job for Tor: configure Prometheus to scrape http://127.0.0.1:9035/metrics. Key Tor metrics available: tor_circuit_opened_total (circuit creation rate), tor_connection_opened_total (connection rate), tor_process_uptime_seconds (Tor process uptime since last restart), and tor_relay_flags (current flags as a bitmask). Create Prometheus alerting rules: alert if tor_process_uptime_seconds resets to 0 (indicating a restart), if bandwidth drops below expected levels, or if tor_relay_flags indicates loss of the Running flag.
Automated Recovery with Systemd
Configure systemd to automatically restart Tor after crashes or stops. Tor's systemd service file already includes Restart=on-failure by default for the official Tor package. Enhance recovery: edit /etc/systemd/system/tor@default.service.d/override.conf (create if not exists) with [Service] then Restart=always (restart on any exit), RestartSec=30 (wait 30 seconds before restart), StartLimitIntervalSec=600 (over 10 minutes), and StartLimitBurst=5 (allow 5 restart attempts). This configuration prevents restart loops while ensuring Tor recovers from transient failures. Test the configuration: systemctl daemon-reload && systemctl restart tor@default, then check systemctl status tor@default. Also monitor disk space (a full disk prevents Tor from writing logs and may cause failures): set up a cron alert when df -h shows /var at 85%+ usage.
Alerting and Notification Configuration
Notification options for relay downtime alerts: (1) email via sendmail or Postfix: configure a simple MTA on the relay server and use mail command in monitoring scripts, (2) Telegram bot: create a Telegram bot via BotFather, get an API token, and use curl to send messages to a private Telegram chat. Simple alert script: if systemctl is-failed tor@default; then curl -s 'https://api.telegram.org/bot/sendMessage' -d chat_id= -d text='Tor relay is down on $(hostname)'; fi. Run this via cron every 5 minutes. (3) UptimeRobot (free): enter the relay's IP and ORPort - UptimeRobot pings the TCP port every 5 minutes and sends email alerts on failure. (4) Prometheus Alertmanager: configure alerting rules in Prometheus that send notifications to email, Slack, or PagerDuty when relay metrics indicate downtime.
Related 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
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.