Drupal uptime and health monitoring

Drupal uptime and health monitoring: what teams need and why

A homepage ping tells you that the web server answered, and very little else. A production Drupal site can return a healthy-looking page while cron has stalled and scheduled publishing, search indexing and cache maintenance have stopped, while a queue backs up behind a failing worker, or while the database connection pool is exhausted and only logged-in editors notice. Monitoring has to cover two views of the same site: the outside view, which asks whether a real user can reach and use it, and the inside view, which asks whether Drupal is doing its own work. Teams need both, but they need them for different reasons and at different points in the site's life.

The outside view is a set of synthetic checks run through the load balancer or CDN. These checks confirm DNS, TLS certificate validity, routing and response for representative pages, including at least one page that requires a database read. A dedicated health check endpoint, which a load balancer can poll without rendering a full page, lets infrastructure remove a failing node from rotation. The inside view comes from the Monitoring module and its system checks, which report on cron last-run time, queue backlogs, requirements warnings and similar Drupal state. Some of this data is available only from inside the application, so an outside check alone cannot tell you that cron has not run for a day. Confirm with your Drupal version and chosen contributed modules which checks the Monitoring module covers and what you must add yourself.

Drupal is licensed under GPL-2.0-or-later and has no paid edition, so there is no vendor dashboard that comes bundled with the platform. The monitoring stack, its hosting, its alert routing and the people who respond to alerts are choices your organization makes and runs, or a partner runs under contract. Before you choose tools, decide who owns the alerts, which failures page someone at night, and which only create a ticket. A small site may need only outside checks and a cron alert. A busy, regulated or multisite estate usually needs the full set, with the health endpoint wired into the load balancer and inside checks feeding the same alerting channel.

Monitoring options and when each fits

This table compares five monitoring options for a self-hosted Drupal site, showing what each one detects, who maintains it and when it fits. Read it by matching the failure you most need to catch with the option that sees it first. In most estates the answer is a combination: an external probe for user-facing outages, an internal check for load balancers, and infrastructure monitoring for the servers beneath them.

Option	What it detects	Who maintains it and when it fits
External uptime probe	Site unreachable or returning errors from outside your network, including DNS, TLS and CDN failures users would see	Usually your operations team or a hosted probe service you pay for; fits every public site and is the first signal to set up
Custom health endpoint	Whether the application can serve a request and reach its database, read by a load balancer to pull a failing node from rotation	Written and maintained by your Drupal developers as a small custom route; fits load-balanced or Kubernetes deployments that need automatic node removal
Monitoring module system checks	Drupal status report findings such as available updates, requirement problems and configuration issues, exposed to your monitoring tools	A contributed module on Drupal.org maintained by its community; confirm the checks and output formats in its documentation before relying on them
Cron and queue alerting	Cron runs that stop happening, queues that grow without draining and jobs that fail, which external probes rarely see	Built with your own tooling such as scheduled checks or a metrics exporter; fits any site that depends on scheduled imports, indexing or email queues
Infrastructure monitoring (Prometheus or Zabbix)	Host CPU, memory, disk, web server and database health, and trends that predict capacity problems	Run by your platform team on servers you control; fits estates that already operate a metrics platform and need one alerting path for all systems

What to check inside Drupal and why each check matters

An outside probe can confirm that a Drupal site answers, but it cannot tell you whether scheduled work is running or the database is reachable from every node. The checks below look inside the application, and each one maps to a specific failure and a specific response.

Cron freshness

Drupal runs scheduled housekeeping, such as clearing expired data, refreshing feeds and triggering contributed module tasks, through cron. When the last successful run is older than expected, those tasks silently stop and the site degrades over days rather than failing at once. Check the time of the last completed run, confirm that only one node runs cron if the site is load balanced, and alert on staleness rather than on individual failures. The usual response is to inspect the cron trigger, the PHP process limits and any lock left behind by a stalled run.

Queue backlog and worker health

Items waiting in Drupal queues, such as mail, search indexing or contributed integrations, are processed by workers that run separately from page requests. A growing backlog with no completed items means workers have stopped, are crashing on one bad item or cannot keep up with incoming work. Track the number of pending items and the age of the oldest one for each queue you rely on. The expected response is to find the worker that stopped, review recent errors for the failing item and decide whether to drain, pause or requeue the work.

Database connectivity

Drupal stores configuration, content and sessions in its database, so a lost or slow connection produces errors that look like application faults. Connection failures often appear first on one web node, after a credential rotation or during a database failover. Probe the database from each application node using the same credentials the site uses, and record query latency alongside success. When the check fails, confirm the database endpoint, the connection pool or limit on the server and whether a failover changed the primary.

Requirements and PHP version status

Drupal's status report flags missing PHP extensions, unsupported database versions and outdated core releases. The PHP runtime matters most because each Drupal major version requires a minimum PHP version, and a platform update can move a node below that floor. Check the PHP version on every node, not only the one that serves your test requests, and compare it with the requirements for the Drupal version you run. Plan the response as a change request to the runtime or the Drupal version, never as an in-place edit on a live node.

File system writability

Drupal writes compiled assets, generated images and uploaded files to the public and private file directories, and it needs write access to its configuration sync path during deployments. When a mount fills up or changes ownership, uploads fail and image styles break while pages still render from cache. Verify write access and free space on the directories Drupal uses, from each node that serves traffic. The usual response is to restore the mount or its permissions, then clear and rebuild affected derivatives before users report broken images.

Error rate trends

A single PHP or JavaScript error rarely matters, but a rising rate after a deploy, a module update or a traffic change usually does. Count logged errors per interval and compare them with the baseline for the same period, so that a new message type stands out. Pair the trend with the Drupal log messages your team has classified as actionable. The expected response is to link the spike to the most recent release, decide whether to roll back and open a ticket for the root cause.

How to set up Drupal health monitoring step by step

This sequence turns uptime expectations into a working set of checks, from a health endpoint and the Monitoring module through cron and queue alerts to tested failure responses. The end result is a site where a stalled background job or a broken dependency pages the right people before editors or visitors notice.

Agree service levels with the business
Before any check is built, the platform owner and the business owner agree what healthy means for this site: which pages and workflows must stay available, how stale content can be before it matters, how long a failed background job can go unnoticed, and who answers out of hours. Write these as a short monitoring specification that names each check, its threshold and its owner. The step is done when every alert in the later steps traces back to a sentence in that document. Ask your provider to confirm any service-level figures in writing, because DeployOpen does not set them for you.
Build a dependency-aware health endpoint
Add a lightweight route that load balancers can call without authentication. The endpoint should confirm that Drupal bootstraps, the database answers a simple query, and any cache backend such as Redis or Memcache responds. It should return a bare status code and a timestamp, and it must not return module versions, database names, stack traces or configuration values. Engineers can implement it as a small custom module or as a reverse proxy rule, then restrict the detailed version to internal networks. Verify it by stopping the database in staging and confirming the endpoint returns a failure status within the timeout your load balancer uses.
Install and configure the Monitoring module
Install the contributed Monitoring module with Composer, enable its system checks, and review each one against the service levels from the first step. Disable checks that duplicate what your infrastructure monitoring already does, and keep those that only Drupal can see, such as failed cron runs, pending updates and Drupal status report errors. Expose the results only to a monitoring user or an internal path, and store the configuration in exported code so it survives deployments. Verify by opening the module's status view as an authorized user and confirming that each enabled check reports a current value, then disabling one dependency in staging and checking that the matching check turns to an error state.
Set cron and queue alerts
Cron and queue workers fail silently more often than the web tier does, so give them their own alerts. Record the last successful cron run and the size and age of the oldest item in each queue that matters for your site, such as search indexing, email or integration sync. Alert when cron has not completed within the window you agreed, and when a queue grows or stops draining. Confirm that cron runs from a single scheduler and that the scheduler's own failures are visible. Verify the alert by stalling cron on staging, for example by pausing the scheduled job, and confirming that the alert fires within the window and clears after cron resumes.
Wire probes through the load balancer
Point the load balancer or ingress health probe at the endpoint from step two, and set the probe interval, timeout and healthy and unhealthy thresholds to match the service levels. Keep the probe path separate from user traffic so that a slow page does not remove a healthy node, and make sure a node that fails its probe is drained rather than left in rotation. Add a separate external synthetic check that loads a real page from outside your network, since an internal probe cannot detect DNS, certificate or CDN faults. The step is verified when you take one web node out of service in staging and confirm the balancer stops sending it requests while the external check stays green.
Route alerts to on-call
Send alerts from the monitoring tool to the people who can act on them, with severity levels that separate a page-worthy outage from a warning that can wait for business hours. Each alert should carry the site name, the failing check, the time it started and a link to the runbook section that explains the first response. Confirm escalation: if the primary responder does not acknowledge within the period you agreed, the alert goes to a second person. Test delivery to every channel, including mobile and email, before go-live. Verification is a test alert sent through each route, acknowledged by a named responder, and recorded in the runbook.
Test failure scenarios and document the runbook
Run a scripted set of failures in staging before production relies on the setup. Stop the database, fill the cache backend, stall cron, break a queue worker, return an error from one integration and remove a web node from the pool. For each one, record what the monitoring showed, how long detection took, what the on-call responder did and whether the site recovered. Fix any gap where a failure went undetected or where the alert lacked enough detail to act on. Keep the results with the monitoring specification so that auditors and the next maintainer can see what was tested and when. The step is complete when every scenario produces the expected alert and a documented recovery.

How monitoring differs across hosting models

On a single virtual machine, Drupal usually runs under Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite as the database, as listed in the supported system requirements. One host carries the web server, PHP, the database and often cron, so a single failure can take every check down at once. Monitoring therefore has to run from outside the machine as well as inside it.

Cron placement: Drupal's cron is commonly triggered by the operating system scheduler calling drush cron or a web request to /cron. Confirm which mechanism is in use, because a web-triggered cron can stop silently when the front end is unhealthy.
Health endpoint: The load balancer or uptime service polls a page on the public hostname, so a broken web server, PHP-FPM pool or database connection shows up as a failed request.
Internal checks: Use the Monitoring module's system checks, or Drush status output, to read database connectivity, file system permissions and cron age from the host itself.
Alert ownership: Usually one operations team owns both the host and the site, so alerts can route to a single on-call group. Confirm who responds at night.
Disk and database growth: Log directories, the file system and database size are often the first thing to fill on a single host, so alert on them early.

Check that an external probe and an internal cron alert would both fire if the database went down.

Security and operational risks of exposed health and monitoring data

Health endpoints, monitoring agents and alert channels are useful to operators and useful to attackers. The cards below cover the places where a monitoring setup can leak detail, weaken access or fail silently, and what to confirm in your own environment before the checks go live.

Version and dependency detail in health output

A health endpoint that reports the Drupal version, PHP version, database engine or module list gives an attacker a map of what to exploit. Drupal's supported versions depend on the PHP release, so version strings are especially revealing. Keep the public health route to a plain status code, and move detailed checks behind authentication or onto an internal-only port. Confirm what the load balancer actually reads and who can reach the detailed output.

Monitoring credentials stored in code

Monitoring tools often need database read access, API tokens or Drush credentials to run checks. When those values are committed to the Drupal codebase or the monitoring configuration repository, every developer and every copy of the repo holds them. Store check credentials in your secrets manager, scope them to read-only checks, and rotate them on the same schedule as other service accounts. Confirm that no monitoring config file in your repository contains a password or token.

Alert fatigue from noisy checks

Checks that fire on every cron delay or short queue backlog train teams to ignore the channel, and the real outage is lost in the noise. Set thresholds from observed normal behavior, separate warnings from paging alerts, and suppress alerts during planned maintenance windows. Review the alert history each month to find checks that never lead to action. Confirm who receives each alert, what they are expected to do, and how often the rule has fired without a response.

Monitoring that shares the failure

If the monitoring server, the alert relay or the dashboard depends on the same database, cache or Drupal instance it watches, an outage can silence the alarm at the moment it is needed. Run at least one external probe from outside the hosting network and keep alert delivery independent of the site's mail or messaging services. Confirm what happens to alerting when the database is down, and test that the notification still arrives.

Personal data in error payloads

Error reports and watchdog entries can capture form values, email addresses, session identifiers or query strings that contain personal data. Once copied into a monitoring tool, that data is subject to your retention and access rules, and often to a third party's processing terms. Filter sensitive fields before data leaves the site, limit what is logged for authenticated users, and set retention on the monitoring platform. Confirm which fields your error tracker captures and who can view raw payloads.

Access control on dashboards

Status pages, Grafana panels and error tracker projects often show internal hostnames, request paths, user counts and stack traces. Many of these tools are installed with default accounts or shared logins, and some are reachable from the public internet during testing and never locked down. Require single sign-on or named accounts with roles, restrict network access to the monitoring tools, and review membership when staff change. Confirm that each dashboard requires authentication and that viewer roles cannot change alert rules.

Questions teams ask before hiring help with Drupal monitoring

What drives the cost of setting up Drupal monitoring?

The main driver is how many things need watching and how many environments are involved. A single production site with a health endpoint, cron checks and one alert channel is a small job. Cost rises with the number of sites in a multisite estate, the hosting layers behind Drupal (web servers, database, cache, queue workers, containers), the number of alert destinations, and whether the Monitoring module's system checks must be tuned for your traffic. Integrating with an existing tool such as Zabbix, Prometheus or a hosted status service adds work on both sides. Setup is usually a one-time fee, while alert tuning, on-call handling and check maintenance recur. Ask any quote to list each environment, each check, each alert route and the handover material, so you can compare it with your own effort.

How long does a Drupal monitoring setup take?

Duration depends on the environment more than on Drupal itself. A single site on a conventional stack, with access already granted and an agreed alert channel, is much quicker to set up than a multisite platform spread across containers, load balancers and several databases. Time is also spent on alert tuning after go-live, because thresholds for cron age, queue backlog and error rates only become meaningful once you see normal traffic. Ask for a written timeline that separates build, staging validation, production rollout and a tuning window. DeployOpen agrees timelines in the written scope before work starts, so the quote should state what is included and what the client must provide first.

What does the client team need to provide for monitoring work?

Monitoring depends on access and decisions the client team must make. Typically you need:

Read access to the Drupal codebase, hosting configuration and load balancer settings
A non-production copy of the site (staging) where checks and alert rules can be tested without paging anyone
Named on-call contacts, escalation paths and working hours for each alert severity
Credentials or service accounts for the monitoring tools, kept in your secrets store
Agreement on what counts as healthy, including expected cron frequency and acceptable response times

Missing any of these usually shows up as noisy alerts or checks that never fire. Confirm each item in the scope document.

Can an internal team set up Drupal monitoring alone?

Yes, a team with Drupal and operations experience can set up basic monitoring alone. The core tasks are well documented: exposing a health endpoint for the load balancer, enabling and configuring the Monitoring module's system checks, watching cron and queue health, and routing alerts to your existing tools. The harder parts are the ones that depend on your environment: deciding which signals page a person at night, avoiding alert fatigue, making sure checks stay accurate after Drupal updates, and proving that alerts reach the right people. If your team has no one who owns Drupal operations, a partner can build the setup and hand over runbooks, which is often cheaper than a long learning curve. Ask for the handover package in writing.

Does monitoring replace security testing for a Drupal site?

No. Monitoring tells you that a site is up, responding and running its scheduled work. It does not find vulnerabilities in custom code, contributed modules or configuration. A site can pass every health check while carrying an unpatched flaw. Security testing is a separate piece of work that examines the application, its APIs and its hosting for weaknesses. Monitoring can still help security: unexpected spikes in errors, failed logins or cron changes can be early signals that are worth investigating. Keep the two scopes separate in your planning so that neither is assumed to cover the other. Security advisories for core and contributed projects are published by the Drupal Security Team, so patch routines should follow them independently of monitoring.

How should alert ownership be assigned?

Assign ownership by alert type, not by a general mailbox. A common split is: the platform or infrastructure team owns endpoint and host alerts, the Drupal maintainers own cron, queue and module-level alerts, and the application owner decides business impact and communication. Each alert rule should name one primary owner, a backup, and the action expected in the first 15 minutes. Review ownership after every Drupal release, since new checks and changed cron behavior often move responsibility. Ask any partner to document the routing matrix in the scope and to test it with a staged alert before go-live.

What should a written monitoring scope include?

A written scope should name the environments covered, each check and its threshold, the alert channels and escalation paths, the access the work requires, the staging validation steps, the production rollout, and the handover material such as runbooks and dashboards. It should also say what is excluded, for example application performance tuning, security testing or long-term on-call support. Ask whether the price is fixed for the listed scope and what triggers a change request. Ongoing support, tuning and continuous checks can be arranged as a retainer, which should be priced and scoped separately from the initial setup.

How DeployOpen scopes and supports Drupal monitoring

DeployOpen starts every Drupal monitoring engagement with a fixed scope agreed in writing before any work begins. The written scope names the endpoints to be checked, the Monitoring module checks to be enabled, the cron and queue thresholds, the alert routes and the people who receive each alert. It also states which parts are out of scope, such as application performance profiling or changes to the site's code. A quote follows from that scope, so the reader can compare it directly with the cost of keeping the work in-house. Items the scope should settle include where the health check endpoint runs, which network can reach it, and whether the external probe comes from inside or outside the load balancer.

All implementation happens inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. The external probe, the internal monitoring agent, the alert channels and any dashboards stay under your administrative control, and credentials for them are issued to your named staff. DeployOpen delivers a runbook for each alert: what the alert means, the first checks to run on the cron or queue, who escalates and when, and how to confirm recovery. Handover includes a walkthrough with the on-call team and a test alert sent through each channel so the reader can confirm delivery before the monitors go live.

Ongoing support is optional and sold as a retainer. A retainer can cover reviewing alert history, tuning thresholds after traffic changes, updating the Monitoring module and checks when Drupal core or contributed modules change, and running scheduled tests of the alert paths. The retainer scope should be written with the same care as the initial build. Ask for the response expectations in writing, the hours covered, and what is excluded, and confirm with your own security and compliance teams how the monitoring data will be stored and who can see it. DeployOpen does not hold certifications or partner status for this work, so ask for the references and evidence your own process requires. To start, request a quote from a written scope.

Drupal uptime and health monitoring