InstaWP Docs

Appearance

Where Are My Site's Error Logs? ​

Every InstaWP site writes its own error log and access log, and you can read both with the site's own SFTP or SSH credentials — no support ticket, no extra permissions. This page shows where those files live, what goes into them, how long they are kept, and how to script a read-only health check across several sites.

If you would rather read the logs in your browser instead of over SSH, the dashboard shows the same files under Site Tools → View Logs. See Site Tools.

Let's get started 🚀

Before You Start ​

Turn on SSH/SFTP for the site and copy its Host, Username, Password and Port — see Enable SFTP & SSH.

Your SFTP/SSH user is chrooted to its own home directory, so everything below is written relative to the folder you land in when you connect. You will not see (and do not need) anything outside it.

The Two Log Files ​

Inside your home directory there is a web/ folder containing one folder per domain on the site. The logs live in that domain folder's logs/ directory:

FileWhat it contains
web/<your-site-domain>/logs/<your-site-domain>.error.logPHP fatal errors and warnings, and WordPress database errors.
web/<your-site-domain>/logs/<your-site-domain>.logThe access log — every request, with status code, URL, referrer and user agent.

<your-site-domain> is your site's InstaWP hostname, for example mysite.instawp.site. If you are not sure of the exact folder name, just list it after connecting:

bash
ls web/
ls web/*/logs/

Both files are mounted read-only, so you can tail, grep and copy them, but nothing you run can modify or delete them.

Reading the error log ​

bash
# last 200 lines
tail -n 200 web/mysite.instawp.site/logs/mysite.instawp.site.error.log

# follow live while you reproduce a problem
tail -f web/mysite.instawp.site/logs/mysite.instawp.site.error.log

PHP errors reach this file through the web server, so each line is prefixed with a server tag and the words PHP message:. A typical entry looks like this:

[proxy_fcgi:error] [pid 12345] [client 203.0.113.10:52344] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function my_helper() in /.../wp-content/plugins/my-plugin/init.php:42'

The part you care about is everything after PHP message: — the error type, the message, and the file and line that raised it.

To pull out just the PHP problems:

bash
grep "PHP message" web/mysite.instawp.site/logs/mysite.instawp.site.error.log | tail -n 50

Reading the access log ​

The access log is the right place to count HTTP errors, because a 500 appears here even when nothing was written to the error log:

bash
# count today's 5xx responses
grep -c '" 5[0-9][0-9] ' web/mysite.instawp.site/logs/mysite.instawp.site.log

# see which URLs are failing
grep '" 5[0-9][0-9] ' web/mysite.instawp.site/logs/mysite.instawp.site.log | tail -n 20

How Long Logs Are Kept ​

Logs are rotated by size, not by date:

  • A log is rotated once it reaches 10 MB.
  • 4 rotated copies are kept, compressed (.1.gz, .2.gz, and so on) alongside the live file.
  • Anything older than that is discarded.

So how far back your history goes depends entirely on how much traffic the site gets: a busy site may only hold a few days, a quiet one may hold weeks. If you need longer retention, copy the logs off the server on a schedule — see the health-check example below.

To include rotated files when you search:

bash
zgrep "PHP message" web/mysite.instawp.site/logs/*.error.log*

What Is Not There ​

A few things are worth calling out, because automated tooling often goes looking for them and reports "no readable log" when it doesn't find them:

  • There is no per-site nginx log. InstaWP sites are served by Apache, so the two files above are the per-site logs.
  • There is no per-site PHP-FPM log. PHP errors from your site are already in the error log above, tagged PHP message:. The PHP-FPM master log is server-wide and is not exposed to individual sites.
  • wp-content/debug.log does not exist by default — see the next section.

Turning On WordPress Debug Logging ​

WP_DEBUG and WP_DEBUG_LOG are off by default, which is why wp-content/debug.log is missing on a fresh site. WordPress-level notices (deprecated functions, plugin _doing_it_wrong() warnings, and anything a plugin logs itself) only appear once you enable it.

Add these lines to wp-config.php, above the /* That's all, stop editing! */ comment:

php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG_DISPLAY set to false keeps the errors out of your visitors' browsers and sends them to the log file only. WordPress then writes to:

wp-content/debug.log

That file is inside your site's files, so it is readable — and deletable — over the same SFTP/SSH connection, and it is also shown as Debug Log in Site Tools → View Logs.

⚠️ Debug logging is a troubleshooting tool, not a permanent setting. wp-content/debug.log is not rotated, so on a busy site it can grow without limit. Turn it on to reproduce a problem, then turn it back off and delete the file.

Example: A Daily Health Check ​

Because both files are readable over SSH, you can collect error counts without logging into WordPress at all. The script below checks one site and prints a one-line summary:

bash
#!/usr/bin/env bash
set -euo pipefail

SSH_USER="your-ssh-user"
SSH_HOST="your-ssh-host"
SSH_PORT="your-ssh-port"
DOMAIN="mysite.instawp.site"

ssh -p "$SSH_PORT" "$SSH_USER@$SSH_HOST" bash -s <<EOF
LOGS="web/$DOMAIN/logs"
YESTERDAY=\$(date -d yesterday '+%d/%b/%Y')

fatals=\$(grep -c "PHP Fatal error" "\$LOGS/$DOMAIN.error.log" || true)
errors5xx=\$(grep "\$YESTERDAY" "\$LOGS/$DOMAIN.log" | grep -c '" 5[0-9][0-9] ' || true)

echo "$DOMAIN: \$fatals PHP fatals in current error log, \$errors5xx 5xx responses on \$YESTERDAY"
EOF

Notes for running this across several sites:

  • Use SSH keys rather than passwords so the check can run unattended — see Add & Use SSH Keys.
  • Each site has its own SSH credentials and its own chroot; loop over your sites and run the check once per site.
  • The error log has no per-day timestamp granularity you can rely on for slicing, so counting 5xx in the access log is the more reliable daily signal. Use the error log to find out why those requests failed.
  • If you want history beyond rotation, scp the compressed rotated files off the server as part of the same run.

Docs are open — edit on GitHub. Built with VitePress.

© InstaWP