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
Supported services
Any systemd service can be monitored. The following are automatically recognised and pre-ticked during discovery:
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
Install or update the agentIf the agent is already installed, run
sitevitals-agent --discoveron your server to trigger discovery manually. On a fresh install, discovery runs automatically. -
2
Review the discovered servicesOpen Server Settings → Monitored Services. You'll see the full list of running services found on your server, with recommended ones pre-ticked.
-
3
Confirm your selectionTick the services you want to monitor and click Save Service Selection. The agent fetches the updated list within 60 seconds.
-
4
Service checks begin immediatelyStatus 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:
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.