Skip to content

Product scope and mission

This page describes what Patcherly is for and what it is not, so expectations stay aligned with how the product works.

What Patcherly does

Patcherly is an error-to-fix workflow:

  1. Connectors send errors to Patcherly as they occur, from the logs and queues you configure.
  2. Errors are analyzed with AI; a fix or patch is proposed on the error record in your workspace.
  3. After you (or policy) approve, the connector applies the change on your environment, with a target backup (snapshot of your files) before writes.
  4. Patcherly runs checks after the patch so the app or site still works — for example a health request to your target URL, and (on supported plans) tests or deeper checks. If something looks wrong, rollback can run automatically or you can roll back manually.

That is the core mission: collect errors → analyze → patch → verify the change did not break things, with optional signals that the original issue may be resolved (for example the error not appearing on a follow-up load).

What Patcherly is not

Patcherly is not a 24/7 uptime or liveness monitoring product. It does not exist to watch your site every minute to tell you if it is “up” or “down” in the way a dedicated monitoring or APM service does.

  • The dashboard pages Audit, Metrics, and Usage help you see what happened in your workspace (events, business outcomes, and AI spend). They are not a replacement for a full-time external monitoring stack for every customer server.
  • Optional endpoints such as agent heartbeat (if present in the API) do not mean Patcherly stores continuous fleet health for every site unless the product explicitly adds that in the future.

Limits of “did the fix work?”

After a patch, checks are best-effort within the workflow:

  • Some problems only happen after specific user actions (clicks, forms, rare paths). Automated checks may confirm the site loads and tests pass, but cannot guarantee every interaction is fixed without manual QA.
  • Intermittent or environment-specific errors may not reproduce on every check.

That is normal: Patcherly focuses on safe apply + post-patch verification, not exhaustive QA of every user journey.