Site logs
Tail a site's access, error, and app logs live from the panel — filter/grep client-side, export the window you watched, and resume a killed tail from its exact byte offset with no gap and no duplicate.
The Logs tab on the site workspace tails a site's logs live, straight from inside the instance — no SSH, no log shipper. It's the first thing you reach for when a site misbehaves: drive some traffic, watch the access/error lines appear, grep for the request you care about, and export the exact window you were looking at.
Where it runs
The logs are read inside the instance — there's no copy on the panel server. Your browser holds a short-lived (60s) link that the worker re-checks before streaming you the log. Open the site workspace and the Logs tab.
Sources
The Source dropdown lists the log sources for the site's type. There's no per-site log config — the set depends on the site type:
| Site type | Sources |
|---|---|
| static | Access (nginx), Error (nginx) |
| PHP / WordPress | Access (nginx), Error (nginx), App (php-fpm) |
| Node | App (node) — the app unit's journal |
The nginx access/error sources are files (/var/log/nginx/access.log, …/error.log); the app
sources come from the system journal (php8.5-fpm.service or the Node app unit). The dropdown marks
a source that can't resume after a disconnect as · live (no resume), so you always know what
you're getting (see below).
Live tail
Selecting a source opens the live tail. New lines appear within about a second, with their real timestamps. The tab starts from the current end — you see new lines from now, not a replay of the whole file (so a busy site doesn't dump 50k lines on open).
Log lines can't smuggle terminal escape codes into the page; those are also stripped from anything you export.
Filter / grep
The Filter / grep box narrows the view over the lines already shown:
- a plain substring — e.g.
GET /wp-login - a
/regex/pattern — e.g./5\d\d/for 5xx,/40\d/for 4xx
It only changes what you see, not what's tailed, so you can turn it on and off without losing the stream.
Download window
Download window exports the slice you've been watching:
- For an nginx file source, it exports the exact bytes between when the tail opened and the latest line you've seen — re-read from the file inside the instance, not rebuilt from the browser.
- For a journal source, it exports the most-recent lines instead (a note in the tab tells you).
The file downloads as site-<id8>-<source>-<timestamp>.log. A single export is capped at 25 MiB /
50k lines.
Resume after a disconnect
For a file source, if your connection drops — laptop sleeps, Wi-Fi blips, the worker restarts — the tail reconnects and picks up exactly where it left off. You get no gap (no missed lines) and no duplicates. If the log rotates while you watch, it resyncs to the new file's start.
File sources resume; journal sources don't
Resume is file-only. A journal source (App php-fpm / App node) tails live but can't replay a precise window after a disconnect — it re-reads the most recent lines. That's why those sources are labelled · live (no resume) in the picker.
Permissions
Viewing logs needs SITES_LOGS_VIEW (operator and admin). Access is granted only behind that
permission and is audited; there's no log access without it.
Analytics
SpipCP turns your fleet from a state console into an observability console — real, modern, time-series charts on the dashboard, and on every node, instance, and site.
Site files
A site-scoped file manager — browse, upload, download, and edit small files inside the site's docroot, confined to the site root with server-side traversal guards, a 50 MB upload cap, and an audit row on every write.