The crash guard

How Alovio Protect catches a fatal error before WordPress finishes loading, pauses only the component responsible, and replays the request without touching the database.

WordPress has shipped a fatal error handler since 5.2, and on its own it does one thing: it apologises. The crash guard replaces that handler with one that records what broke, blames the plugin or theme responsible, and — if the same component fatals again — pauses that one component and replays the request. The visitor gets a blink instead of a white page, and the rest of the site keeps working.

The crash guard is always on. It is the one module that cannot be switched off from the settings, because turning it off would just mean deleting its files, which is what deactivating the whole plugin already does.

How it catches a fatal

The guard runs from two files that load before your plugins — and, in the case of the handler, before the database:

wp-content/fatal-error-handler.php catches the fatal and answers the request.
wp-content/mu-plugins/alovio-protect-guard.php keeps a paused extension out of the load order on every request.

The sequence, from a visitor’s point of view:

	What happens	What the visitor gets
First fatal	The guard records what broke and which component is to blame	A short explanation page (HTTP 503)
The same component fatals again	That component is paused	A redirect, and then the page loads without it
Next request	The site loads normally, minus the paused component	The working site

The pause is never written to the database

When a component is paused it stays active in WordPress’s own list. The pause is held in a file and applied while the page is being built — the mu-plugin filters the active list at runtime. Nothing in the database is rewritten behind your back, and resuming is one click.

This is also why the guard keeps working when the database is the thing that broke: all of its state lives in files under wp-content/alovio-protect/, not in the database.

A paused component is a silently changed site, so Alovio Protect says so on every admin screen until you resume it or remove the extension.

Why a false pause is the thing it avoids

The worst thing a tool like this can do is pause a healthy plugin, so the guard only counts the error types that always halt the script: E_ERROR, E_PARSE, E_USER_ERROR, E_COMPILE_ERROR and E_CORE_ERROR.

E_RECOVERABLE_ERROR is deliberately not counted. A plugin can catch one with its own error handler and let the request finish — but WordPress would still hand it over at shutdown, and the guard would pause a plugin that was never actually broken.

The safety rules

A form is never resubmitted. Only GET and HEAD requests get the replay redirect, so a POST is never replayed.
One retry only. A cookie prevents a loop and is cleared the moment the request succeeds.
REST and AJAX get a JSON error, not an HTML page.
Visitors never see file paths. The detail of an error is shown only when WP_DEBUG and WP_DEBUG_DISPLAY are both on — in other words, on a development site, not a live one.
Alovio Protect never pauses itself.

What it catches, and what it cannot

Case	Caught?
A plugin or theme fatal, a parse error, an uncaught exception	Yes
Memory exhaustion	Yes — a small reserve of memory is released first so there is room to answer
An error in `wp-config.php`	No — that runs before the guard loads
An infinite loop or timeout	Partly
A PHP segfault or OPcache corruption	No
The database completely down	No

This is the honest shape of it: the guard covers the common case — a plugin or theme that fatals — and the table says plainly where it does not reach.

Resuming a paused component

A paused component does not fix itself. When you resume it, the same request will reach the same fatal error and the guard will pause it again — so resume it after you have updated it, rolled it back, or sent the recorded trace to its vendor. You can resume from the Crash guard tab, or with WP-CLI:

wp alovio status                 # what is paused
wp alovio resume plugin:<slug>   # resume a paused extension

If another plugin owns the handler

Only one plugin can own wp-content/fatal-error-handler.php. If another already does, Alovio Protect will not overwrite it: the screen explains the conflict and offers to take ownership, which is your decision. A copy of the file it replaces is saved as a restore point first. If you leave the other plugin in charge, the rest of Alovio Protect keeps working and the screen stops warning you about it.