The server logs page
Thirteen logs the server keeps, in one place, without a shell. Which one answers which question is most of the skill, so this page is mainly a map: what each source holds, and what it deliberately does not.
Where it is
Status & logs, then Server logs.
Choose a source and how many lines, up to a thousand. The default is 200, which is the right size for “what just happened” and too small for “what happened this morning”.
Only sources this server actually has are offered. A server with no mail hosting has no mail log in the list, rather than one that is always empty.
The map
What each source holds.
| Source | What it holds | What it does not |
|---|---|---|
| Panel | The control panel’s own API: every request it refused, and why. | Who signed in. That is Operations, Activity. |
| Privileged agent | The part running as root: anything the panel asked for that it would not do. | Requests that never got that far. |
| Web server | Nginx itself: configuration it refused, and errors belonging to no single site. | One website’s traffic, which is on that website’s Logs tab. |
| Sign-in and SSH | Who signed in over SSH, who failed, and from where. Also sudo and PAM. | Panel sign-ins. |
| Scheduled tasks | The system scheduler. | A website’s own task output, which is on that website’s page. |
| Postfix, Dovecot and the spam filter together, because a refused message usually involves more than one. | Nothing: this is the one place all three appear in order. | |
| Database server | The database: slow starts, refused connections, crashes. | One website’s queries. |
| PostgreSQL | The PostgreSQL cluster: refused connections, slow starts, crashes. | One website’s queries. |
| Authoritative DNS | PowerDNS: what it would not load, and what it would not answer for. | Lookups your own machine makes. |
| Containers | The Docker daemon. | Output from inside a container website. |
| Panel requests | Every request to the panel: who reached it, from where, and what answered. | A website’s traffic. |
| Panel web server errors | What nginx refused or could not reach while serving the panel. | Anything the panel itself logged. |
| File transfer | Who connected over FTPS, what they uploaded or fetched, and when. | SFTP sessions, which are SSH and appear under Sign-in and SSH. |
| Certificates | Issue and renewal attempts. | Which certificate is live, which is on the website’s SSL tab. |
| Installation and updates | What the installer and the updater did, and where either stopped. |
Choosing a source
Four questions and where they are answered.
“The panel is showing an error.” Start with Panel. If it holds nothing for the moment it happened, the request did not reach the panel, so go to Panel web server errors.
“The panel would not do something.” Panel says what it refused and why. If the panel accepted it and the work did not happen, Privileged agent is where the refusal is.
“An email did not arrive.” Mail, which is the only place Postfix, Dovecot and the spam filter appear together in order. A message refused by one of them is usually explained by another.
“Somebody is trying to get in.” Sign-in and SSH for the machine’s own accounts, Panel requests for the panel. Panel sign-ins, successful and failed, are under Operations rather than here.
A worked example
Reading a refusal.
A certificate that will not issue, read from Certificates:
challenge failed for shop.example.com: 404 from http://shop.example.com/.well-known/acme-challenge/ no certificate issued
That is not a certificate problem. The name did not answer on port 80 at this server, so the question moves to DNS and the firewall, and the certificate page is a bystander. The log said which door was knocked on, which is the part worth reading before changing anything.
Two things to know
Reading a log is recorded, and this page is not for a website’s traffic.
Every read is written to the audit record, with who read which source. Reading the authentication log is a legitimate thing to do, and a record of who read what is exactly what an audit trail is for. Expect to see your own reads under Operations.
A website’s own access and error logs are not here. They are on that website, under its own Logs tab, because they belong to the site and because the people who may read them are not the people who may read the server’s. This page is the machine; that page is the site.
When the question is whether the machine is well rather than what it said, start at The health page. When a service will not start, Service settings has its status and its controls beside its settings.