A server shows as offline in the Monarx WebApp when the Monarx Agent on that server has stopped checking in with the Monarx Cloud. While it is offline, the server is not reporting new scan results and cannot receive actions from the WebApp.
This almost always comes down to one of two causes:
The
monarx-agentservice is not running on the server (stopped, failed, or never started after install).The server cannot reach the Monarx Cloud because of a firewall, DNS, proxy, or other network restriction.
Work through the checks below in order. All commands must be run as root (or with sudo).
Reason 1: The Monarx Agent is not running
The agent runs as a systemd service called monarx-agent. If it is stopped or has failed, the server will show as offline within a few minutes.
CentOS / CloudLinux / AlmaLinux / Rocky Linux / RHEL
Confirm the agent package is installed:
rpm -qa | grep -i monarx
You should see monarx-agent (and usually monarx-protect). If nothing is returned, the agent is not installed. Follow Monarx Installation.
2. Check the service status:
systemctl status monarx-agent
Look for Active: active (running). If it shows inactive (dead) or failed, continue to the next step.
3. Start the service and enable it at boot:
systemctl enable --now monarx-agent
4. Confirm it stays running:
systemctl is-active monarx-agent ps aux | grep -i [m]onarx-agent
Debian / Ubuntu
Confirm the agent package is installed:
dpkg -l | grep -i monarx
Lines starting with ii mean the package is installed. If nothing is returned, follow Monarx Installation.
2. Check the service status:
systemctl status monarx-agent
3. Start the service and enable it at boot:
systemctl enable --now monarx-agent
4. Confirm it stays running:
systemctl is-active monarx-agent ps aux | grep -i [m]onarx-agent
If the service starts and stays active, wait 5–10 minutes and refresh the WebApp. If it stops again or fails to start, gather the logs as described in the next section.
💡 Tip: If the service fails right after starting, check /etc/monarx-agent.conf. A missing or wrong client_id / client_secret prevents the agent from authenticating with the Monarx Cloud.
Gathering agent logs for Monarx Support
If the agent will not start, keeps stopping, or is running but the server is still offline, the agent logs usually show why. These commands work on all supported distributions.
Show the latest agent log entries:
journalctl -u monarx-agent --no-pager -n 200
2. Show only errors and warnings from the last 24 hours:
journalctl -u monarx-agent --since "24 hours ago" -p warning --no-pager
3. Save the logs and service status to a file you can attach to a ticket:
{ echo "=== Host ==="; hostname; cat /etc/os-release echo "=== Packages ==="; rpm -qa 2>/dev/null | grep -i monarx; dpkg -l 2>/dev/null | grep -i monarx echo "=== Service status ==="; systemctl status monarx-agent --no-pager echo "=== Agent logs ==="; journalctl -u monarx-agent --since "48 hours ago" --no-pager } > /tmp/monarx-agent-debug.txt 2>&1The file is saved as /tmp/monarx-agent-debug.txt.
Contacting Monarx Support
Email support@monarx.com with the log file attached and the following details:
Enterprise ID — shown in the Monarx WebApp for your account
Agent ID (
agent_id) of the affected server — shown on the server's entry in the WebAppOperating system and version (for example, AlmaLinux 9.4 or Ubuntu 22.04)
When the server went offline, and any recent changes (OS upgrade, firewall change, server migration, control panel update)
The output of the commands you already ran from this article
Including these details up front lets our team start investigating right away, without a back-and-forth for basic information.
⚠️ Note: Do not send the contents of /etc/monarx-agent.conf in plain text, as it contains your agent client_secret.
Reason 2: The server cannot reach the Monarx Cloud
The agent can be running and still show as offline if it cannot talk to the Monarx Cloud. The agent opens outbound HTTPS connections (TCP port 443) to api.monarx.com. Anything that blocks or breaks that connection makes the server appear offline.
Common causes:
Outbound firewall rules (CSF, firewalld, iptables/nftables, UFW, or a network firewall upstream) that block outgoing traffic on port 443
DNS problems: the server cannot resolve
api.monarx.comProxy or egress restrictions: the server must go through an HTTP proxy that the agent is not configured to use
TLS inspection: a security appliance intercepts HTTPS and presents its own certificate
Wrong system clock: a time that is far off causes TLS certificate checks to fail
Step 1: Check DNS resolution
dig +short api.monarx.com # or, if dig is not installed: getent hosts api.monarx.com
If nothing is returned, check /etc/resolv.conf and your DNS servers.
Step 2: Test the HTTPS connection to the Monarx API
curl -sv -o /dev/null --max-time 15 https://api.monarx.com/v2/agent/config/default
In the output, look for Connected to api.monarx.com and an HTTP/ response line. A response code means the server can reach the Monarx Cloud. If the command times out, shows Connection refused, Could not resolve host, or an SSL certificate error, there is a network problem between the server and Monarx.
Step 3: Test port 443 directly
If curl fails, confirm whether port 443 is open towards Monarx:
timeout 5 bash -c '</dev/tcp/api.monarx.com/443' && echo "Port 443 open" || echo "Port 443 blocked"
You can run the same test against the Monarx IP addresses listed in How to Whitelist Monarx IPs on Your Server:
for ip in 35.155.66.123 35.155.94.94 44.233.225.38 34.216.8.209 44.245.68.222 52.88.67.19 52.42.56.82; do timeout 5 bash -c "</dev/tcp/$ip/443" 2>/dev/null && echo "$ip:443 open" || echo "$ip:443 blocked" done
If api.monarx.com and the IPs all show blocked, an outbound firewall is very likely the cause.
Step 4: Check the local firewall and system time
# CentOS / CloudLinux / AlmaLinux / Rocky firewall-cmd --list-all 2>/dev/null csf -l 2>/dev/null | grep -i out # Debian / Ubuntu ufw status verbose 2>/dev/null # All systems iptables -S OUTPUT timedatectl
In CSF, make sure port 443 is listed in TCP_OUT in /etc/csf/csf.conf. In timedatectl, confirm System clock synchronized: yes.
Fixing it
Allow outbound TCP 443 to api.monarx.com (and the Monarx IPs above) in your firewall, then restart the agent:
systemctl restart monarx-agent
If the server must use a proxy, or your network team can only allow specific destinations, contact support@monarx.com with the output of Steps 1–4 and the details listed in the previous section.
Quick checklist
monarx-agentpackage is installedsystemctl is-active monarx-agentreturnsactiveAgent logs show no authentication or connection errors
api.monarx.comresolves and answers on port 443Outbound TCP 443 is allowed in the server and network firewalls
System clock is synchronized
Still offline after all of these? Email support@monarx.com with your Enterprise ID, the server's agent_id, and the /tmp/monarx-agent-debug.txt file.