WHMCS Monitoring — What Exactly We Check

WHMCS is the system that handles a hosting company's orders, invoices and client data. When the cart stops working or a copy of the configuration file is left in the public directory, plain "does the site respond" monitoring will not notice. MonitorWWW.com recognises WHMCS automatically from the client area address and runs a set of checks built for it.

Key pages

• Cart (cart.php), client area (clientarea.php) and tickets (submitticket.php) — we check not only the response code but also whether a WHMCS error message is shown instead of the page.
• Application state — maintenance mode ("Down for Maintenance"), critical error and license problems.

Installation security

• Installer folder — whether /install/ was removed after installation or an upgrade.
• Copies of configuration.php — .bak, .old, .save and ~ files that the server would hand out as plain text, database password included.
• Archives and database dumps — whmcs.zip, whmcs.sql, backup.zip, backup.sql in the web root.
• Cron scripts — whether /crons/cron.php can be triggered from a browser.
• The /vendor/ directory — whether libraries are reachable from outside.
• Client files — directory listing of attachments, downloads, templates_c and modules/gateways/callback.
• Application logs — whether a file from /storage/logs/ can be downloaded.
• Admin area — whether it runs at the default /admin/ address.
• CAPTCHA — whether the registration form is protected against bots.

Every finding comes with a ready fix in the dashboard — specific commands and WHMCS settings, not general advice.

How often, and why not all at once

We check availability every few minutes. Security probes, however, are spread across the whole day: 22 requests a day, at most two at a time, roughly every 100 minutes and at irregular intervals. A dozen requests for unusual files within one second looks like a scan to a firewall and ends with the IP address being blocked — and then monitoring reports an outage that is not there. On a newly added site the first full cycle runs faster, in about four hours.

All checks are made from the outside, the way a visitor sees the site. We do not install a module, log in to the admin area or need server access.

Alerts

You hear about an outage by email, SMS or Telegram. A separate security alert is sent when a publicly accessible installer, a copy of configuration.php or a database dump appears. Other findings are visible in the dashboard and count towards the site's security score.

What we check on every site, regardless of platform

• Uptime and response time — HTTP status, load time, redirects, maintenance mode.
• SSL certificate and domain — certificate validity and domain expiry date, with an alert ahead of time.
• DNS — SPF, DMARC, MX and CAA records.
• Security headers — HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and cookie flags.
• Files that should not be visible — .env, .git, phpMyAdmin, backups, directory listing.
• Malware and PHP errors — suspicious code and error messages in the page content.
• Blacklists — whether the domain has been flagged as unsafe.
• Content changes — an optional keyword that must be present on the page.