Skip to content

Custom log paths

Patcherly already monitors standard log locations automatically. With a Core or Pro plan you can add extra log files on top of those defaults.

What's monitored automatically

Every site monitors the typical log locations for its connector type right out of the box - no setup needed. For example:

  • WordPress - wp-content/debug.log and common web server error logs
  • PHP - Apache, Nginx, and PHP error logs, plus framework logs (Laravel, Symfony)
  • Python - logs/error.log, app.log, Django and WSGI server logs
  • Node.js - logs/error.log, error.log, app.log, PM2 logs

You can see the full preset list in Dashboard → Sites: expand the site, then Customize next to Monitored Logs (the "Preset log paths" section, shown for every site).

Adding custom log paths (Core and Pro)

If your app writes errors to a non-standard location, you can tell Patcherly to monitor that file too.

  1. Open Sites

  2. Go to your dashboard and navigate to Sites

  3. Open Monitored Logs

  4. Expand your site and click Customize next to Monitored Logs

  5. Add a new path

  6. At the top under Add custom log, enter the log file path (absolute or relative to your app root)
  7. Add an optional description so you remember what it's for
  8. Make sure Enabled is toggled on
  9. Click Add

The connector picks up new paths within a few minutes.

Plan note: Custom log paths require a Core or Pro plan. Preset paths are monitored on all plans.

On WordPress, Get started can detect a custom error_log path in wp-config or theme functions.php (and, if those are empty, the active PHP error_log / string WP_DEBUG_LOG at runtime) and register it when your plan allows. Pairing still never writes wp-config. Get started applies the Patcherly debug snippet only when the site has no logging configured yet; if logging already exists, the snippet is skipped and the custom path is registered instead.

Path formats

Enter the path the same way you'd see it in your server's file system:

/var/log/my-app/error.log
logs/custom-error.log
storage/logs/laravel.log

What's allowed

For your own protection, Patcherly applies a strict policy to every custom log path:

  • Paths must end in .log or .txt, use the Apache/httpd basename error_log, or use rotated names like error.log.1 / error.log.1.gz.
  • Paths must live under one of the allowed roots for your connector type:
  • WordPress - anything inside wp-content/, logs/, or log/, or a single file at the website root like _error_log.log or /_error_log.log (covers WP Engine / Kinsta / shared-hosting SFTP jails - see below)
  • PHP / Python / Node.js - /var/log/, /app/ (container apps), logs/, log/, storage/logs/, app/logs/, or a single file at the application root (e.g. error.log or /error.log). Relative roots also match their absolute form (so app/logs/ accepts /app/logs/error.log).
  • Windows hosts - C:\inetpub\logs\, C:\Windows\System32\LogFiles\, or relative logs\ / log\
  • The connector will not create the log file for you - it must already exist.
  • Up to 32 custom paths per site or app. Need more? Open Support from the bottom of the dashboard sidebar.

Site-root files on shared hosting (WP Engine, Kinsta, etc.)

On managed-WordPress hosts, the SFTP user is jailed to the website root (you don't see the full server filesystem). PHP error logs commonly live at the WordPress install root, so paths like:

_error_log.log
/_error_log.log
debug.log
/debug.log

are accepted. The leading / is read as "website root", not server root: Patcherly resolves it against the WordPress install (ABSPATH). Paths with internal slashes (/etc/passwd.log, /var/data/secret.log) are still rejected.

What's rejected

Patcherly refuses, and your connector will skip, paths that contain:

  • .. (path traversal) - e.g. ../../etc/passwd
  • A leading . in the file name - e.g. .bash_history, .env
  • A scheme prefix - e.g. php://input, phar://..., data://...
  • A NUL byte
  • A Windows reserved device name - CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9
  • UNC paths - e.g. \\server\share\log

If the dashboard rejects a path you save, the error message will name the rule (for example extension, root, or traversal).

Managing log paths

Enable / Disable

  • Enabled - the path is actively monitored
  • Disabled - the path is saved but skipped until re-enabled

Toggle the Enabled switch to pause monitoring without deleting the path.

Edit a path

  1. In the Custom logs section, click Edit on the path you want to change
  2. Update the file path, description, or enabled status
  3. Click Save

Delete a path

  1. Click Remove on the path you want to delete
  2. Confirm the deletion

The path is permanently removed. Preset paths are not affected.

Discovered paths

Your connector automatically reports which log files it can see on the server. In the Monitored Logs modal you'll see a Detected logs section - useful for:

  • Confirming which files are accessible and readable (includes operator preset paths such as web-server logs on VPS hosts)
  • Quickly adding a discovered path as a custom log path with one click

Troubleshooting

My custom log file isn't showing up in errors - Check that the path is correct and the file exists on the server (the connector will not create it for you) - Make sure the path passes the rules above - .log or .txt, under an allowed root, no .., no leading . - Make sure the connector has read permission for that file - Confirm the log path is enabled (not toggled off) - The connector refreshes its path list every few minutes - wait a moment after saving

Save fails with "extension" / "root" / "traversal" / etc. - Your path was rejected by the path-safety rules. Re-read What's allowed / What's rejected above and fix the offending part of the path. - If you genuinely need a log under a non-standard root, open Support from the bottom of the dashboard sidebar so we can review whether the root can be allowed for your account.

I don't see the Custom logs section - Custom logs require a Core or Pro plan. Preset logs are always monitored regardless of plan.

The path shows as "not readable" in Detected logs - The connector can see the file but cannot read it - check file permissions on your server - The connector process must have read access to the log file