D3bris WordPress monitoring without a plugin: what external checks do
Monitor WordPress sites from the outside, without a plugin: which failures are typical after updates, what external monitoring detects and what it cannot see.
Most WordPress outages are not caused by attacks but by perfectly normal maintenance: a plugin update, a new theme, a PHP version change at the host, an expired certificate. For agencies looking after many WordPress installs, the key question afterwards is: does the website still work for visitors the way it did before?
Why without a plugin?
Monitoring plugins run inside the website they are supposed to watch. That has drawbacks:
- When the site goes down, the plugin often goes down with it. A PHP error or a crashed server prevents exactly the alert that matters.
- Every plugin is one more update. Across 40 installs that is 40 more places to maintain and check for compatibility.
- No difference from other systems. Many agencies also run TYPO3, Shopware or static sites alongside WordPress.
External monitoring checks the website the way a visitor sees it: it requests the address and evaluates the response. Nothing needs to be installed on the client’s server.
Typical failures after WordPress updates – and which are visible from outside
| Situation | Visitors see | Detectable from outside? |
|---|---|---|
| A plugin causes a PHP fatal error | “There has been a critical error on this website”, usually with HTTP status 500 | Yes, from the status code |
| Error on one subpage only, e.g. in the contact form plugin | Homepage fine, contact page broken | Yes, if the contact page is checked as its own page |
| A theme update removes a button or section | Page loads, content missing | Yes, if that text is set as the expected text |
| Maintenance mode stays on after an interrupted update | “Briefly unavailable for scheduled maintenance”, status 503 | Yes, from the status code |
| The form is displayed but emails never arrive | nothing unusual | No |
| The page becomes extremely slow | long load time | Yes, once it exceeds the timeout |
| Content loaded later by JavaScript is missing | empty areas | Only if the text is already in the HTML |
The most important point in this table: the homepage alone says little. An error in a single plugin often affects only the pages that use it. So also check the pages that mean money for the client – contact, appointment booking, quote request.
Setting it up in D3bris
- Add the website: the homepage address, e.g.
https://www.client.com. - Add two key pages: for example
/contactand/book. - Set an expected text: a short, stable text that only appears in the HTML when the page works – the label of the submit button or a form heading, for instance. Avoid texts that change often, such as dates or prices.
D3bris then checks availability, status code, TLS certificate and the expected text every 5 minutes. An outage is only reported after a second failed check, so a brief hiccup during an update does not trigger an alert.
What external monitoring does not replace
- No diagnosis inside the system. We see that the page responds with status 500, but not which plugin causes it. For that you still need error logs or WordPress’s recovery mode.
- No security scanning. D3bris does not detect outdated plugins, malware or vulnerabilities.
- No form or checkout tests. We don’t check whether an enquiry actually reaches the inbox. An occasional test submission is still worthwhile.
- No backups and no updates. D3bris doesn’t manage WordPress; it only watches the result.
External monitoring is therefore a complement to your maintenance tools: you update as usual, and D3bris tells you if an important page no longer works as before.