How to see PHP error logs on a local server

PHP error logs are on the Logs page of Server by Zaweba, one for each PHP version it runs. Open the page, choose the log for the version your site uses, and it follows new lines as they arrive, so you can keep it open while you reload your page and watch the errors appear. Apache's and MariaDB's logs sit on the same page.

A log is where PHP writes what went wrong even when nothing shows in the browser. A blank page, a form that seems to do nothing, a redirect that goes nowhere: the reason is usually written down, and the trick is knowing where to look.

One log per PHP version

Server includes PHP 5.6, 7.4, 8.2 and 8.3, and each version keeps its own error log. That separation is useful when sites on different versions run at the same time, because one site's errors don't bury another's. It does mean picking the right one. Check which version the site uses in the sites list, then open that version's log.

If you've just switched a site to a newer version to see how it copes, the newer version's log is where its complaints will be. Deprecation warnings and removed functions show up there first.

Watching errors as they happen

The Logs page follows each log live, adding new lines as PHP writes them. A good routine is to clear the log first (the page can do that), then go to the browser and do the thing that fails, then look back. Everything in the log now belongs to that one attempt, which makes it far easier to read.

Each entry names the message, the file and the line. Start at the first error, not the last. Later ones are often knock-on effects of the first.

If you'd rather open the files yourself, perhaps to search an old log in an editor, the page can open the logs folder.

Errors in the log versus on the page

The PHP page has a display_errors switch for each version, which prints errors into the page itself. That's quick for a page you're looking at. The log is better for everything else: form posts that redirect afterwards, background requests from scripts on the page, anything that fails before the page has a chance to print. Many developers keep both on locally.

The control panel also shows the last lines of each service's log on its card, which is a handy glance, but the Logs page is the place to read properly.

When the PHP log is empty

If the PHP log has nothing and the page still fails, the problem may be earlier in the chain. Apache's error log on the same page records things like a missing file, a rewrite that loops, or a permissions problem, before PHP is involved at all. Apache's request log shows whether your request even arrived and what status it got back.

Database errors may also appear in MariaDB's log, for example when a connection is refused because the server isn't running or the port is different from what your code expects.

Common messages and where they lead

A message about a function that doesn't exist often means an extension isn't turned on. The PHP page lists every extension for that version as a tick box. A message about memory being exhausted or a time limit being reached points to memory_limit or max_execution_time on the same page.

Warnings about undefined variables or array keys won't stop the page, but they tend to grow into real bugs. Clearing them while the log is short is easier than later.

Logs grow over time. Clearing one you no longer need keeps the useful lines easy to find, and with the Logs page in Server by Zaweba it's one click.