CPU
Average utilisation across all cores, with sustained warning and critical thresholds.
75% warning · 90% critical · 5 min sustain
Server monitoring
Your website can be up while your server is struggling.
Uptime checks tell you whether your site responds. They don't tell you that your server is running at 95% memory, that MySQL has been restarting every few minutes, or that your disk is nearly full. SiteVitals server monitoring installs with one command and alerts you when a problem lasts, not every time something spikes for a moment.
Available on Marketer from £36.00/month.
What we monitor
The things that tell you how the server is actually coping.
A lightweight agent reports once a minute over HTTPS. It uses under 0.3% CPU per run and around 1.5 MB of network traffic per day.
The important bit
CPU and memory spikes are not treated as incidents straight away. SiteVitals waits to see whether the problem lasts, so a normal burst of activity does not become an alert.
Memory & swap
RAM usage in percentage and GB, with swap tracked separately so slow memory pressure is visible early.
75% warning · 90% critical · 5 min sustain
Disk usage
Root filesystem usage in percentage and GB. Disk problems alert immediately because a full disk rarely fixes itself.
75% warning · 90% critical · immediate
Load average
1, 5 and 15 minute load averages, normalised against CPU core count so thresholds make sense across different server sizes.
1m · 5m · 15m · per-core normalised
Top processes
The busiest processes by CPU are captured with each check, including PID, CPU and memory use, so you can see what was consuming resources.
Captured every check · shown with incidents
Service health
Monitor nginx, Apache, MySQL, Redis, PHP-FPM, Supervisor and other discovered services individually.
Auto-discovery · crash-loop detection · immediate alerts
Agent offline
If the server stops reporting for more than 10 minutes, SiteVitals opens an offline incident and alerts your configured channels.
10 min threshold · recovery alert
How it works
One command to install. Then it looks after itself.
There is no persistent daemon and nothing listening for inbound connections. The agent runs every minute via systemd or cron, sends its readings securely to SiteVitals, then exits.
your server
$ curl … | sudo bash
01
Add the server
Create a server in SiteVitals and copy the generated install command. The API key in that command is scoped to that server only.
Usually less than a minute.
02
Run one command
Paste the command on the server as root. The installer configures systemd or cron, runs its first check and discovers the services already running.
Tested on Ubuntu, Debian, Amazon Linux, CentOS and AlmaLinux.
03
Choose the services that matter
SiteVitals shows the services it found. Recommended ones are pre-selected, and you decide which should be watched.
You can re-run discovery after installing new software.
04
Set thresholds and alerts
Choose warning and critical thresholds, how long a breach must last, and who should be told. Different channels can have different escalation delays.
Email, Slack, webhook and in-app alerts are supported.
The Gap Uptime Monitoring Leaves
Your site returned 200.
Everything else was on fire.
An uptime check confirms your server responded. It doesn't know that the response took three times longer than usual because your database is under pressure. It doesn't know that your disk is 97% full and the next log rotation will bring everything down. It doesn't know that PHP-FPM has restarted eleven times this hour.
Server monitoring gives you the view from inside, the resource utilisation, the process health, the service status, that external checks fundamentally cannot provide. Uptime monitoring tells you when your site goes down. Server monitoring tells you why, and warns you before it happens.
And when something does go wrong, having a minute-by-minute record of what was happening, CPU at 94%, MySQL restarting, load spiking, means you spend time fixing the problem rather than reconstructing what caused it.
💾
The disk that filled silently
Log files grow. Backup scripts run. Uploads accumulate. Disk fills gradually and then all at once, taking down databases, mail servers, and application writes simultaneously. Disk alerts fire immediately with no sustain delay, giving you time to act.
🗄️
The database that kept restarting
MySQL or PostgreSQL restarting repeatedly is often the first sign of a memory exhaustion problem, a corrupted table, or a runaway query. The site may still respond, slowly. Service monitoring catches this pattern before visitors notice.
📈
The load spike that wasn't a spike
A brief high CPU reading is noise. Ten minutes of sustained high load is a problem. Sustained breach detection means you only get alerted when something is genuinely wrong, not every time a cron job runs.
🔧
The service nobody noticed had stopped
A queue worker stops processing. A cache server goes down and requests start hitting the database directly. A mail relay stops accepting connections. None of these prevent your site returning 200, but all of them cause real problems.
Sustained Breach Detection
Alerts that fire when
something is actually wrong.
CPU spikes. Every server has them. A backup job runs, a cron fires, a burst of traffic arrives. These are normal and brief. An alert every time CPU exceeds 75% for thirty seconds is noise, not signal.
SiteVitals only opens an incident when a metric has been continuously above its threshold for the configured sustain period, default five minutes for CPU and memory. Disk alerts fire immediately because a full disk doesn't self-correct. Service alerts also fire immediately.
The result is alerts you can trust. When SiteVitals wakes you up, something is genuinely and sustainably wrong, not a momentary blip that resolved itself before you reached for your phone.
🧠
CPU
warn 75% / crit 90%
5 min sustain
Ignores deploy spikes and cron bursts
💾
Memory
warn 75% / crit 90%
5 min sustain
Catches slow memory leaks before they become critical
📊
Load
warn 75% / crit 90%
5 min sustain
Normalised against core count, consistent across server sizes
🗄️
Disk
warn 75% / crit 90%
Immediate
No delay, a full disk doesn't fix itself
⚙️
Service
warn Down / crit Crash-loop
Immediate
Service stopped or crash-looping alerts fire straight away
🔴
Agent
warn Offline / crit > 10 min
10 min
Agent stops reporting, offline incident opens automatically
All thresholds and sustain delays are configurable per server in Settings → Alert Thresholds.
Things people ask us
If something isn't covered here, just ask us. We're a small team and we answer our own emails.
A single shell script at /usr/local/bin/sitevitals-agent, a systemd timer (or cron job on systems without systemd), and a config file at /etc/sitevitals/agent.conf. No persistent daemon, no open ports, no inbound firewall changes required.
The agent is a plain bash script with no dependencies beyond standard Linux tools. It has been tested on Ubuntu 20.04 and 24.04, Debian 10 and 12, Amazon Linux 2, CentOS 7, and AlmaLinux 8. Any modern Linux distribution should work.
On install, the agent scans your running systemd services and sends the list to SiteVitals. A checklist appears in your dashboard with recommended services pre-selected. You confirm what you want to monitor and save, the agent picks up the change within 60 seconds.
Rather than opening an incident the moment a metric crosses a threshold, SiteVitals waits until it has been continuously above the threshold for a configurable period, default five minutes for CPU and memory. This eliminates false alarms from deployment spikes or traffic bursts. Disk and service alerts fire immediately.
If the agent stops reporting for more than 10 minutes, SiteVitals opens an offline incident and alerts your configured channels. When the server comes back online and the agent resumes reporting, a recovery notification is sent automatically.
Load average is normalised as a percentage of available CPU cores. A load_5 of 1.0 on a single-core server equals 100%, fully utilised. On a 4-core server, a load_5 of 4.0 also equals 100%. This makes thresholds consistent across different server sizes.
Yes, the agent makes outbound HTTPS requests to the SiteVitals API every minute. No inbound connections are required. You need to allow outbound port 443 to sitevitals.co.uk if your server sits behind a firewall.
Very little. The agent consumes under 0.3% CPU per run and approximately 1.5 MB of network traffic per day. It exits completely between runs, there is no persistent process in memory.
This depends on your plan. The Starter plan includes one server, Marketer includes two, and the Agency plan includes ten. Contact us if you need more.
Server monitoring that costs less than an hour of downtime.
Get started with our free tools today. When you're ready for continuous server_monitoring monitoring, our plans are simple, transparent, and built for sites of all sizes.
Plans start from
View All Plans & Features
£36.00/mo