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 Product scope.

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 (target 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 ignore non-bug log noise by default before detection — PHP notice, deprecated, warning, and info lines; runtime deprecation/info prefixes; 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 target 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 target, 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 target-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 Not patchable — 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:

  • A target backup (pre-patch snapshot of your site’s files) is created by the connector before writes, so the change can be rolled back later if needed
  • Fix is applied to your codebase
  • 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 Restarting Your Application)

7. Verification

System verifies the fix:

  • Basic health check (all plans): After apply, Patcherly checks that your target 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).
  • 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.
  • 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 tenant-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 Path rules for targets—monitoring vs patch lists)
  • 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 patch (Not patchable — no Approve/Reject)
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 — check excluded reason for monitoring vs patch list (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
  • Target: Which target it belongs to

Error Filtering

You can filter errors by:

  • Status: New, Ready to Patch, Not patchable, approved, fixed, etc.
  • Target: Specific application
  • Environment: Production, staging, development, or other (from the target 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