Approving Fixes¶

After Patcherly analyzes an error and generates a fix, you need to approve it before it is delivered (applied on your site, and/or opened as a GitHub PR when the site uses Repo Pull Requests). This guide explains the approval workflow.

Two types of action in the workflow¶

Patcherly has two separate human steps in the error workflow. Knowing the difference makes the rest of this page (and auto-analysis vs auto-apply) much easier:

Starting analysis (Analyze with AI)¶

• When: the error is Pending (just detected).
• What it does: queues AI analysis. After you click, the error becomes Pending analysis while AI works on a fix suggestion.
• How: click Analyze with AI on a pending error in the Errors page.
• Auto-analysis skips this click: if your plan includes auto-analysis and it's turned on for the site, errors move straight to analysis. See Auto-Analysis and the Pricing page.

Patch approval (Approve patch)¶

• When: the error is Ready to Patch or Manual review (AI has generated a draft patch). Bare Analyzed with a Not patchable badge in Status means analysis finished without a draft: Approve / Reject stay hidden; use Mark as manually fixed or Delete (Re-analyze is not offered on Not patchable).
• What it does: approves the suggested patch so Patcherly can deliver it. On the default Live Patch method the error becomes Approved, then Applying, then Patched if the apply succeeds. With Repo Pull Requests, PR Only goes to Awaiting PR merge instead.
• How: review the patch details and click "Approve" (described below).
• Auto-apply skips this step: when your plan includes the auto-apply feature and the per-site Auto Apply toggle is on (and the other conditions in the auto-apply section below are right), Patcherly approves the patch on your behalf and the connector applies it without your click.
• After approve: on the default Live Patch method, the status moves to Waiting for connector or Applying. If the connector was still waiting on analysis when you approved, it continues and applies - it does not stay stuck on “Waiting for connector”. With Repo Pull Requests, PR Only shows Awaiting PR merge until the GitHub PR is merged or closed; Live Patch + Repo PR still applies live via the connector. If analysis has no usable patch, Approve is hidden in the dashboard (and returns 409 empty_fix if called anyway); connectors report empty_fix and stop cleanly. If Patcherly cannot reach your site (live apply), you will see a red Dispatch failed / Apply stalled badge - use Retry Patch. The Errors page legend (Show all) lists these badges by workflow stage. If the connector reported a failed apply, open History on that error to see a red banner with the precise failure message - that banner is suppressed after a later successful patch (older failures remain in History only).

These two steps are independent: clicking Analyze with AI does not approve the resulting patch. The patch has its own safety rail - a minimum confidence check, explained below.

Fix Approval Workflow¶

Step 1: Review the Fix¶

When a fix is ready for review:

1. Navigate to Errors in your dashboard
2. Find the error with status Ready to Patch (or Manual review)
3. Click on the error to view details
4. Review the fix suggestion

Rows marked Not patchable (Analyzed without a draft) do not show Approve - use Mark as manually fixed or Delete.

Step 2: Understand the Fix¶

The fix details show:

• What will change: Files and code that will be modified
• Confidence score: AI's confidence in the fix (0-100%)
• Explanation: Why this fix was suggested
• Impact: What the fix will do

Step 3: Make a decision¶

Minimum confidence - the safety rail¶

Every fix comes with an AI confidence score from 0 to 100%. Your workspace has a minimum confidence set by Patcherly (default 90%) - a built-in guardrail that prevents low-confidence fixes from applying silently. If your plan includes auto-apply, the workspace owner can optionally raise that bar even higher for their own approvals on Profile → AI. The override only matters at the auto-apply gate, so it's hidden on plans that don't include auto-apply.

If a fix is below the threshold:

• The dashboard asks you to confirm before you approve or accept it (this also covers some bulk actions).
• Patcherly will not auto-approve a low-confidence fix on its own - you have to approve it manually in the dashboard.
• On live (non - dry-run) sites, you may get an email or in-app notice depending on your notification settings.

If a fix is at or above the threshold and your plan includes auto-apply with the Auto Apply toggle on for that site (and the other conditions below), Patcherly may auto-apply it (see the next section).

Custom scripts or external tooling - the dashboard's confirmation rules are the safety floor. Any other automation talking to your workspace must respect the same minimum-confidence guardrail.

Approve¶

Click "Approve" to:

• Queue the fix for application
• Fix will be applied automatically
• Backup created before application
• System monitors the result

Note: After a fix is applied, you may need to restart your application for the changes to take effect. See Restart after a fix for details.

Reject patch¶

After AI analysis, click Reject patch to open a modal. You must pick an outcome before anything is saved - closing without a choice does nothing.

For Pending errors you have not analyzed yet, use Hide Error & Ignore (hide, restorable) or Delete (remove the record; it may reappear if the bug still fires on the site).

Mark as manually fixed¶

On post-analysis errors, Mark as manually fixed (orange hand icon) is a separate two-choice modal (Patcherly suggestion vs own code). It does not chain through reject. Use it when you fixed the issue without applying the AI patch. The row stays Patched with the same orange Manually fixed badge as reject-then-manual.

Hide Error & Ignore (pre-analysis and post-apply only)¶

Hide Error & Ignore is available on pre-analysis rows (Pending, Pending analysis, Analysis failed, Excluded) and on post-apply rows (Failed, Rolled back, Rollback failed) to tidy your list.

Click Hide Error & Ignore to:

• Mark the error as Ignored in the list (restorable via Unignore)
• Upsert an ignore pattern so the same signature does not auto-analyze again
• Pre-analysis hide does not increment Business Metrics totals; post-apply hide keeps your rollback/fix metrics unchanged

Not available after analysis when a fix proposal exists (Ready to Patch, Manual review). Use Reject patch or Mark as manually fixed instead. Bare Analyzed with Not patchable has no Reject or Hide - use Mark as manually fixed or Delete. After you reject a draft as wrong, the row stays Analyzed with Bad patch - use Re-analyze, Mark as manually fixed, or Delete. After Source changed or Stale patch (orange badge), use Mark as manually fixed or Delete only - Re-analyze is not offered.

Auto-apply: when Patcherly delivers a fix without your click¶

Auto-apply is when Patcherly approves and delivers a fix on your behalf, without you clicking Approve the Fix in the dashboard. Delivery follows the site Connected repositories mode (live apply and/or a GitHub PR). Auto-apply itself is a separate Pro feature with its own per-site toggle, independent from auto-analysis.

Auto-analysis vs auto-apply¶

The baseline path is always available on every plan: analyse → you approve the fix in the dashboard → the connector applies (unless the site uses Repo Pull Requests in PR-only mode). Auto-apply is an optional Pro layer on top, independent from auto-analysis - a workspace can have auto-analysis ON and still keep auto-apply OFF if it wants every approve to go through the dashboard.

When auto-apply happens¶

Patcherly only delivers a fix without your click when all four of these are true:

1. Auto Apply is on for the site. The new per-site toggle (Sites page → expand row → Auto Apply). Requires your plan to include auto-apply.
2. Auto Analysis is on for the site. Auto-apply only chains in after an auto-analysed fix; if auto-analysis is OFF, the connector pauses for your Analyze with AI click and won't reach the apply step automatically anyway.
3. Dry-run is off for the site. Sites in dry-run still run the full automated pipeline, but the actual file write becomes a preview - nothing changes on disk. The dashboard surfaces a hint when Auto Apply is ON and dry-run is still ON so you know you'll only see previews.
4. The fix's confidence is at or above your workspace minimum (default 90%). Below that, Patcherly pauses for manual approval - exactly like the baseline path. The automatic ingest pipeline stops quietly on 409 low_confidence_confirmation_required and waits for review. A manual Approve click in WordPress sends approve_intent=manual (human consent); the dashboard uses your signed-in session and bypasses the same gates when you click Approve.

If any of the four is missing, the fix waits for your click in the dashboard or in the WordPress connector Errors page, just as it does on a Personal plan. Auto Apply off does not block manual Approve when you click the apply icon in WordPress - that sends an explicit human approval. The automatic ingest pipeline (when Auto Apply is on) still receives 409 auto_apply_not_enabled if the toggle or plan changes between detection and approve.

Where to set the controls¶

• Auto Analysis toggle: Profile → AI tab → Auto-Analysis Preferences, or expand a site row on the Sites page and use the Auto Analysis toggle. Both places control the same setting.
• Auto Apply toggle: Sites page → expand a site row → Auto Apply toggle. Greyed with an upgrade hint on plans that don't include the feature.
• Dry-run: Sites page table toggle (optional ColumnPicker column) or expand the site row (under Auto Analysis / Auto Apply). New sites are created with Dry-run off by default so Approve applies for real; turn it on when you want a preview-only test.
• Workspace minimum confidence: Patcherly maintains a default for your workspace; contact support if you need it changed. The workspace owner can also set their own personal floor on Profile → AI when their plan includes auto-apply.

Bulk Approval¶

For multiple errors:

1. Select errors using checkboxes
2. Click "Bulk Approve" (or the low-confidence bulk confirmation when offered)
3. Eligible fixes are approved; entries that fail policy (paths, confidence, state) are skipped or called out in the result

Same minimum confidence rules apply: the UI may ask you to confirm when any selected fix is below the threshold.

Approval Best Practices¶

• Review high-impact fixes: Always review fixes that modify critical code
• Check confidence scores: Higher confidence = more reliable fix
• Test in staging first: Apply fixes to staging before production
• Monitor after approval: Watch for any issues after fix is applied

Approval History¶

All approvals are logged:

• Who approved the fix
• When it was approved
• What was changed
• Result of the application

You can review approval history on the error details page, or on the Audit Logs page filtered by the matching Error ID to see every event tied to that error (analysis, approval, apply, rollback).

Repo Pull Requests¶

On every plan, a site can open a GitHub pull request instead of (or as well as) applying live. Install the App once under Profile → Account → Connected repositories, then link each site there. While a PR-only fix waits for merge, Errors shows Awaiting PR merge. See GitHub App and Repo Pull Requests.

Next Steps¶

• Auto-Analysis - Skip the manual Analyze with AI click for faster error processing
• GitHub App (Repo Pull Requests)
• Restart your application after fixes
• Learn about rollback
• Apply manual fixes
• Understand error states
• Audit Logs - Per-event record of approvals, applies, and rollbacks