Server Showing as Offline

When your server appears as offline in the Server Scout dashboard, it typically indicates that our monitoring platform hasn't received data from your server agent within the expected reporting interval. This guide will help you systematically diagnose and resolve the issue.

How Server Scout Detects Offline Status

Server Scout marks a server as offline when no monitoring data is received within the configured reporting interval (usually 2-5 minutes). The agent running on your server continuously collects system metrics and transmits them via HTTPS to our monitoring platform. When this communication breaks down, the server status changes to offline in your dashboard.

It's important to distinguish between a genuinely offline server and one experiencing network connectivity issues. A server may be running perfectly but appear offline due to network problems, firewall restrictions, or DNS resolution failures.

Initial Server-Side Diagnostics

Start by verifying the Server Scout agent is running on your server:

# Check if the agent process is running
ps aux | grep serverscout

# For systemd-based systems, check service status
systemctl status scout-agent

# View recent log entries
journalctl -u scout-agent --since "10 minutes ago"

If the agent isn't running, restart it:

sudo systemctl restart scout-agent
sudo systemctl enable scout-agent

Check the agent's log files for error messages:

# Common log locations
tail -f journalctl -u scout-agent
# or
tail -f /opt/serverscout/logs/agent.log

Firewall Configuration

The Server Scout agent requires outbound HTTPS access on port 443. Verify your firewall isn't blocking these connections:

# For iptables-based systems
sudo iptables -L OUTPUT -v -n | grep 443

# For firewalld (CentOS/RHEL/Fedora)
sudo firewall-cmd --list-all

# For ufw (Ubuntu/Debian)
sudo ufw status verbose

Ensure outbound HTTPS traffic is permitted:

# For iptables
sudo iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

# For firewalld
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

# For ufw
sudo ufw allow out 443

DNS Resolution Issues

DNS problems can prevent the agent from reaching our monitoring servers. Test DNS resolution:

# Test DNS resolution for Server Scout endpoints
nslookup app.serverscout.ie
dig app.serverscout.ie

# Check your DNS configuration
cat /etc/resolv.conf

If DNS resolution fails, try using alternative DNS servers temporarily:

# Test with Google DNS
nslookup app.serverscout.ie 8.8.8.8

# Test with Cloudflare DNS
nslookup app.serverscout.ie 1.1.1.1

Connectivity Verification with curl

Use curl to test HTTPS connectivity to Server Scout's monitoring endpoints:

# Test basic connectivity
curl -v https://app.serverscout.ie/health

# Test with timeout settings
curl --connect-timeout 10 --max-time 30 https://app.serverscout.ie/health

# Test through proxy if applicable
curl --proxy http://your-proxy:8080 https://app.serverscout.ie/health

A successful connection should return a response. Pay attention to SSL/TLS handshake messages and any error codes.

Network Infrastructure Considerations

If your server sits behind a corporate firewall or uses a proxy server, ensure these are configured correctly:

• Proxy servers: Configure the Server Scout agent to use your proxy
• NAT/Load balancers: Verify they're not interfering with outbound connections
• ISP filtering: Some ISPs block or throttle HTTPS traffic on certain networks

Data Spooling During Outages

One of Server Scout's key features is data resilience. When connectivity is lost, the agent automatically spools monitoring data locally. Once the connection is restored, this cached data is replayed to our platform, ensuring you don't lose historical metrics during outages.

You can verify spooling is working by checking the agent's cache directory:

# Check for spooled data files
ls -la /var/cache/serverscout/
# or
ls -la /opt/serverscout/cache/

Next Steps

If these troubleshooting steps don't resolve the issue, check our status page for any ongoing service disruptions. For persistent problems, contact our support team with the agent logs and any error messages you've encountered during these diagnostic steps.