Beyond raw metrics, the agent can watch the software running on your server and alert you when it stops.
Services
In the Services section of a server's page, pick a type, type the name (services found on the server are suggested) and choose Watch:
- Systemd service: for example
nginx,mysqlorphp8.4-fpm. Alertly.Net checks that the unit is active. - Process: a process name, for programs not managed by systemd, such as
nodeor a custom worker.
Set the minimum number of processes to be alerted when, say, fewer than 4 workers are running. You can watch up to 25 services per server.
If a watched service stops or runs too few processes, you get a Service down alert. When it's running again, you get a recovery notice.
Failed systemd units
The Services section also lists any systemd unit on the server that is in the failed state, even ones you don't watch. Open How to check or clear it for the commands that show why it failed. Once it's fixed, sudo systemctl reset-failed <unit> clears it and it disappears after the next report.
Some units fail on healthy servers, like Ubuntu's motd-news.service, which only fetches news for the login message. Use Ignore to hide a unit on that server. Ignored units are listed under the notice, and clicking one shows it again.
Failed units are shown on the page but don't send alerts. Watch a unit above if you want to be alerted when it stops.
Docker containers
Install the agent with --docker (see Installing the agent) and Alertly.Net lists every container with its:
- state (running, restarting, exited and so on) and health check result,
- CPU, memory and network usage,
- restart count, exit code and when it started.
You get a Container problem warning when a container keeps restarting, dies, exits with an error code, stops even though its restart policy is always or unless-stopped, or becomes unhealthy. A container that finishes cleanly doesn't alert.
Muting a container
Some containers are meant to come and go, like one-off jobs or migrations. Click the bell icon (Mute alerts) on the container to stop alerts for it. It keeps showing in the list.
Top processes and listening ports
The server page shows the 10 busiest processes by CPU, plus the 10 using the most memory, and the ports that are listening:
- Open to network: listening on all interfaces or a public address. Make sure your firewall allows only what you intend.
- Local only: bound to localhost, so not reachable from outside.
Processes with the same name and user are grouped, so php-fpm ×6 means six workers. Only process names, users and usage are collected. Command lines, arguments and environment variables never leave your server.
Because the agent runs as its own unprivileged user, it can't see which program owns a port opened by another user, such as nginx or sshd running as root. Those ports are listed without a process name.
Alertly.Net remembers which ports are open to the network. If a new one appears, you get a New open port warning, naming the process when it can. The first report sets the starting list, and local-only ports are ignored.
Pending updates
Every 6 hours the agent asks apt or dnf, read-only, how many package updates are waiting and how many of them are security updates, and checks whether a restart is needed. The server page shows a notice when there are any. Nothing is downloaded or installed.
Security events
Unless you installed with --no-logs, the agent reads the system logs on the server and sends only counts and names, never the log lines or the commands that were run:
- Failed SSH logins: each connection that failed to log in counts once, however many passwords it tried. The server page shows the total for the last 24 hours.
- Out-of-memory kills: when the server runs out of memory, Linux stops a process to recover. The server page shows a notice for a week with the names of the stopped processes.
- Sudo use: how many commands were run with sudo, and by whom. The server page lists who used sudo recently.
- New accounts and admin access: a new user account raises a warning, and someone being added to the
sudo,wheel,admin,rootordockergroup raises a critical User account change alert. - Firewall: the agent checks whether ufw, firewalld, nftables or iptables is on. If a firewall that was on is turned off, you get a critical Firewall turned off alert. A firewall that was never on doesn't alert, since many servers rely on their provider's firewall.
Add the SSH login attack and Process killed for memory rules from the recommended rules to be alerted about them.
System errors
The agent also watches the kernel log for problems that usually mean something is about to break, and raises a System error alert with what to do next:
- Disk errors and a filesystem switched to read-only: the disk may be failing. Check your backups first.
- Hardware errors reported by the CPU or memory.
- Crashes: a process stopped with a segfault or similar fault.
- Stuck processes: a process waited more than 2 minutes, usually for a slow disk.
While an alert is open, the same problem doesn't alert again. System error, User account change and New open port alerts stay open until you resolve them, so you can confirm you've checked. Zombie processes are shown on the server page with the parent to restart, and the Zombie processes piling up rule alerts when they build up. CPU and memory alerts name the busiest process.
Databases and web servers
The agent can report MySQL or MariaDB, PostgreSQL, Redis, nginx and PHP-FPM. Each one is off until you add it to /etc/alertly/agent.yml on the server and run sudo systemctl restart alertly-agent. Credentials stay in that file and are never sent to Alertly.Net.
# MySQL or MariaDB: CREATE USER 'alertly'@'localhost' IDENTIFIED BY '...'; GRANT PROCESS ON *.* TO 'alertly'@'localhost';
mysql_user: alertly
mysql_password: "..."
# mysql_host: 127.0.0.1
# PostgreSQL: CREATE ROLE alertly LOGIN PASSWORD '...'; GRANT pg_monitor TO alertly;
postgres_user: alertly
postgres_password: "..."
# postgres_host: 127.0.0.1
# postgres_database: postgres
# Redis
redis: 127.0.0.1:6379
redis_password: "..."
# nginx stub_status and the PHP-FPM status page, served to 127.0.0.1 only
nginx_status_url: http://127.0.0.1/nginx_status
php_fpm_status_url: http://127.0.0.1/fpm-status
MySQL needs the mysql or mariadb client and PostgreSQL needs psql on the server. Running the install command again keeps these lines.
The server page then shows connections, queries, memory, requests and workers for each one. You get a Database or web server problem alert when one stops answering, when connections or Redis memory reach 90% of their limit, or when every PHP-FPM worker was busy and requests had to wait. The agent's README has an nginx example for the status pages.