Find what is wrong with your site before your visitors do. PHP errors and the module behind them, slow pages, database, disk, cron, security and mail, each with a plain explanation and the steps to fix it.
Last Update: 11 Nov 2026
Version: 2.0.4
Compatibility: Drupal 10.3, 11 and 12 (tested on 10.3.14, 11.4.10 and 12.0.0-beta2), PHP 8.1 or newer, MySQL or MariaDB
A Drupal site rarely breaks all at once. A module starts throwing warnings, pages get slower week by week, the cron stops and the queues grow, the log of Drupal fills up with millions of messages, caches and sessions pile up in the database, a development setting or a database tool is left on the live site, a backup archive lies in the web root where anyone can download it, and letters from the site quietly land in spam. Site Health Doctor watches all of this on your own server and tells you, in plain words, what is wrong, why it matters and what to do about it.
What it checks
PHP errors. Reads the log of Drupal (Reports > Recent log messages) and the PHP error log, catches errors on the pages itself, groups the same error and tells which module or theme it comes from. A sudden spike of errors or a new fatal error becomes a problem on the Issues screen and an e-mail.
Server time. Measures 1 request in 10: time and memory, separately for pages of the site, the administration, Ajax, REST and JSON:API and the cron. Shows the slowest addresses and warns when the site became slower than its own normal.
Drupal speed settings. The page cache for anonymous visitors (its maximum age and its hit rate), CSS and JavaScript aggregation, OPcache settings that do not fit Drupal and Xdebug left loaded.
Cron and queues. Whether the cron of Drupal runs on time and how it is started, and queues that grow without being worked off.
Database. Table sizes and growth, unused space, character sets, a log table (watchdog) that grew too large, expired cache, session and flood rows that nobody removes, and the version of the database server.
Files and disk. Free disk space, the largest files, archives and database dumps in the web root, PHP files in the public files folder, foreign PHP files where Drupal keeps its compiled templates, server tools left on the site and files that should not be readable from the web (the configuration folder, the Composer files in vendor, .env and .git).
Security. Development settings left on (verbose errors, Twig debug, disabled caches), open registration of new accounts, the Update module off or its page open to everyone, trusted host patterns missing, an administrator named admin, attacks and probes seen in the server access logs, password guessing on the login page, HTTPS, HSTS and the SSL certificate expiry, and the end of support of your Drupal version.
E-mail. SPF, DKIM, DMARC and MX records of your domain, whether the site sends mail through the sendmail program or SMTP, and a test message to check that mail from the site arrives.
Server and PHP. PHP version and its end of support, memory limit, missing PHP extensions, a site left in maintenance mode and whether the background checks run on time.
Updates. Core and modules with an update or a security update, taken from the data the Update module already has (the module itself does not ask drupal.org).
What you get
A health score from five areas: errors, performance, security, database and files, server and configuration. An area without data says "not measured" instead of pretending to be fine.
Every problem with the fix. What was found, why it matters and the steps to fix it, with the place in the Drupal administration. Hide an item for 30 days if you decided to live with it.
Alerts by e-mail for critical problems, without the same alert again and again, and a message when the problem is gone.
A weekly e-mail with the score, new and fixed problems, errors and server time.
A printable report of the last 7 days: print it or save it as PDF from your browser.
Its own item in the administration: Reports > Site Health Doctor, and a row in the Status report with the version.
Permissions: "View Site Health Doctor" shows the screens, "Administer Site Health Doctor" changes settings and runs checks.
Light on your server, private by design
A visitor request never waits for the module: no database query and no outside request runs during a visit. Only 1 request in 10 writes one line to a file.
The analysis runs in the background in short portions from the cron of Drupal.
Everything is collected and stored on your own server. No account and no connection to SiteGuarding are needed; the module only asks siteguarding.com, from the administration pages, whether a new version is out.
Visitor addresses are shortened before they are stored, page addresses are kept without the query string, and full log lines are never kept.
Screenshots
Fix it yourself, or let us do it
Every problem comes with the steps to fix it. If you would rather not do it yourself, the button next to the problem sends it to our engineers:
Fix it for me. Our engineer checks the problem and tells you the price before any work starts. Price after review.
Emergency help. The site is down or shows fatal errors: we bring it back online and find the cause. Price after review.
Site health audit. Our engineer reviews the whole site and sends you a report with the causes and a fix plan. Price after review.
No. Visitor requests do not query the database or call anything outside. Only 1 request in 10 writes one line to a file, and all analysis runs in the background.
Does it change anything on my site?
Only when you ask. The module checks and reports. The one-click clean-ups of Pro run only when you press the button, show what they will change first, keep a journal and, where they remove data, a copy for 7 days.
Where does it keep its data?
In its own database tables (sgshd_*) and in a folder named sgshd inside the files folder of Drupal: the private files folder when you have set one, otherwise the public files folder behind guard files that keep it closed to the web. Nothing about your site is sent to SiteGuarding.
Do I need an account?
No. The free module works without an account and without a licence key.
Which Drupal versions are supported?
Drupal 10.3, 11 and 12 with PHP 8.1 or newer, tested on 10.3.14, 11.4.10 and 12.0.0-beta2 with the Claro administration theme. The stable Drupal 12.0 is not out yet: it will be tested when it is.
Does it need the cron?
Yes. The background checks are a job of the Drupal cron. Server cron is better than Automated Cron on a quiet site, because Automated Cron runs only when someone visits. Without the cron the module shows the screens, refreshes the numbers when an administrator opens a page, and tells you the cron is not running.
Does it work with a Drupal multisite?
Yes. Every site of a multisite is a separate site for the module: its own data folder, tables, settings, history and licence.
I use Varnish or a CDN. What does the module see?
They serve cached pages without Drupal, so the module measures the pages that reach PHP, the cache misses. The server time it shows is the time of those pages.
Does it have Drush commands?
No. The state is on its screens and in the Status report.
Does it count SQL queries or profile the code?
No. It measures the time and memory of requests, not the number of queries, and it has no profiler.
What happens when I remove the module?
Uninstall it under Extend > Uninstall. By default its tables and its folder stay, so that installing it again picks up the history. To delete them with the module, turn on "Delete all data when Site Health Doctor is uninstalled" under Reports > Site Health Doctor > Settings before you uninstall.
Requirements
Drupal 10.3, 11 or 12 (tested on 10.3.14, 11.4.10 and 12.0.0-beta2) with PHP 8.1 or newer and MySQL or MariaDB. The Drupal cron must run. The test sites ran on MariaDB 11 with Apache; other databases, nginx and PHP-FPM, and administration themes other than Claro were not tested.
Download
Free, no account needed. The archive holds one folder, sgsitehealthdoctor: unpack it into the modules folder of the site as it is.
1. Unpack drupal-site-health-doctor.zip into modules/custom (web/modules/custom in a Composer project) so that the folder sgsitehealthdoctor is there.
2. Turn the module on under Extend. Drupal 11.1 and newer cannot install a module from an uploaded archive in the interface, so unpack it by hand; Drupal 10.3 still has Extend > Add new module.
3. Open Reports > Site Health Doctor once, as a user of the web server, so that its data folder is made. The first checks start at once; some numbers appear after a day of data.
Pro: unpack the Pro file the same way next to the free module (folder sgsitehealthdoctorpro), turn on Site Health Doctor Pro under Extend, and enter your licence key in Reports > Site Health Doctor > License.
Updates
The screens of the module show a notice when a new version is out, with a download link and the steps. Replace the folder sgsitehealthdoctor with the one from the new archive and clear all caches (Configuration > Development > Performance > Clear all caches). Until the caches are cleared, the screens of the module say so, because Drupal does not know the new services yet. Settings and history stay; there is no database update to run.
Changelog
2.0.4 First version for Drupal 10.3, 11 and 12, on one core with the WordPress, Joomla, OpenCart, PrestaShop and Magento editions: checks with explanations and the steps to fix them, a health score by area, PHP errors from the Drupal log grouped by module, sampled server time and slow addresses, page cache, cron, queue and database checks, archives and tools in the web root, security checks for the administration and the site, mail checks, a printable report and a weekly e-mail.
Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience. See our policyAccept
