An extension update lands overnight, a payment gateway fails to register, and your store keeps serving pages perfectly — minus the one button that matters. Most owners find out from a customer email, hours later.
EU-hosted · your code and backups stay on your server · nobody gets your store login
Maintenance retainers are priced on effort — so much a month, so much an hour. Your loss is priced on something else entirely: how many people tried to buy while it was broken.
Put your own numbers in. Nothing is sent anywhere; this runs in your browser.
And it understates the damage: it counts only the orders you lost, not the customer who tried twice, gave up, and bought somewhere else for good.
≈ — orders/hour on average (your daily total, spread evenly over 24 hours).
≈ — orders missed in — hours of downtime × — € average.
≈ — orders/hour × — € average order.
Rough figures for illustration, assuming orders arrive evenly through the day (orders per hour = orders per day ÷ 24; lost revenue = orders per hour × average order × hours down). Your real distribution is lumpier, and outages have an unhelpful habit of landing at peak.
That is the promise every emergency WooCommerce service makes, and it is a real one — their clock genuinely starts fast. It just starts at the wrong moment. Between the extension update that broke checkout and the moment you open a ticket sits the expensive part: the hours nobody was watching. Something already sitting on your server does not have that gap.
Five checks, in the order that finds the cause quickest for a store. If your whole site is white rather than just checkout, start on the WordPress critical error page instead.
Take a host snapshot before you change anything. On a store, an hour of lost orders beats a restore you cannot undo.
Start here, not in the PHP log. WooCommerce keeps its own logs, and every payment gateway writes its own file. A declined-versus-broken distinction usually shows up in the gateway log within seconds of a test order, and it costs you nothing to look.
Plugins → Installed Plugins, sorted by last update. WooCommerce core, a payment gateway, a shipping or tax extension, or your theme. Deactivate the most recent one and place a test order. If auto-updates are on, this list is the closest thing you have to a changelog of your own store.
In a private window, as a logged-out visitor. Half of all “checkout is broken” reports are only broken for guests, only on mobile, or only for one shipping zone — and none of that is visible while you are browsing as an admin.
Turn on error logging in wp-config.php, reload checkout, and read the last
PHP Fatal error line in wp-content/debug.log:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Switch to Storefront or a default theme for two minutes and place another test order. If checkout works, your theme is overriding a WooCommerce template that changed under it — a very common cause after a WooCommerce core update, and one that never shows up as an obvious error.
A small plugin on your store watches for PHP fatals, sends the error line to your dashboard, and comes back with a patch and a plain-English explanation of what broke. You approve it. It backs up, applies, and verifies — on your server, never ours.
Patcherly patches PHP files. It does not read your database, so your orders, customers and payment records are simply not in scope.
No admin account for an agency, no SFTP credentials in someone’s password manager. The plugin pairs itself in one click and you can revoke it in one click.
Every file is snapshotted on your own server before a patch is written. If the health check fails, rollback runs on its own — and you can trigger it yourself any time.
Frankfurt, GDPR-aligned, with a Data Processing Agreement you can read now rather than request. Your code never trains anyone’s model.
Every proposal comes with a plain-language explanation of what broke and why the change fixes it, plus a confidence score. The diff is there if you want it, or if you want to forward it to a developer.
Low-confidence fixes are gated behind an explicit confirmation, and new stores start in dry run, so the first thing Patcherly does on your site is nothing at all until you say otherwise.
Retainers and emergency-support plans are a real service and they solve real problems. They also all work the same way: you hand over access, you open a ticket, you wait.
| Maintenance retainer | Patcherly | |
|---|---|---|
| Detection | You, or a customer email | The connector, at the moment it fails |
| Clock starts | When the ticket is opened | When the error happens |
| Store credentials | Handed over and kept | Never issued to anyone |
| Where your code goes | Wherever they work on it | Nowhere — it stays on your server |
| Who approves the change | Them, on your behalf | You, every time |
| Cost shape | Monthly retainer plus emergency hours | Flat plan, free tier available |
| Knows your business | Yes, and that is worth paying for | No. It reads errors, not strategy |
These are not mutually exclusive. The sensible setup for most stores is Patcherly catching the fatal errors at 2am and a human you trust for everything that needs judgement. See plans and pricing.
Anything missing? Ask us directly — the founder reads every message.
Usually a version collision. WooCommerce, a payment or shipping extension, and your theme all ship updates independently; when one calls something another just removed, PHP hits a fatal error and the page dies. Checkout is hit hardest because it loads the most extensions at once.
Often, yes — a fatal error inside a gateway extension makes it fail to register, so the option silently disappears rather than throwing a visible error. The line will be in your PHP error log even though the page looks fine. That is the kind of quiet failure that runs for days before anyone notices.
No. It patches PHP files. It never reads or writes your database, which is where your orders, customers and payment records live. What leaves your server is the error message, the file path and line, a small snippet around the error, and your WordPress, PHP and extension versions.
No, and that is the main structural difference from a maintenance retainer. Nobody at Patcherly logs into your store. You install a plugin, click Connect, and it pairs itself — there is no API key to paste and no password to hand over.
Every file in the patch is snapshotted to your own server before anything is written, and syntax-checked before and after. If the post-apply health check fails, rollback restores from that local backup. You can also roll back manually at any time, and Emergency Rescue can run the rollback even if the store is too broken to load normally.
For the fatal-error half of it, largely yes — that is the part that wakes you up. It is not a replacement for the rest of a maintenance plan: updates strategy, performance work, backups of your database, or someone who knows your business. Plenty of stores run both.
Patcherly is EU-hosted, in Frankfurt. Your code and your pre-apply backups stay on your own server. A Data Processing Agreement is published rather than something you have to request, and your code is never used to train third-party models.
The WordPress plugin covers the PHP side of any WooCommerce install, including custom themes and Multisite. If your storefront is a separate Node or Python application, use the connector for that stack alongside it — those can also run tests and restart the app after a fix, which the WordPress plugin deliberately cannot.
It is in an extension update that has not shipped yet. Install the plugin, click Connect, and the next one arrives as a drafted fix in your dashboard instead of an email from a customer who could not pay you.
Full Pro plan for 30 days. No credit card. Free Personal plan after that, for as long as you like.