ServerAvatarDocs
Administration

Error log

Internal failures inside the panel's own API — grouped by kind, with the exact command that ran, what it printed, and a reference you can look up.

Admin Panel → Error Log records unexpected failures inside the panel. Not your application's errors — those are in the application's logs — and not your server's, which are in System logs. This is the panel failing to do something it tried to do.

The API error log, grouped by kind

What is and is not recorded

The summary line says it: "Rejected input, sign-in problems and pages that were not found are normal, and are not recorded here." A validation error, a wrong password, a 404 — all expected, none logged. What lands here is the unexpected: a shell command that exited non-zero, an exception, a provider that answered with something unparseable.

Rows are grouped by kind, not listed one by one. A command that failed 27 times is one row that says "27 times", with the first and last occurrence dated. That is what makes the screen readable — a loop that fails every minute would otherwise bury everything else.

Reading an occurrence

Expand a group. Every occurrence is listed, newest first.

An expanded error group

Read the sentence first. Each occurrence leads with a plain-English explanation and, where the panel knows one, the remedy — not a stack trace.

Then the command. The exact command line that was run is shown in a block, with the error it printed underneath, how many attempts were made, and how long it took.

Open Raw response if you need the whole payload the panel received — it is collapsed by default and has its own copy button.

Each occurrence carries its own Reference UUID, the feature it belongs to, the operation name, and the user it happened for.

Look up a reference

When something goes wrong in the panel, the error you are shown ends with a reference — a UUID. So do the failures on the System health page. That reference is the bridge from "it said it failed" to "here is why".

Copy the whole reference from the message. A partial one is rejected with "That doesn't look like a reference. Copy the whole thing from the error message."

Paste it into the reference box and press Look up. The page narrows to exactly that occurrence.

One occurrence, found by its reference

The reference goes into the URL, so a looked-up failure is a link you can send to somebody else with an administrator account on this server.

Clear it with the × in the box to go back to the full list.

If nothing matches, the panel says so rather than showing an empty list — check the reference was copied in full, and that it came from this server rather than another one.

Searching and sizing

The second box searches the error name and the route. The Show selector sets how many of the most recent records are read — the page tells you plainly when there are older ones it is not showing:

Showing the 100 most recent entries. There are older ones that are not on this page.

Limits worth knowing

  • It is a window, not an archive. The page reads the most recent N records. Raising Show widens the window; it does not search the whole history.
  • No severity filter. Everything here is already an unexpected failure; there is no debug/info/warning gradation to filter on.
  • It cannot be cleared from the interface, and nothing here is editable.
  • The Admin Dashboard tile counts kinds, not occurrences, over the last 100 records — "4 recent errors" means four distinct kinds.

On this page