The Uptime Monitor is a Rust-based service that monitors multiple endpoints and sends Slack notifications when their status changes. It runs as a systemd service on a Vultr VPS and provides real-time monitoring with metrics collection.

• Code Directory: /root/code/uptime
• Binary Location: /root/code/uptime/target/release/uptime
• Service File: /etc/systemd/system/uptime.service
• Metrics Storage: /root/code/uptime/metrics/uptime_metrics.json

• https://api.populist.us
• https://api.staging.populist.us

• Multi-endpoint monitoring
• Slack notifications for status changes
• Response time tracking
• Uptime percentage calculation
• JSON metrics storage
• Colored console output
• Configurable check intervals and timeouts

sudo systemctl status uptime

sudo systemctl start uptime

sudo systemctl stop uptime

sudo systemctl restart uptime

# View latest logs
sudo journalctl -u uptime -f

# View logs since last boot
sudo journalctl -u uptime -b

# View last 100 lines
sudo journalctl -u uptime -n 100

To modify service settings (like endpoints or intervals), edit the service file:

sudo nano /etc/systemd/system/uptime.service

Current service configuration:

[Unit]
Description=Uptime Monitor Service
After=network.target

[Service]
Type=simple
Environment=SLACK_WEBHOOK_URL=<your_webhook_url>
ExecStart=/root/code/uptime/target/release/uptime "https://api.populist.us" "https://api.staging.populist.us" --interval 60 --timeout 10
Restart=always
RestartSec=10
WorkingDirectory=/root/code/uptime

[Install]
WantedBy=multi-user.target

After any changes to the service file:

sudo systemctl daemon-reload
sudo systemctl restart uptime

Metrics are stored in JSON format at /root/code/uptime/metrics/uptime_metrics.json. The file includes:

• Total checks per endpoint
• Successful checks
• Failed checks
• Total downtime
• Average response time
• Last check timestamp
• Last status

To view current metrics:

cat /root/code/uptime/metrics/uptime_metrics.json

The service sends Slack notifications when:

• Service starts up (initial status of endpoints)
• An endpoint changes status (UP → DOWN or DOWN → UP)

Notifications include:

• 🟢 Green circle for UP status
• 🔴 Red circle for DOWN status
• Timestamp
• Response time (for UP status)

If code changes are made:

cd /root/code/uptime
cargo build --release
sudo systemctl restart uptime

The service accepts these command-line arguments:

• Multiple endpoint URLs (space-separated)
• --interval or -i: Check interval in seconds (default: 60)
• --timeout or -t: Request timeout in seconds (default: 10)

Example manual run:

./target/release/uptime "https://api.populist.us" "https://api.staging.populist.us" --interval 30 --timeout 5

1. Check logs:

sudo journalctl -u uptime -n 50

2. Verify binary exists:

ls -l /root/code/uptime/target/release/uptime

3. Check service file permissions:

ls -l /etc/systemd/system/uptime.service

1. Verify webhook URL in service file
2. Check logs for notification attempts
3. Verify network connectivity to Slack

The service is designed to be lightweight, but if memory issues occur:

1. Check system resources:

top
free -m

2. Restart the service:

sudo systemctl restart uptime

• Regularly check the metrics file size
• Monitor system logs for any errors
• Keep Rust and dependencies updated
• Consider rotating log files if disk space is a concern

• The service runs as root (consider creating a dedicated user if needed)
• Webhook URL is stored in plaintext in the service file
• All monitored endpoints must be HTTPS