Skip to content

Understanding Errors

Patcherly automatically detects and categorizes errors in your applications. This guide explains how errors work and how they're processed. For what Patcherly is and is not (workflow vs 24/7 monitoring), see What Patcherly is (and is not).

What Are Errors?

Errors in Patcherly are:

  • Exception events caught by your application
  • Error logs from your application's logging system
  • Runtime failures detected by connectors
  • Application crashes or unhandled exceptions

Error Lifecycle

1. Detection

Errors are detected automatically by connectors (site log monitoring on your stack - log paths, queues, exclusions - then error detection to Patcherly; this is the raw event stream, not the same thing as the dashboard Metrics page, which shows business outcomes for those events):

  • Connectors watch configured logs and capture events in real time
  • Connectors (and the API as a backstop) ignore non-bug log noise by default before it becomes an Errors row: PHP notice, deprecated, warning, and info lines (including nginx/php-fpm wrappers); Python/Node deprecation warnings; hosting audit lines (for example auditor:scan fingerprint scans); and other lines with no real failure markers. Kept: PHP fatals/parse errors, uncaught exceptions, Python Traceback / ValueError-style type lines, Node unhandled rejections, stack frames, JSON "level":"error", and messages containing words like failed or critical (but not bare “runtime” on its own).
  • On WordPress, the optional Emergency Rescue logger can also capture PHP fatals during early plugin load (before your custom log path may see them). The dashboard shows one canonical message per underlying error: Rescue-wrapped and plain PHP lines are deduplicated when they describe the same bug.
  • Source labels (WordPress only): when you open the full error text, Rescue-captured lines are signed (Patcherly Emergency Logger) so you can tell the site was down and Rescue detected the log. Errors from the main plugin's normal log tail while the site is running may show (Patcherly Advanced Logger). The list view shows only the short headline.
  • When an error occurs, the connector captures:
  • Error message and stack trace
  • Context (file, line number, function)
  • Request details (if available)
  • Timestamp

2. Path requirement

The connector sends the error to Patcherly only when the log line includes an extractable source file path (needed for backup and patching). Lines without a file path are dropped on the connector - they are usually log noise, not actionable bugs.

  • Error is stored in the database
  • Assigned a unique error ID
  • Associated with your site and workspace

3. Start AI Analysis

Before AI looks at an error, analysis must be started:

  • Manual (default on every plan): click Analyze with AI on a pending error in the Errors page. The error moves from Pending to Pending analysis and AI analysis begins.
  • Auto-analysis: if your plan includes auto-analysis and the Auto-Analysis toggle is on for the site, errors skip the manual click and go straight to AI analysis. See Auto-Analysis for details.

4. AI Analysis

AI analyzes the error:

  • Examines the error message and stack trace
  • Understands the code context using site-specific context when available
  • Selects the appropriate AI prompt template for the language and framework
  • Generates a fix suggestion
  • Provides confidence score (0-100%)

After analysis finishes: - Ready to Patch / Manual review - AI produced a draft you can Approve, Reject, or Mark as manually fixed - Analyzed with a Not patchable badge in Status - analysis finished without a draft (missing context, model declined, or empty fix). Approve / Reject / Hide stay hidden; use Mark as manually fixed or Delete (Re-analyze is not offered on Not patchable)

You can see analysis details (template used, context files, model-requested paths, whether a Core/Pro context follow-up ran, analysis time) in the error detail panel.

Analysis attaches up to 3 FILE CONTEXT excerpts on the first pass (traceback frames and shallow related-path hints). On Core and Pro, if the model declines for insufficient context and names 1 - 2 extra project-relative files, Patcherly may fetch them once and re-analyze once in the same job; Personal stays single-pass.

5. Fix Approval

You review the fix proposal stored on the error record (there is not a separate “patch” object in the dashboard - approve and reject apply after analysis; ignore and delete handle pre-analysis cleanup):

  • Confidence check: Each fix has a confidence score. Patcherly enforces an app-wide minimum for applying fixes (default 90% - a guardrail for your workspace). If confidence is below that threshold, the dashboard asks you to confirm before applying - so “one click approve” only applies when policy and confidence allow it. Contact support if your organization needs a different default.
  • When a draft exists (Ready to Patch, Manual review required): Approve, Reject patch, or Mark as manually fixed - Hide is not available
  • Not patchable (Analyzed without a draft): Mark as manually fixed or Delete - no Approve / Reject / Hide / Re-analyze
  • Before analysis (Pending, Pending analysis, Analysis failed, Excluded): Hide Error & Ignore or Delete - no reject-patch button
  • After apply (Failed, Rolled back, etc.): Hide Error & Ignore tidies the list without changing rollback/fix metrics

6. Application

If approved, the fix is applied:

  • The connector checks that the live files still match what the fix expects. If they do not, it does not change files or create a backup; the error returns to Analyzed with an orange Stale patch badge (use Mark as manually fixed or Delete)
  • When the check passes, a site backup of the files about to change is saved on your server, then the fix is written
  • Patcherly coordinates verification (health/tests per your plan)
  • Restart or refresh may be required: Python and Node.js apps usually need a process reload or restart; PHP apps may need a cache clear, OPcache reset, or composer dump-autoload (see Restart after a fix)

7. Verification

System verifies the fix:

  • Basic health check (all plans): After apply, Patcherly checks that your site URL responds and is not 5xx or unreachable. If this fails, the fix is automatically rolled back (included on every plan).
  • Enhanced checks (Agent Testing plan): If your plan includes Agent Testing, tests run and health score is monitored; critical failure can trigger automatic rollback.
  • If any of these checks fail, the fix can be automatically rolled back.

When a fix does not work out (failed apply, rollback, or you indicate the patch was wrong), Patcherly records that outcome in your workspace. On Core and Pro plans (the Patch Learning feature), prior outcomes are then injected as context into future AI analysis so the model can avoid proposing very similar patches again. On the Personal plan, outcomes still accrue - they just don't feed new analyses until you upgrade. This is in-product, per-workspace pattern recognition, not training third-party commercial AI models on your codebase. See How Patcherly learns from outcomes.

Error States

In the dashboard (plain language)

  • New / Pending: Just detected - Analyze with AI, Hide Error & Ignore, or Delete (unless auto-analysis handles analysis)
  • Pending analysis: Queued for AI: sky-blue badge with a short pulse (same waiting motion family as Waiting for connector)
  • Analyzed / Ready to Patch / Manual review: Ready to Patch and Manual review are draft-ready (Approve available). Bare Analyzed with Not patchable means no draft - use Mark as manually fixed or Delete (no Re-analyze). Analyzed with red Bad patch means you rejected the draft as wrong (or the draft was empty) - Approve stays hidden; use Re-analyze for another attempt when you want one. Analyzed with orange Source changed means the file on the site no longer matched what was logged when analysis ran. Stale patch means the same kind of mismatch when you tried to apply. In both cases use Mark as manually fixed or Delete (Re-analyze is not offered).
  • Suspicious: Red quarantine flag (not a workflow status) - do not approve or apply until Patcherly Staff clears it; see Quarantined patches
  • Approved / Applying / Patched: On the way through or successfully patched. Waiting for connector / Applying / Rolling back use the same stage colors as success or rollback, with a short pulse or spin so they read as in progress. With Repo Pull Requests, Awaiting PR merge means a GitHub PR is open and waiting for merge (not writing on the site yet).
  • Failed / Dispatch failed / Apply stalled / Rolled back / Rollback failed: Apply or rollback did not complete cleanly - follow the error detail and rollback guidance. Failures stay red.
  • Analysis failed: AI could not complete after retries - a short customer-safe reason may appear; use Retry analysis, Hide Error & Ignore, or Delete. While retries are still scheduled you may see Retrying analysis (n/max).
  • Excluded: Path or policy rules excluded this error from the normal pipeline (see Site paths - monitoring vs patch lists). When the log clearly shows a schema mismatch, database connection, disk, out-of-memory / exhaustion, or timeout pattern, Errors may show a short cause tip beside Excluded. Patcherly does not fix database schemas or memory issues; those tips point you at work outside the product.
  • Ignored (Hide vs Reject patch → not needed): Same Ignored list status covers two paths - Hide (pre-analysis or post-apply cleanup) vs Reject patch → not needed (counted in metrics as ignored after reject)

Status slugs (technical reference)

Advanced users, filters, and exports use lowercase slugs such as:

Slug Meaning
pending Detected; not yet in analysis
pending_analysis Analysis queued (pulsing waiting badge); may show Retrying analysis (n/max)
analysis_failed Analysis exhausted retries
analyzed Analysis finished without a draft (Not patchable), Bad patch after you rejected a wrong draft (Re-analyze available), or Source changed / Stale patch when the live file no longer matched (Mark fixed / Delete only)
awaiting_approval Ready to Patch - review the draft fix before approving apply
manual_review_required Human decision required (e.g. policy / redaction)
approved / applying / fixed Patch lifecycle (approved waiting / dispatch phases shown as labels on the same slug; fixed badge reads Patched)
failed Apply failed
rolling_back Rollback in progress (waiting motion)
rolled_back / rollback_failed Rollback outcomes
dismissed Read-only compatibility status (no new writers)
manual Read-only compatibility status - Mark as manually patched writes fixed, not this slug
ignored Hidden from the default list - either pre/post-apply Hide (no KPI for pre-analysis hide) or Reject patch → not needed (metrics: ignored after reject)
excluded Path rules - history shows Monitoring vs Patch path rule labels; may add a short cause tip when the log matches a known schema/DB/disk/memory/timeout pattern (see path rules doc)

Your workspace's Errors filters show the statuses that matter to you.

Error Information

Each error includes:

  • Error ID: Unique identifier
  • Message: Error message/exception type
  • Stack Trace: Full stack trace
  • File & Line: Where the error occurred
  • Timestamp: When it was detected
  • Occurrences: How many times it happened
  • Severity: Error severity level
  • Site: Which site it belongs to

Error Filtering

You can filter errors by:

  • Status: New, Ready to Patch, Not patchable, approved, fixed, etc.
  • Site: Specific application
  • Environment: Production, staging, development, or other (from the site label)
  • Date range: Created date on the loaded list (up to 200 rows per page load)
  • Severity: Error severity
  • Error type: Exception type
  • Search: Message, status, file path (fix_path), language, framework, and environment text

Next Steps