Service Monitoring

Know the moment nginx stops, MySQL crashes, or PHP-FPM starts cycling — before your users do.

SiteVitals Service Monitoring extends server monitoring with per-service status checks. The agent scans your running services on install, you confirm which ones to watch, and SiteVitals alerts you the moment a service transitions from active to any other state.

Service monitoring is part of the server monitoring feature and requires the agent to be installed. No additional setup is needed — service monitoring is included automatically.

How it works

When the agent installs, it runs a discovery pass — scanning all active systemd services and sending the list to SiteVitals. You then see a checklist in Server Settings → Monitored Services where you confirm which services to watch. Known services like nginx, MySQL, Redis and PHP-FPM are pre-ticked.

On every subsequent check (every 60 seconds), the agent calls systemctl is-active for each monitored service and reports its status alongside the resource metrics. SiteVitals compares the current status against the previous check and opens an incident if anything has changed.

The agent also tracks the systemd NRestarts counter per service. If a service restarts two or more times between consecutive checks, SiteVitals opens a crash-loop warning — even if the service is currently active — because repeated restarts usually indicate an underlying problem that will eventually result in a hard failure.

What gets detected

🔴
Service stopped
Any transition from active to inactive, failed, or dead opens an incident immediately and triggers your alert channels.
Crash-looping
Two or more restarts between consecutive checks triggers a warning — the service is still up but unstable.
Service recovered
When a service returns to active, the incident closes and a recovery notification is sent to every channel that received the down alert.
🔍
Context at failure
CPU, memory, load average, and top processes are captured at the moment a service goes down — so you know whether resource exhaustion was the cause.

Supported services

Any systemd service can be monitored. The following are automatically recognised and pre-ticked during discovery:

Web servers
Nginx
Apache
Caddy
Lighttpd
Databases
MySQL
MariaDB
PostgreSQL
MongoDB
Cache / Queue
Redis
RabbitMQ
Beanstalkd
PHP
PHP 8.3-FPM
PHP 8.2-FPM
PHP 8.1-FPM
Process mgr
Supervisor
PM2
Gunicorn
Search / Mail
Elasticsearch
OpenSearch
Postfix
Dovecot

Services not in this list are still discovered and available to monitor — they just aren't pre-ticked. You can monitor any named systemd service.

Setting up service monitoring

  1. 1
    Install or update the agent
    If the agent is already installed, run sitevitals-agent --discover on your server to trigger discovery manually. On a fresh install, discovery runs automatically.
  2. 2
    Review the discovered services
    Open Server Settings → Monitored Services. You'll see the full list of running services found on your server, with recommended ones pre-ticked.
  3. 3
    Confirm your selection
    Tick the services you want to monitor and click Save Service Selection. The agent fetches the updated list within 60 seconds.
  4. 4
    Service checks begin immediately
    Status is checked on every agent run. The first check that shows a service as inactive or failed will open an incident and alert your configured channels.

Adding services after initial setup

If you install new software on your server after the initial discovery, run a re-scan:

sudo /usr/local/bin/sitevitals-agent --discover

Then refresh the Monitored Services page in SiteVitals — newly discovered services will appear and can be enabled. Existing selections are preserved; the re-scan only adds new services, it doesn't change anything already configured.

Common questions

Does this work with non-systemd servers?

Currently service monitoring requires systemd — it uses systemctl is-active and systemctl show for status and restart counts. SysV init and OpenRC are not currently supported. All modern Ubuntu, Debian, CentOS, AlmaLinux, and Amazon Linux installations use systemd.

Can I monitor nginx and Apache on the same server?

Yes — you can monitor any combination of services. If both nginx.service and apache2.service appear in the discovery list, you can enable monitoring for both independently.

What's the difference between "service stopped" and "crash-looping"?

A stopped alert fires when systemctl is-active returns anything other than active — the service is definitively down. A crash-loop warning fires when the service is currently active but has restarted two or more times since the last check — it's still running, but something is wrong and it's likely to fail again.

Will I get alerted if a service restarts cleanly during a deployment?

A single planned restart won't trigger a crash-loop alert — the threshold is two or more restarts between consecutive 60-second checks. A normal deployment restart registers as one restart and is ignored. If your deployment process restarts a service multiple times in quick succession you may want to pause monitoring temporarily, though in practice this is rarely necessary.

How do I investigate a service failure?

Crash-loop alert emails include the exact journalctl and systemctl commands pre-filled with your service name, so you can paste them directly into your terminal. The SiteVitals server dashboard also shows CPU, memory, and the top 10 processes captured at the moment the incident opened — so you can see whether resource exhaustion was the cause before even SSHing in.