Monitoring and Alerts
Host metrics up to 90 days, app traffic, alert rules and incidents.
Agents send host metrics every 15 seconds. The control plane keeps every sample for 7 days and hourly averages and peaks for 90 days, charts them per server and across the fleet, and evaluates alert rules every 30 seconds.
Metrics
- CPU, memory and swap usage
- Disk and inode usage on the root filesystem
- Load average and network throughput
- Services, containers and listening ports (inventory, every 60 seconds)
Server and fleet charts show the last hour, 24 hours, 7, 30 or 90 days; 7 days and longer are drawn from the hourly rollups.
Application traffic
Every site on VPSPilot's proxy writes an access log. Once a minute the agent counts requests per domain (total, 4xx, 5xx, bytes, and p50/p95 latency) and reports the counts, never the requests themselves. Each app's page shows its Traffic over 1 hour, 24 hours or 7 days, for requests through its domains (not its direct port). Counts are kept for 7 days.
Alert rules
VPSPilot ships with a rule for each of these. Change thresholds, durations and severities, or add more rules of the same kinds. Percentage thresholds stay below 100; app error rules count lines; certificate rules take days and backup rules hours (168 suits weekly backups), and those two are checked once rather than over a duration.
How rules avoid noise
- Metric rules average samples over the rule’s duration, so a single spike never alerts.
- They resolve only once the value falls 3 points below the threshold, so values at the edge don’t flap.
- App error alerts resolve after three quiet windows (15 minutes by default), so an app that fails every few minutes is one incident, not a page every time.
- There is at most one open alert per rule and target.
App logging errors
Once a minute the agent reads what each app logged (its container, every service of a Compose app, or its systemd journal) and counts the error lines. The alert says how many there were and shows the latest one, so a Telegram or Slack message tells you what broke.
Output on stderr alone doesn't count, since many apps log everything there. Passwords, tokens and credentials in URLs are masked on the server before the line is sent, and stored lines are encrypted and kept for 7 days. Raise the threshold (for example 20 lines in 5 minutes) for a noisy app, or turn the rule off. Needs agent 1.1.3 or later.
Scanner probes in app errors
Bots scan every server on the internet, and some of their probes leave error lines. Those lines are left out on their own, but only while the app is safe from what the probe looks for. Otherwise they count, so you hear about it.
Uptime checks
Once a minute the control plane requests each live domain's health check path, the way a visitor reaches it: DNS, the proxy, HTTPS and the app. A connection error, timeout, certificate problem or 5xx answer counts as down; a 4xx is up (a login page is a working site). The app's page charts availability and response time over 24 hours, 7 or 30 days, and the Site down rule alerts when checks fail for 2 minutes. When the control plane runs on the same server, these checks don't see network problems between the server and the internet.
High error rate
Uses the request counts from the proxy (see Application traffic): it fires when more than 5% of requests through an app's domains are answered with 5xx over 5 minutes, and only with at least 20 requests in that time, so one failure on a quiet app doesn't page you.
Security updates pending
Agents read pending package updates from apt every 6 hours; each server's page lists them, flags a needed reboot, and has buttons to install security updates, all updates, or reboot. The rule waits 3 days by default, since unattended-upgrades usually installs security fixes overnight. Needs agent 1.1.4 or later.
App resources
Each app page charts its CPU and memory once a minute: a container's own usage, a Compose project's services added up, or a systemd service's cgroup, for an hour, a day or a week. Needs agent 1.1.5 or later.
Errors by cause
The app page's Errors groups error lines by cause: numbers, ids, quoted values and timestamps are left out when comparing, so the same bug is one row with its count, first and last time seen and a 14-day trend. Ignore stops the agent counting it, for the alert too.
Rules for one app
App rules (down, errors, error rate, site down) can be limited to one app when you create them, for example a stricter error rule for your main app, while the default rule covers the rest.
Weekly report
Every Monday at 08:00 (in the timezone set in Settings → Notifications), a summary of the week: uptime per site, deploys, alerts, app errors, backups, disk use per server and pending updates. It goes to the inbox, by email to admins who keep it on, and to alert channels with Weekly report ticked (Telegram included). Send now shows this week's.
Snoozing and maintenance
Alert states
Firing and resolved alerts appear in every admin’s inbox, are emailed to those with alert emails on, and go to any alert channels (Slack, Telegram, webhook) that subscribe to them. See Notifications and Audit.