Monitoring, resource limits and statistics

#Service monitoring and auto-recovery

The settings live on the Monitoring tab of Server Admin → System → Alerts & Notification Channels. The monitor runs every minute and checks each service at the protocol level, not just whether its process exists:

A crashed (failed) service counts as down immediately; other failures must be confirmed by two checks in a row, so brief blips do not open an incident. With auto-restart on, the service is restarted with backoff: by default at most 3 attempts within a 15-minute window, waiting 1, 2, 4… minutes between attempts. When the attempts run out, the panel gives up and sends an alert. Every outage is recorded as an incident, which closes when the service recovers, and the recovery is reported too.

Some services are never restarted: those an administrator stopped from the panel, those with start at boot disabled, and socket-activated services (being inactive is normal for them). If apt or dnf is running, the restart is postponed because the package manager restarts services itself. A protocol check that has never succeeded does not trigger restarts; it is only noted.

To manage services by hand and see their latest log lines, use Server Admin → Server → Services. On a server installation the logs are read from the systemd unit with journalctl.

#Resource alerts

Resource alerts on the same tab are on by default with these thresholds:

While an alert is active, a reminder goes out every 24 hours by default (0 turns reminders off). You can also exclude mount points you do not want watched. On Docker and Railway installations the load average belongs to the host, so there is no load alert.

#Notification channels

The Notification channels tab decides where alerts go. Each channel has a minimum level (Info, Success, Warning, Error) and a set of categories: service monitoring, resource alerts, security, backups, SSL certificates, updates and license, account quotas and usage, and other system notifications. The tab also shows deliveries sent, failed and pending in the last 24 hours; failed deliveries are retried.

If there is no local mail sender (for example in a container installation), configure an SMTP server for email. Account owners turn on their own notifications under Preferences → Email Notifications in the user panel and choose the minimum level.

#Site monitoring

The Metrics → Site Monitoring page in the user panel checks the account's sites from the server at regular intervals, records outages and notifies the owner. Administrators and resellers see every monitor under Server Admin → Accounts → Site Monitoring. The page is hidden for accounts whose package has site monitoring turned off.

The shortest check interval is 1 minute on Pro and 5 minutes on Community. The timeout ranges from 2 to 30 seconds (default 15), and the number of consecutive failures that opens an outage from 1 to 10 (default 2). Each account can have 10 monitors by default, adjustable per package. Individual check results are kept for 30 days by default (configurable from 7 to 90), daily summaries for 400 days. As SSRF protection, private network and loopback addresses are not checked by default. The administrator can also forward outage notifications to the server's notification channels.

Pro: each account can publish up to 5 public status pages. A page lives at an unguessable address and shows the current state of the chosen monitors, their 90-day uptime and recent outages; target addresses and error details are never shown.

#Resource limits

Limits are set in the package editor and their state is shown under Server Admin → Accounts → Resource Limits. An empty value means unlimited. See Accounts and packages for packages.

#CPU, memory and processes

Each account gets systemd slices: PHP-FPM, Node.js and Python apps run in bipanel-u-<user>.slice, SSH sessions and cron jobs in user-<uid>.slice. Both receive the same limits:

By default every account has its own PHP-FPM master process running in its own slice. The limits require systemd and cgroup v2; if the server runs cgroup v1, the screen shows the kernel parameter to add.

#Disk I/O and file count (Pro)

The Server Admin → Accounts → Disk I/O & File Limits screen is Pro only. It shows per-account read/write speed limits (MB/s, cgroup io.max) and file (inode) limits (at least 1000), and lets you choose the block device the I/O limits apply to (default: the disk holding /home). Setting a new value requires a Pro license; existing values keep working regardless of the license.

#Disk quota

The package disk quota is enforced with file system quotas: setquota on ext4/ext3 and xfs_quota on XFS (user or project quota). The soft limit is the package quota; you can add a percentage margin for the hard limit (default 0) and a grace period after the soft limit is exceeded (default 7 days). Each mount point is detected separately, so extra home volumes such as /home2 added with the Disk Manager get quotas on their own volume. If quotas are not enabled, the screen shows why and the commands that fix it.

#Bandwidth

Monthly bandwidth is the sum of web, mail and FTP traffic. When disk or bandwidth usage passes 90% of the quota and again when it is full, the account owner and the administrator are notified. If the package overage action is suspend, the account is suspended when the quota runs out and reopened automatically at the start of the new month; if the administrator lifts the suspension early, the account is exempt for the rest of that month.

#In a container installation

On Docker and Railway installations per-account cgroup limits and disk quotas cannot be enforced; the platform limits resources and disk usage is only monitored. Apps get only a process count limit. See Docker and Railway for details.

#Web statistics

The Metrics → Web Statistics page in the user panel summarizes visitors, requests, bandwidth, pages, referrers, browsers, countries, status codes and bots; these summaries are calculated even without GoAccess. When the GoAccess component is installed, it adds monthly and yearly graphical reports per domain and an optional live view. Reports are generated as the account user, in a folder in the account's home directory that is not reachable from the web.

Administrators manage server-wide totals and settings under Server Admin → Server → Web Statistics: the report generation hour (default 04:00), the default retention (12 months) and the maximum retention (24 months), the live view and the maximum number of live sessions (default 10).

#Daily process log

Server Admin → Server → Daily Process Log reads the process table every minute and groups it by hosting account. For the chosen day it shows each account's average and peak CPU percentage (100% = one core), memory use and process count. Data is kept for 31 days. The report requires the Linux /proc file system.

#Logs