Tor Relay Uptime and Stability: Earning Stable and Guard Flags

The Stable flag is assigned when a relay's Weighted Time Between Failure (WTBF) is greater than the median WTBF of all relays currently in the consensus. WTBF accounts for both the frequency and duration of outages. A relay that has been running for 30+ days with minimal downtime typically earns Stable. The Guard flag requires: Stable flag, bandwidth greater than the median observed bandwidth of all relays (approximately 2-4 Mbit/s as of 2026 depending on network conditions), and fractional uptime greater than 98%. Guard flag thresholds are dynamic - they adjust based on the overall network. New relays take a minimum of 8 days to be considered for Guard even with perfect uptime. Once earned, Guard flag is maintained as long as the relay continues meeting the requirements.

Configure systemd to automatically restart Tor if it crashes. In /etc/systemd/system/tor.service.d/override.conf: [Service], Restart=on-failure, RestartSec=5, StartLimitIntervalSec=300, StartLimitBurst=5. This restarts Tor within 5 seconds of a crash, up to 5 times in 5 minutes before systemd gives up. The StartLimitBurst prevents infinite restart loops if Tor keeps crashing (indicating a persistent configuration or resource issue requiring manual intervention). Enable the override: systemctl daemon-reload && systemctl restart tor. Verify auto-recovery by simulating a crash: kill -9 $(pidof tor), then watch systemctl status tor and verify it restarts within 10 seconds.

Kernel updates, disk maintenance, and other planned reboots cause downtime that reduces relay uptime statistics. Minimize reputation loss with graceful shutdown procedures. Before rebooting: signal Tor to close new circuits without accepting new ones: tor --hup (SIGHUP reloads config without restarting). To inform the network: edit torrc to add MaxAdvertisedBandwidth 0 KB (tells directory authorities the relay is not accepting circuits, removes it from path selection). Wait 30-60 minutes for existing circuits to expire. Then safely reboot. After restart: remove MaxAdvertisedBandwidth 0 from torrc and reload Tor. This reduces the impact of planned reboots on the relay's WTBF statistics compared to an abrupt crash.

VPS provider issues (hypervisor maintenance, hardware failures, network disruptions) are the primary cause of relay downtime beyond operator control. Proactive monitoring: run a monitoring agent that checks Tor process status and connectivity every 60 seconds. Alert via Telegram bot or email when Tor is not responding. For VPS providers that occasionally perform live migrations (pause-migrate-resume), Tor's circuit state may be corrupted post-migration causing brief confusion even without a full restart. Verify Tor log after any known provider maintenance window. For critical relay infrastructure: choose VPS providers that give advance notice of maintenance windows and guarantee live migration support. Monthly uptime SLAs of 99.9% (8.7 hours downtime/year) are the minimum for maintaining Stable flag; 99.99% (53 minutes/year) is needed for consistent Guard flag.

Tor's log provides diagnostic information about stability issues. Key log patterns to monitor: WARNING level messages indicating circuit build failures (may indicate introduction point or network issues), NOTICE 'Self-testing indicates your ORPort is reachable from the outside' (healthy - confirms relay is accepting connections), ERROR messages (warrant investigation), 'Bootstrapped 100%' after restart (confirms successful Tor network connection). Log analysis with grep: grep -E 'WARN|ERROR' /var/log/tor/notices.log | tail -50 shows recent warning and error messages. For long-term trend analysis, forward Tor logs to a log aggregation system (ELK Stack, Loki with Grafana) to query for uptime correlation with specific error patterns. Tor's --list-torrc-options can verify configuration syntax without restarting.