Downtime causes

When a monitored page fails its check, Scanfully looks at what came back and tells you why: a WordPress critical error, a PHP fatal error, a database error, a WordPress setup screen, maintenance mode, a timeout, and so on. You no longer have to open the site to find out what kind of outage it is.

You see the cause:

• On the downtime details, with what it means, what to do, and what the page showed, such as the PHP error and the plugin it came from.
• In Incidents on the Uptime screen, in Downtime periods and Latest check on the page uptime screen, and in What needs your attention on the site overview.
• In the site down and site degraded alerts. The subject names the cause, for example “example.com is down: WordPress critical error”, and the message links to its section on this page.
• In the AI apps you connect with MCP, which can explain a downtime and what to do about it.

How Scanfully tells

• When the page answers with a server error (a 5xx status), Scanfully reads the start of the error page and recognizes the screens WordPress and PHP show. It goes by their markup, so the language of the site doesn’t matter.
• When the page redirects to one of the WordPress setup screens, that is the cause, whatever status the setup screen answers with.
• When there is no answer at all, the cause is a timeout or a connection error.
• Any other failed answer, such as a 404 or a 5xx page Scanfully doesn’t recognize, is an HTTP error with its status.

Scanfully keeps only the cause and a short detail, such as the PHP error message. It never stores the page itself. Text from your site, like an error message, is shown as plain text.

WordPress critical error

WordPress shows its “There has been a critical error on this website” screen: a plugin, a theme or WordPress itself stopped with a fatal PHP error. WordPress hides the error itself from visitors.

What to do:

• WordPress emails the site’s admin address a link to recovery mode. Use it to log in and deactivate the plugin or theme that broke.
• The PHP error log on the server says which file it was. Your host can show it to you, or turn on the debug log (see WordPress debugging).
• The note What changed around it on the downtime details lists the updates just before the outage, which is often the answer.

PHP fatal error

PHP stopped with a fatal error and shows the error to visitors, because the site has display_errors on. Scanfully reads the error and shows it on the downtime details: the message, the file and line, and the plugin, theme or must-use plugin it belongs to (or WordPress itself).

What to do:

• Update, fix or deactivate the plugin or theme the error names. When wp-admin doesn’t load, rename the plugin’s folder in wp-content/plugins over SFTP or in your host’s file manager; WordPress then deactivates it.
• Turn off display_errors. The error shows the server’s paths to everyone who opens the page. See WordPress debugging.

Database connection error

WordPress shows “Error establishing a database connection”: it can’t reach its database, or can’t read its tables.

What to do:

• Check that the database server runs. On shared hosting, ask your host; a database server that is down often takes many sites with it.
• Check that the database name, user, password and host in wp-config.php are right, for example after a move or a password change.
• If the database runs and the details are right, the tables may be damaged. See Database tables unavailable.

Database tables unavailable

WordPress reaches its database, but one or more of its tables can’t be read. WordPress only says so on wp-admin pages; on the pages your visitors see, it shows the same screen as a database connection error. As most monitored pages are public pages, a table problem usually shows as a database connection error.

What to do: repair the tables. Add this line to wp-config.php, open /wp-admin/maint/repair.php on your site and run the repair, then remove the line again. Or ask your host.

define( 'WP_ALLOW_REPAIR', true );

WordPress setup screen

The site has no wp-config.php, so WordPress sends visitors to its setup screen (/wp-admin/setup-config.php). Anyone who opens it can connect the site to a database of their own, become its administrator and run code on your server. This usually happens after a failed deploy or migration, or when the file was deleted or renamed.

What to do: restore wp-config.php from a backup right away. Until it is back, block the setup screens.

WordPress installer

WordPress finds no WordPress in its database, so it sends visitors to its installer (/wp-admin/install.php). Anyone who opens it can install WordPress, become its administrator and run code on your server. This happens when the database was emptied or replaced, or when the table prefix in wp-config.php no longer matches the tables.

What to do: restore the database, or correct the table prefix ($table_prefix) in wp-config.php, right away. Until then, block the setup screens.

How Scanfully alerts about setup screens

A setup screen counts as down even though it answers 200, and even when the monitor accepts that status. Because the site can be taken over, the alert is urgent and goes out the moment the failure is confirmed, past every hold (the wait for problems that fix themselves, quiet hours and the daily digest). Only a snooze still silences it. This holds for a setup screen on any monitored page: a site that is only degraded by it gets an urgent site degraded alert that names it. If a downtime that started with another cause turns into a setup screen, you get one more alert about it.

The site overview shows a red banner while a page shows a setup screen, and the Sites list marks the site with Setup screen open.

Block the setup screens

While you restore the site, refuse requests to the two setup files on the server.

On Apache, add this to the .htaccess file in the WordPress folder:

<FilesMatch "^(install|setup-config)\.php$">
    Require all denied
</FilesMatch>

On nginx, add this to the site’s server block, above the block that passes .php files to PHP:

location ~* /wp-admin/(install|setup-config)\.php$ {
    deny all;
}

Remove the rule once the site works again, if you want to keep using the installer for new sites. Many hosts can also put a site in maintenance or password-protect it for you.

WordPress maintenance mode

WordPress shows “Briefly unavailable for scheduled maintenance” while it installs updates. It ends maintenance mode by itself 10 minutes after the update started, so a page that stays in it longer had an update that did not finish.

Scanfully waits those 10 minutes: while a page is in maintenance mode for less than 10 minutes, it doesn’t count as down, and Latest check says WordPress is updating. After that, the checks count as failures as usual.

What to do: delete the .maintenance file in the WordPress folder, then check the update that was running. A half-finished update can leave a plugin broken, so check the site for a critical error afterwards.

WordPress error page

A plugin, a theme or WordPress stopped the page with an error message (WordPress’s wp_die()). Scanfully shows the page title and the message on the downtime details.

What to do: the message says what stopped the page. Check the plugin or theme it comes from, or search for the message in your plugins’ support forums.

HTTP error

The server answered with an error status Scanfully doesn’t recognize as one of the screens above, such as 404, 410 or a 5xx without WordPress’s error page. The cause shows the status, for example HTTP 502.

What to do: check the server’s error log, or ask your host. A 502 or 504 often means the web server could not reach PHP; a 404 means the page was moved or deleted.

When the site has its own error page drop-in (php-error.php, db-error.php or maintenance.php in wp-content), the downtime details say so: the drop-in replaces WordPress’s screen, so Scanfully can’t tell which WordPress error it hides. Scanfully knows the drop-ins from the Scanfully plugin.

Timeout

The site did not answer within the timeout of the monitor.

What to do: check whether the server is overloaded or a slow plugin holds the page up. A rising response time before the outage, shown under the chart on the Uptime screen, points that way. Ask your host when it keeps happening.

Connection error

Scanfully could not connect to the site at all. The cause says which kind:

• DNS error: the domain name does not resolve to an address. Check the domain’s DNS records, and that the domain has not expired. See DNS.
• Connection refused: nothing answers on the port. Check that the server and its web server run.
• Connection reset: the server closed the connection without an answer. Check the server’s error log, or ask your host.
• TLS error: the secure connection failed, for example because of a broken certificate setup. See Certificate, and check the certificate with your host or CDN.

Downtimes from before Scanfully read causes show Connection error for a check that got no answer, Timed out for a timeout, and the HTTP status for the rest.

When the cause changes during a downtime

A downtime keeps the cause it started with, which is the one the alert named. When the page shows another cause later in the same downtime, for example maintenance mode that turns into a critical error, the downtime details list each cause with when it first showed. A change of cause doesn’t send another alert, except a change to a setup screen.

What Scanfully can’t see

• Errors on a page that loads. When a fatal error happens after the page has started to load, the server has already answered 200 and the page is cut off. The monitor counts that as up.
• Pages it doesn’t check. Scanfully only checks the pages you monitor. A plugin that breaks the checkout but not the home page shows only when you monitor the checkout too.
• Custom error pages. An error page drop-in, or a host or CDN that shows its own error page, hides the WordPress screen behind it. The cause is then an HTTP error.
• Database tables on public pages. As described under Database tables unavailable, a table problem looks like a connection error on the pages visitors see.