DomainWarn Monitoring

A site is not only broken when the page stays white. It is also broken when no order confirmation has gone out for three days because WP-Cron has stalled. Or when the certificate expires in two weeks and nobody read the issuer's email. Or when a plugin has been carrying a known vulnerability for months. DomainWarn monitors your domains from the outside – availability, redirects, TLS certificate, DNS, SPF, DKIM, DMARC, blacklists, domain expiry. This plugin adds the inside view that nobody can see from outside. What the plugin does

• Adds the addresses of this site to monitoring. In a network, every site.
• Reports what is invisible from outside: the exact WordPress and PHP version, plugins and themes with a pending update, the mail setup – sender address and server. Together with the DNS records this yields the finding "your site sends through a server that is not in the SPF record", which neither the site nor an outside check can reach on its own.
• Notices when WP-Cron stalls. A scheduled run reports in every 15 minutes. If it stops, WP-Cron has stalled: the site still answers, but no mail goes out and nothing is processed. DomainWarn then opens an incident and sends it to your channels – email, Slack, Teams or webhook.
• Serves security.txt via DomainWarn (optional, off by default). If DomainWarn hosts the security.txt of your domain, the site fetches it from there and serves it itself at /.well-known/security.txt – no redirect – and the mandatory Expires field stays current by itself. The file is kept for an hour; while DomainWarn cannot be reached, the site serves the last good copy as long as it has not expired. Only at the domain itself or with www in front of it, only from DomainWarn, and never over a security.txt that is already there: a file in the web root or another plugin is shown as a conflict instead of being overridden.
• Shows the state of the site on the dashboard: a "DomainWarn" widget with availability over 30 days, the response time of the last 7 days as a small chart, certificate and domain expiry and open incidents – for every domain of the site, with a link to it in DomainWarn. The figures are refreshed by the scheduled run at most once an hour; opening the dashboard never contacts DomainWarn.
• Shows what DomainWarn hosts for the domain: the state of security.txt, MTA-STS and the BIMI logo, the DNS records to copy, and a link to the page in DomainWarn where they are set up with one click.
• Works from the command line as well: wp domainwarn test, wp domainwarn sync, wp domainwarn report.

Which data is transmitted The plugin sends to DomainWarn: the addresses of the site, the WordPress and PHP version, the names and versions of installed plugins and themes, the sender address and mail server, whether maintenance mode is on, and the environment (PHP settings such as memory limit and OPcache, loaded PHP extensions, database and web server version, and switches such as error display, automatic updates, XML-RPC and WP-Cron) – only versions, sizes and on/off values. The environment can be switched off with "Report platform health" on the settings page. Not transmitted are users, posts, comments, orders or any content of the site. The API token is stored on the site only and never reaches the browser. The plugin works with a DomainWarn account only; the processing is described in DomainWarn's privacy policy. External service This plugin connects to the DomainWarn API at https://api.domainwarn.com (operated by Wigandt Technology, Germany). Without an API token that you create yourself, the plugin stays idle and contacts nothing. The API address is configurable, DomainWarn can also be self-hosted. If you switch on "Serve security.txt via DomainWarn", the site fetches the file from https://domainwarn.com/security-txt/… when someone requests /.well-known/security.txt – at most once an hour – and serves it itself. Normal page views never contact DomainWarn: the address of the file is stored on the site and refreshed by the scheduled run.

1. Install and activate the plugin.
2. Under Settings → DomainWarn, click "Connect with DomainWarn". You confirm in DomainWarn, and the token lands here by itself. A free account is enough to start.
3. "Add addresses". Done.

Prefer to do it by hand? Create a token in DomainWarn under Settings → API with write scope and paste it into the token field instead. For the heartbeat, WP-Cron must run – which is exactly what it checks.

1.4.1

• New setting "Report platform health" (on by default): switched off, the environment is not sent, not rated and opens no incident.

1.4.0

• Platform health: the report now also contains the site's environment – PHP settings (memory limit, execution time, upload size, OPcache, loaded extensions), database and web server version, and WordPress switches modelled on Site Health (error display, file editor, automatic core updates, XML-RPC, HTTPS, WP-Cron, object cache). DomainWarn rates them against the WordPress requirements and the support periods of PHP, MySQL and MariaDB and shows steps to fix them. Only versions, sizes and switches are sent – no paths, no credentials.

1.3.2

• security.txt is served by the site itself (status 200, no redirect), kept for an hour, with the last good copy while DomainWarn cannot be reached. "Check security.txt" recognises this and reports an outdated cached copy.
• Two installations under one domain (for example kunde.de and blog.kunde.de) each report their own inside view and ping their own heartbeat.
• Multisite: only the main site reports the whole network, and only network admins manage the settings there; a sub-site reports just itself. Networks with more than 100 sites are reported in full.
• "Test connection" and the other buttons on the settings page save the form first instead of dropping a freshly entered token.
• Opening the settings page in a second tab no longer breaks a connection in progress.
• The dashboard widget keeps the figures of the first run.
• Sites under internationalised endings such as .рф are recognised.
• Removed the switch "Add the addresses of this site to DomainWarn", which had no effect.

1.3.1

• Heartbeat: after a 404 the scheduled run sets the heartbeat up again instead of pinging into the void; changing the token or slug clears the remembered address.
• "Report now" and wp domainwarn report show a notice instead of a fatal error when DomainWarn cannot be reached.
• Network activation schedules the run on every site of the network.
• Connecting works when the site and the admin run on different hosts.

1.3.0

• New: the "DomainWarn" dashboard widget shows, per domain of the site, its state, availability over 30 days, the response time of the last 7 days, when certificate and domain expire and the open incidents, with a link to the domain in DomainWarn. Only for administrators.
• The figures come from the scheduled run, at most once an hour ("Report now" and wp domainwarn report refresh them right away). Opening the dashboard never contacts DomainWarn.

1.2.0

• New: "Serve security.txt via DomainWarn" (off by default). The site answers /.well-known/security.txt with a redirect to the file DomainWarn hosts – only at the domain itself or www, only to DomainWarn, never over an existing security.txt.
• New: "Check security.txt" fetches the address like a researcher and shows whether the redirect arrives, whether a valid file waits at the target and whether a file or another plugin answers as well.
• New: "Hosted by DomainWarn" shows the state of security.txt, MTA-STS and the BIMI logo with the records to copy.
• Domain names with umlauts are added in the form DomainWarn uses (Punycode) instead of being skipped.
• Requires PHP 8.2. The plugin already relied on PHP 8.2 while declaring 8.1, so on PHP 8.1 it failed with a fatal error. On an older PHP it now stays inactive and says so in the admin area.

1.1.0

• "Connect with DomainWarn" sets the connection up with one click – no token to copy.
• "Assign to client" is a list of your clients in DomainWarn instead of a free text field.
• The organization slug and the API address moved under "Advanced".

1.0.1

• The scheduled run is now really scheduled: on activation the 15-minute interval was not known yet, so no heartbeat was ever set up.
• Corrected links and contributor in this readme.

1.0.0

• First release: add addresses to monitoring, report the inside view, heartbeat against a stalled WP-Cron, settings page and WP-CLI commands.