Emergency recovery
Most tools assume WordPress is still running well enough to load a plugin's own dashboard. WPFixAgent has two separate recovery paths for when that assumption breaks: one for a site where the connector was already installed before it crashed, and one for a site that's down or was never connected in the first place.
Automatic
Fatal recovery
No plugin
Required option
FTP/SFTP
Credentials used once
Never
Stored
Which recovery path applies
MU Safe Mode catches the fatal error automatically and isolates the plugin -- no action needed on your part.
The signed CLI rescue bridge, polled via hosting cron, can continue processing emergency commands.
Use FTP/SFTP-based Emergency Recovery to deploy a standalone rescue file and diagnose the specific cause.
Recovery hands off back to normal connector pairing and operation.
Installed the moment the connector is. If a plugin causes a fatal PHP error, it's caught and that plugin is quarantined before the next page load -- no dashboard action needed, and downtime is limited to the single failed request.
For a site that's already down before WPFixAgent was ever installed. Using FTP or SFTP credentials entered once and never stored, WPFixAgent locates the WordPress install and deploys a standalone rescue file.
The rescue file identifies the actual cause -- a database connection failure, a fatal plugin error, a corrupted configuration -- instead of leaving you with WordPress's own generic white-screen message.
A hosting cron command lets emergency commands keep being processed even when normal WordPress web requests can't load at all -- configured once from a website's dashboard.
Once a site is responding again, it hands back off to the normal connector-based workflow -- emergency recovery is a bridge, not a permanent operating mode.
FTP/SFTP credentials are used once and never stored
Recovery targets the diagnosed cause, not a blind reset
MU Safe Mode isolates only the plugin that actually failed
Normal operation resumes once the site is confirmed healthy
Practical guidance
Critical errors
Recover from the WordPress critical error screen with a controlled process that protects evidence, creates a restore point, isolates the cause, and verifies the result.
Read guideAuto repair
Automation should resolve known, reversible WordPress conditions while risky database, malware, and hosting failures remain review-driven.
Read guideBackups
Local restore points make repairs fast, while off-site copies protect against hosting and disk failure. A serious recovery plan needs clear roles for both.
Read guideFAQ
No -- FTP/SFTP-based recovery is specifically for sites where the connector isn't installed, or couldn't be reached before the site went down. Professional and Agency plans.
No. They're used once for that specific recovery session and never persisted.
A fatal PHP error caused by a plugin -- the must-use loader runs before ordinary plugins and can isolate the one that's crashing the site, automatically, without any dashboard action.
Server-level outages, exhausted disk space, a fully failed database server, or a compromised hosting account still need direct hosting-provider or specialist intervention -- recovery diagnoses and addresses WordPress-level failures.
Free 14-day trial · no card required
Install the connector, pair with a one-time token, and start monitoring in minutes -- upgrade whenever you're ready.