Skip to content

Site paths: exclusions and monitored logs

Control which files Patcherly watches for errors, which paths it may patch, and which log files the connector reads.

Three layers of path protection

Layer What it does Who sets it
Always-excluded paths Never monitored or patched (system files, .env, connector folders, node_modules / vendor, build output, and similar). Patcherly (built-in)
Monitoring exclusions Hides errors from matching paths in Errors. Useful for third-party noise. You - all plans
Patch-only exclusions Errors can still show, but Patcherly will not approve or hand out a fix that touches these paths (including secondary files in a multi-file patch). You - Core and Pro

See the full always-excluded list under Sites → expand the site → Patch exclusion paths → Customize → Preset exclusions (read-only).

Monitoring exclusions

Open Sites, expand the site, Customize next to Monitoring excluded paths. Add glob patterns (for example **/vendor/**), save. The connector picks up changes within a few minutes.

An error is hidden when either the throw site or the patch candidate path matches. For WordPress, that candidate is often a plugin or theme even when core appears in the stack.

Patch-only exclusions (Core and Pro)

Customize next to Patch exclusion paths. Use for heavily customised code or areas only humans should change.

Tip: To hide a path completely (no errors, no fixes), add it to both lists. Monitoring exclusions take priority when both match.

Troubleshooting exclusions

  • Errors still appear: wait a few minutes or restart the connector; check the pattern matches the path as shown on the error; confirm you saved the right site.
  • Error visible but no fix: check patch-only exclusions and Preset exclusions.

Monitored logs

Connectors watch standard log locations for their type automatically (for example WordPress wp-content/debug.log). Presets are available on all plans.

Custom log paths (Core and Pro)

  1. Sites → expand the site → Customize next to Monitored Logs.
  2. Under Add custom log, enter a path (absolute or relative to the app root), optional description, keep Enabled on, then Add.
  3. Manage under Custom logs. Detected and Preset sections are inventory only.

The modal order: Add custom log → Custom logs → Detected logs → Preset logs.

On WordPress, Get started can detect a custom error_log path when your plan allows. Pairing never writes wp-config.php.

Path safety (custom logs)

  • Must end in .log / .txt, use basename error_log, or rotated names like error.log.1.
  • Must live under an allowed root for your connector (for example WordPress: /var/log/, wp-content/, logs/, or a single file at the site root such as _error_log.log on shared hosts).
  • Rejected: .., leading-dot filenames (.env), schemes (php://), UNC paths, Windows device names.
  • The file must already exist; up to 32 custom paths per site.

If save fails, the message names the rule (extension, root, traversal, etc.). Need a non-standard root? Open Support.

Managing custom logs

Toggle Enabled to pause without deleting. Edit / Remove under Custom logs. Preset paths are not deleted.

Detected logs shows files the connector can see - useful to confirm readability and add a path in one click.

Troubleshooting logs

  • Path correct, file exists, plan allows custom logs, Enabled on, connector has read permission.
  • Wait a few minutes after save for the connector refresh.
  • "not readable" in Detected logs means the process cannot read the file - fix OS permissions.