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 ingestion 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
  • When an error occurs, the connector captures:
  • Error message and stack trace
  • Context (file, line number, function)
  • Request details (if available)
  • Timestamp

2. Ingestion

The connector sends the error to Patcherly:

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

3. Analysis Approval

Before AI looks at an error, the error needs the green light for analysis:

  • Manual approval (default on every plan): click "Approve for Analysis" on a pending error in the Errors page. The error moves from Pending to Pending analysis.
  • Auto-analysis: if your plan includes auto-analysis and the Auto-Analysis toggle is on for the target, errors skip this step 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, the error status becomes Analyzed — AI has a fix proposal ready for you. You can see the analysis details (template used, context included, analysis time) in the error detail panel.

5. Fix Approval

You review the fix proposal stored on the error record (there is not a separate “patch” object in the dashboard — approve, dismiss, and ignore apply to the error workflow):

  • 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.
  • Manual choice: Approve, dismiss, or ignore the fix when you are ready
  • Ignore: Mark the error as ignored (it won't be fixed)

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; may need Approve for Analysis unless auto-analysis handles it
  • Pending analysis: Queued for AI
  • Analyzed / Awaiting approval: A fix proposal exists—review before applying
  • Manual review required: A sensitive or policy case needs a human decision before promotion
  • Approved / Applying / Fixed: On the way through or successfully patched
  • Failed / Rolled back / Rollback failed: Apply or rollback did not complete cleanly—follow the error detail and rollback guidance
  • Analysis failed: AI could not complete after retries—you can retry or dismiss
  • Excluded: Path or policy rules excluded this error from the normal pipeline (see Path rules for targets—monitoring vs patch lists)
  • Ignored / Dismissed: You chose to stop work or skip this suggestion

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 or running
analysis_failed Analysis exhausted retries
analyzed Fix proposal available
awaiting_approval Ready for your review (wording varies slightly in the UI)
manual_review_required Human decision required (e.g. policy / redaction)
approved / applying / fixed Patch lifecycle
failed / rolling_back / rolled_back / rollback_failed Apply or rollback outcomes
dismissed / ignored You stopped work on this error
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. Patcherly may use additional internal states when viewing the service as a whole; your list stays focused on your organization’s errors.

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, analyzed, approved, etc.
  • Target: Specific application
  • Date Range: Time period
  • Severity: Error severity
  • Error Type: Exception type

Next Steps