WordPress monitoring from plugin update to WP-Cron
XICTRAQ monitors availability, subpages, WP-Cron, exposed files and embedded scripts of your WordPress website and recognises maintenance mode during updates as a planned pause rather than an outage. The cookieless tracker captures page views, JavaScript errors and the search terms of the WordPress search.
Check these paths first
- Uptime monitoringHomepage with maintenance detection
/ - Uptime monitoringLogin page as a separate subpage
/wp-login.php - API monitoringREST API: status and JSON response
/wp-json/ - HeartbeatsTrigger from server cron, then ping
/wp-cron.php - Security scanPublicly readable error log
/wp-content/debug.log
Why checking the homepage is not enough for WordPress
A WordPress website consists of the core, a theme and usually several plugins, each of which can be updated separately. If an update triggers a fatal PHP error, WordPress answers with its critical error message and HTTP 500. Scheduled tasks run via WP-Cron, which only checks on page loads whether anything is due. And a page cache can keep serving the homepage while PHP or the database are down.
XICTRAQ therefore spreads the checks across several modules: uptime monitoring with subpages and maintenance detection, heartbeats for WP-Cron, the security scan for exposed files, the visual changelog with defacement detection for injected scripts and script integrity for embedded external scripts. For the REST API under /wp-json/, an API check that verifies status and JSON response is a good fit.
What XICTRAQ does not do: it does not compare the versions of WordPress, plugins and themes against known vulnerabilities, and scripts served from your own domain, including the files of locally installed plugins and themes, are not part of script integrity. You continue to check the update status in the WordPress admin area.
If a security plugin moves the login address, monitor the new address instead of /wp-login.php. An API check on /wp-json/ has no maintenance detection: if WordPress answers there with 503 during an update, the check treats this as a failure.
What typically breaks on WordPress websites
Critical error after an update
If a plugin, theme or WordPress update triggers a fatal PHP error, WordPress shows its critical error message and answers with HTTP 500. Uptime monitoring treats status codes outside 200 to 399 as an outage unless it recognises maintenance or bot protection. If the response stays at 200 and only part of the page is missing, a keyword check on the monitored URL reports the missing word, and the tracker reports JavaScript errors from real visits with message, file and line.
Database down, cache still answering
If the database cannot be reached, WordPress by default answers with a database error message and HTTP 500. If a page cache serves the homepage as a stored copy, it can still keep answering with HTTP 200. Uptime monitoring requests configured subpages directly and raises a separate alert for a subpage that cannot be reached. Choose a page that your page cache does not store; how many subpages are possible depends on the plan.
Maintenance mode during an update
While WordPress updates core or active plugins and themes, it usually answers with HTTP 503 and a notice that the site is briefly unavailable for scheduled maintenance. XICTRAQ recognises this page in German and in English as maintenance: outage and content alerts pause, SSL, domain and blacklist alerts keep running, and start and end are recorded in the changelog. A custom maintenance page in wp-content/maintenance.php only counts as maintenance if it answers with HTTP 503 and carries a notice such as “undergoing maintenance” or “Wartungsarbeiten”. A plugin maintenance page that answers with HTTP 200 remains a normal page for monitoring.
WP-Cron stalls with little traffic
WP-Cron checks on every page load whether scheduled tasks are due. If no page loads occur, tasks such as publishing scheduled posts can be delayed. Disable WP-Cron with DISABLE_WP_CRON, trigger it from the server cron and append a heartbeat call: if its ping does not arrive within the expected interval plus grace period, XICTRAQ reports the missed run.
Injected third-party scripts
A compromised plugin or theme can insert third-party scripts into the page without any change in availability. With defacement detection switched on, XICTRAQ learns the external script hosts of the page during the first three runs. If a new one appears afterwards, it feeds into a score together with source and screenshot changes, and above the alert threshold XICTRAQ reports a possible defacement including the foreign hosts. For verified websites, script integrity additionally reports when an external script it has already recorded changes. Both checks depend on the plan, and malicious code from your own domain or as an inline script does not count as a foreign script host for either.
Error log or config backup publicly readable
With WP_DEBUG and WP_DEBUG_LOG switched on, WordPress usually writes errors to wp-content/debug.log, and a leftover copy such as wp-config.php.bak can contain the database credentials. The security scan requests such files and lists those that answer with HTTP 200, an exposed wp-config.php.bak as critical. If a server answers every address with 200, the scan skips these requests rather than reporting false findings.
How XICTRAQ recognises WordPress
Technology detection reads the HTML and response headers of the monitored page, and a change of the detected CMS is recorded in the changelog. Maintenance detection, by contrast, evaluates the response itself, independently of the detected system.
- WordPress by paths such as /wp-content/, /wp-includes/ or /wp-json/ in the source or by the generator tag. If the pages also carry the identifiers woocommerce or wc-blocks, the website counts as a WooCommerce shop; see the WooCommerce page for more.
- XICTRAQ recognises maintenance by a 503 response with a maintenance notice, such as the WordPress notice about scheduled maintenance in English or German, a maintenance notice in the page title or an address with /maintenance in the path. A 503 without such a notice and without recognisable bot protection remains an incident.
- For WordPress, the security scan also shows a detected page builder such as Elementor or Divi and a detected SEO plugin.
- XICTRAQ does not compare the WordPress version against known vulnerabilities, nor the versions of plugins and themes. If an error page or bot protection comes back instead of the page, XICTRAQ does not assess the CMS in that run and does not infer a system change from it.
What the tracker captures in WordPress
The tracker needs no dedicated detection for WordPress: it captures page views, errors and interactions on every page that loads the script. Tailored to WordPress are the linking of signed-in users via the classes on the body and the evaluation of the WordPress search. It sets no cookies and, in standard tracking, stores nothing in browser storage.
Captured by the tracker on its own
- Page views with referrer, UTM parameters and device type, plus Web Vitals such as LCP, CLS and INP.
- JavaScript errors with message, file, line and stack trace, plus unhandled promise rejections, for example when an updated plugin breaks a script.
- Search terms from the WordPress search: the default search form passes the term in the s parameter, and XICTRAQ shows it in the search terms report.
- Form interactions, if your plan includes form analytics: first contact, focus and leaving per field with input length and time spent, browser validation errors and submission. Forms without id and name, such as those from Contact Form 7, are told apart by their action address including the anchor.
- Clicks on external links and on downloads from your own domain such as PDF or ZIP, for example from the media library, plus clicks on elements with the data-xictraq-event attribute.
- Signed-in users, if your plan includes user identification and the theme or a plugin sets a class following the pattern user-id-number on the body next to logged-in.
Not captured automatically
- Whether the form plugin actually sent the message: the tracker sees the submission in the browser, not the processing on the server.
- Validation errors that a form plugin only detects on the server.
- Field contents: of any input, the tracker captures only the length, not the text.
- Signed-in users without an identifier: WordPress itself adds the class logged-in to the body for them, but no user number.
- Actions in the admin area such as publishing, updates or approving comments. There is no automatic event for them.
- Search terms that are not in the address as a query parameter, for example when a theme or plugin redirects to an address such as /search/term/.
Pass anything missing through the JavaScript API: xictraq.event(name, properties) for custom events and xictraq.identify(userId, traits) for signed-in users. Alternatively, set window.xictraqUser with id, type, group, name and company, or the xictraq:user-id meta tag; the tracker reads both by itself.
The right modules for WordPress
Frequently asked questions
How do I add the XICTRAQ tracker to WordPress?
Add the script tag with your website ID in the data-site attribute to the head of every page, for example via the child theme or a plugin for custom head code. The script loads with defer and sets no cookies. The tracker then captures page views, JavaScript errors and the search terms of the WordPress search without further configuration.
Does WordPress maintenance mode during updates trigger an outage alert?
Usually not. In maintenance mode, WordPress answers with HTTP 503 and a notice about scheduled maintenance, and XICTRAQ recognises this combination as maintenance. Outage and content alerts pause, SSL, domain and blacklist alerts stay armed, and start and end are recorded in the changelog. A 503 without a maintenance notice and without recognisable bot protection, on the other hand, is treated as an incident, because an overloaded server answers the same way.
How do I monitor WP-Cron with a heartbeat?
Disable WP-Cron with DISABLE_WP_CRON in wp-config.php, trigger it from the server cron, for example with wp cron event run --due-now, and call the heartbeat’s ping URL afterwards. If the ping does not arrive within the expected interval plus grace period, XICTRAQ reports the missed run. Separate URLs for start and failure also capture run time and aborts. The ping confirms the run itself, not whether every single task within it succeeds.
Does XICTRAQ notice when my WordPress website has been hacked?
Partly. With defacement detection switched on, XICTRAQ reports, after a learning phase, new external script hosts together with source and screenshot changes as a possible defacement, script integrity reports changed external scripts, and the security scan lists publicly readable files such as debug.log. Malicious code in files on your own domain that does not visibly change the page usually goes unnoticed by these checks.
Does XICTRAQ check whether WordPress, plugins and themes are up to date?
No. Technology detection recognises WordPress but compares neither the WordPress version nor plugins and themes against known vulnerabilities. You check the update status in the WordPress admin area. XICTRAQ reports the consequences an update makes visible, such as a critical error on the homepage or a subpage that no longer responds.
Does XICTRAQ capture signed-in users and the WordPress search?
The search, yes: the default search form passes the term in the s parameter, and XICTRAQ shows it in the search terms report. The tracker links signed-in users if the body carries a class following the pattern user-id-number next to logged-in, which WordPress itself does not set, or if you use window.xictraqUser, the xictraq:user-id meta tag or xictraq.identify(). User identification requires a plan that includes it.