Who actually fixes the bug after it ships?

A plugin update lands at 02:14. Your monitoring catches the fatal and emails you about it straight away. Your editor has an assistant that could write the one-line fix in about four seconds. The site is still broken at 07:30, because you were asleep and neither of those tools can do anything on its own.

The six stages of a production bug

It helps to lay the whole thing out, because the tooling conversation usually collapses two or three stages into one and then argues about the wrong thing.

Stage	What has to happen	Usually covered by
1. Write	The code gets written, reviewed and merged	IDE assistants, review tools
2. Break	Something fails in production	Nothing. This is the event.
3. Notice	A human learns that it failed	Error monitoring, uptime checks
4. Diagnose	Someone works out which line and why	A human, reading a stack trace
5. Fix	A patch is written for the deployed code	A human, in an editor
6. Apply	The patch reaches the server and is verified	A human, plus a deploy pipeline

Stages one and three have had enormous investment over the last few years. Stages four, five and six are still almost entirely manual, and they are where the clock runs.

What coding assistants cover

Copilot, Cursor, Claude Code and the rest are genuinely excellent at stage one, and that is not faint praise. They have your editor open, your repository indexed, and your full attention while you work. For writing code that has not shipped yet, nothing else comes close.

What they do not have is your production server. They cannot see the error that fired twenty minutes ago on a machine they have never connected to, they do not know which of your sites is running an older version of the file, and they have no way to put a change onto a host and confirm it worked. That is not a limitation anyone should hold against them, because it was never what they were built for. It does mean that when something breaks at 2am, the assistant is sitting in a closed laptop.

What monitoring covers

Sentry, Datadog, New Relic, Bugsnag and their peers own stage three, and they do it very well. They capture the exception, the stack trace, the release, the user context and the frequency, then put it in front of you with a graph showing how worried you should be.

Then they stop, by design. A monitoring tool hands you a diagnosis and a ticket. Everything after that, reading the trace, understanding the cause, writing the patch, getting it onto the server, confirming the site recovered, is your job. For a team with an on-call rotation that is a reasonable division of labour. For a solo developer, a small agency, or anyone running sites that are not staffed around the clock, the ticket just sits there until someone is awake.

Uptime monitors sit even earlier. They tell you the site is down, which you will usually have learned from a customer by then, and they tell you nothing at all about why.

The stage nobody owns

So the gap is stages four through six: turning a known error into an applied, verified fix on code that is already live. It is the most expensive part of an incident and the least automated.

Every minute between the error appearing and the fix landing costs the same as the minute before it, and almost none of those minutes are being spent on the fix itself.

Our own research put the typical manual resolution anywhere from ten minutes for a trivial typo to over two hours for something genuinely tangled, and that is measuring from the moment a developer sits down. It does not count the overnight hours where nothing happens at all, which on an unstaffed site are usually the bulk of the outage.

Why the hard part is not writing the patch

Here is the thing that surprised me most while building this. Generating a plausible fix for a well-described error is the easy part now. A current model handles most production fatals comfortably, given the file, the line and enough surrounding context.

The hard part is everything around it. You have to get the error off the customer's server without taking their source code with it. You have to decide whether the proposed change is safe enough to offer at all, and say so honestly when it is not. You have to write to a live file without ever leaving it in a broken state, which means a local backup and a syntax check before and after. You have to verify the site still responds afterwards, and undo the whole thing in one click when it does not.

That is why this category took so long to appear, and it is why the design is mostly gates rather than generation. An AI that writes patches is a weekend project. An AI you would actually let near a site that pays your bills is not.

Where Patcherly fits, and where it does not

Patcherly covers stages four, five and six, and it is explicitly a complement to the tools above rather than a replacement for either of them. Keep your assistant for writing code. Keep Sentry for the detail and the dashboards. Patcherly watches the live app, drafts the fix against your own code, waits for your approval, and applies it on your server with a local backup first.

The limits are worth stating as plainly as the capabilities:

• It is not an uptime monitor. It reacts to errors your application produces. It does not ping you every minute to confirm the site is alive.
• It is not an APM. There are no latency percentiles, no traces, no performance dashboards.
• It patches PHP, Python and Node.js, plus WordPress through its own plugin. It does not touch JavaScript, CSS, your database or your uploads.
• It will not help with a bug that lives in a database row or a stylesheet, and it says so rather than guessing.
• It does not replace your tests, your review process, or your judgement. The approval step is there precisely because the last call should be yours.

If your production code is already covered by a rota of people who respond in minutes, the gap this fills is small. If it is covered by you, a phone, and a hope that nothing breaks on a Sunday, the gap is most of your downtime.

What leaves your server and what never does is documented in full on the security page, which is the question most people ask immediately after this one. For a worked example of stage four done by hand, there is getting the real error out of a 500.