Reading Apache, PHP and MariaDB logs in Server by Zaweba

When a page goes wrong, the answer is usually sitting in a log, and Server by Zaweba puts all of them on one page. The Logs page shows Apache's errors, requests and console output, MariaDB's log, Mailpit's log, the error log for each PHP version and the Base import log. It follows new lines as they arrive, can clear a log and can open the logs folder in File Explorer.

Which log to read

Start with the PHP error log for the version your site uses. Fatal errors, warnings and notices land there, with the file and line number. If a page is blank, this is almost always where the reason is. Each PHP version has its own log, so a PHP 7.4 site's errors don't get mixed with a PHP 8.3 site's, and you know which one to look at from the version shown on the site's card.

Apache's error log covers problems the web server itself sees: missing files, permission trouble, rewrite rules that misbehave. The requests log is a line for each request, with the address and the status code, which is the quickest way to see whether a request reached the server at all and what came back. The console output shows what Apache printed while starting and running.

MariaDB's log is the one to read if the database light won't come on, or if something odd happened during start-up or shutdown. Mailpit's log tells you about the mail catcher. The Base import log records what happened when a website exported from Base by Zaweba was imported, step by step.

Watching a log live

Because the page follows new lines as they arrive, you can keep it open beside your browser, reload the page you are working on and watch the error appear. That is often faster than turning display_errors on and off, and it catches errors from requests you can't see, such as the ones a form makes in the background.

Clearing a log

Clearing a log before you reproduce a problem leaves only the lines from that attempt. It is a small habit that saves scrolling through a morning's worth of old warnings to find the one that matters. The open logs folder button is there when you want the raw files, perhaps to send to someone or search with another tool.

How it fits with the rest of the app

The control panel already shows the last few lines of each service's log on its card, which is often enough to see why something stopped. The Logs page is where you go when you need more than a few lines. Between the two, you rarely need to know where the log files are kept.

The PHP page's display_errors switch is the other half of debugging. With it on, errors show in the page itself; with it off, they still go to the PHP error log. Many developers keep it on during development and use the log for problems in requests they don't see directly.

A quick checklist for a broken page

Is the Apache light on in the control panel? Does the requests log show your request, and with what status? Does the PHP error log for the site's version show an error at that moment? If the page uses the database, is MariaDB running, and is there anything in its log? Working down that list in Server by Zaweba usually finds the problem in a minute or two, without guessing.