Logs and monitoring

Site logs

Each site writes to its own directory, owned by the site user:

Rotation is daily, keeping 14 compressed archives (access.log.1, access.log.2.gz …), configured per site in /etc/logrotate.d/<user>. nginx is reloaded after each rotation. Log files under the document root are never served: every server block denies *.log.

The Logs tab

The site's Logs tab shows the last 500 lines of the chosen source, with:

• a source switch: access, error, app (Node.js and Python journal), or docker (compose logs);
• level chips (2xx/3xx/4xx/5xx for access; error/warn/notice for error) and a text filter;
• Older / Newer to step back through rotated days;
• Live, which refreshes every 4 seconds and follows the end;
• select, Copy and Download as <domain>-<kind>-<date>.log.

Node.js, Python and Docker service logs

Runtime processes log to the systemd journal under the site's unit. The journal keeps about seven days by default.

journalctl -u aurapanel-site-example.com -n 200 --no-pager
journalctl -u aurapanel-site-example.com -f            # follow
docker compose -p <project> logs --tail 200            # Docker sites

Panel and update logs

apcli logs          # last 200 lines of the panel daemon
apcli logs -f       # follow
journalctl -u aurapaneld | grep acme       # certificate issuance
cat /var/log/aurapanel-update.log          # self-update runs

Resource history

The panel samples the server once a minute, directly from /proc: CPU (I/O wait counted as idle), load, memory and swap, disk on /, and network bytes on physical interfaces (Docker bridges and virtual interfaces excluded). Samples are kept for six months.

Resources shows windows of 24 hours, 7 days, 30 days and 6 months, each drawn from about 90 aggregated points; the latest point is labelled by its bucket ("last 15 min", "last 2 h") and gaps are shown as gaps, never interpolated. By site attributes CPU and memory to sites by their Linux user every five minutes, and disk by document-root size nightly, with an explicit "other" remainder for nginx, the database engines and the panel, which cannot be pinned to one site.

Site health

The site list shows Online, Provisioning, Degraded, Offline or Stopped, refreshed in the background every 45 seconds from a signal appropriate to the type: the systemd unit state and restart count for Node.js, Python and Docker; the PHP-FPM service for PHP; nginx for static sites; an upstream probe for reverse proxies. The rule is that uncertainty never downgrades a site: only confirmed problems do.

Optional deep checks add specific warnings: a Health check path you set on the site's Backend card is probed on the loopback port ("Health check failing"); a database the panel created but the engine no longer has ("Database missing"); a Node site with package.json but no node_modules ("Deps missing"); and a service the runaway watchdog has flagged ("Worker crash-looping", "Worker high CPU").

Services

Services lists the units the panel is responsible for, with start, stop and restart: nginx, each PHP-FPM version, MariaDB, PostgreSQL, Redis, Docker, Typesense and fail2ban. The panel daemon itself is shown but restarted with apcli restart.

sudo apcli server status
sudo apcli server restart nginx

Runaway service watchdog

Every 45 seconds the panel reads CPU time and restart counts for every systemd service. A service that restarts three or more times in two consecutive sweeps is a crash loop and is automatically throttled to half a CPU core (lifted after about 7.5 minutes of calm) with a persistent back-off drop-in. A service holding 85 percent of a core for four sweeps is reported as a CPU hog with a one-click Throttle, never throttled automatically. The panel daemon, SSH, systemd's own units and D-Bus are never touched.

Administrators receive one email per unit per 24 hours when a watchdog alert is confirmed, if outgoing email is configured. This is the panel's only alerting channel; there are no threshold alerts for CPU, memory, disk or certificate expiry.