Add Uptime Monitoring to WordPress Maintenance Plans
"Does Your Maintenance Plan Include Monitoring?"
When a client asks this, can you answer immediately?
Most agencies offering WordPress maintenance include backups, plugin updates, and security scans as standard items. But external uptime monitoring — the kind that detects whether a site is actually reachable from the outside world — is still rarely built into maintenance menus as a named, documented service.
This guide covers how to add external monitoring to your WordPress maintenance offering: the setup steps, SSL certificate monitoring, client-facing status pages, and how to adjust your pricing structure to reflect the added value.
Why External Monitoring Specifically
WordPress has no native mechanism to detect its own downtime and send an alert. Internal monitoring plugins like Jetpack exist, but they run on the same server infrastructure. When the server goes down, those plugins go down with it — and the alert never fires.
External monitoring works differently. A remote network sends HTTP requests to your site on a regular interval and checks for a valid response. If the server stops responding entirely, or if PHP is returning errors that look like a 500, the monitoring service catches it regardless of the site's internal state.
| Monitoring Type | How It Works | Detects Server Outage |
|---|---|---|
| WordPress plugin (internal) | Runs on the same server | No |
| External monitoring (Miterl) | HTTP checks from external network | Yes |
For a WordPress maintenance service to reliably catch outages, external monitoring is not optional — it is the only approach that works in the worst-case scenario.
Four Steps to Add Monitoring to a WordPress Maintenance Plan
Step 1: Register the WordPress site as an HTTP monitor
Log in to Miterl and add each managed WordPress site as an HTTP monitor. The dashboard approach works for a handful of sites; for larger portfolios, the API is more efficient.
# Create an HTTP monitor for a WordPress site via API
curl -X POST https://miterl.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Client A - WordPress Site",
"url": "https://client-a.example.com",
"type": "http",
"interval_seconds": 60,
"alert_contact_ids": [1]
}'
After registration, confirm in the dashboard that each monitor shows UP (green). A monitor that shows DOWN immediately after creation usually means either a URL typo or an HTTP redirect that needs adjusting.
Step 2: Add SSL certificate expiry monitoring
SSL certificate failures are among the most common WordPress maintenance incidents. Let's Encrypt auto-renewal failures, forgotten paid certificate renewals, and CDN misconfiguration can all cause a valid-looking site to go down with an SSL error overnight. WordPress-specific failure patterns — such as cache plugins blocking ACME challenge URLs and security plugins flagging certbot as a bot — require targeted fixes beyond standard certbot troubleshooting. For bulk SSL certificate management across multiple WordPress client sites, see "SSL Certificate Monitoring for WordPress Agencies."
# Add an SSL certificate monitor for the same site
curl -X POST https://miterl.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Client A - SSL Certificate",
"url": "https://client-a.example.com",
"type": "ssl",
"interval_seconds": 3600,
"alert_contact_ids": [1]
}'
Miterl checks the certificate's expiry date and sends advance alerts at 30, 14, and 7 days remaining. This turns SSL expiry from a surprise incident into a scheduled task.
Step 3: Publish a client-facing status page
Once monitoring is active, create a status page the client can bookmark. In the Miterl dashboard, select the monitors you want displayed and set the page to public. That is all the setup requires.
For a custom domain (status.clientdomain.com), add one CNAME record to the client's DNS. On Standard plan and above, the "Powered by Miterl" attribution is hidden, and the page carries your agency's branding.
Share the status page URL in the maintenance contract onboarding email. When an incident occurs, clients who check the URL themselves reduce inbound contact volume significantly. The "How Status Pages Reduce Client Support Requests" article covers the impact in detail.
Step 4: Include uptime data in monthly maintenance reports
Add uptime percentage to your standard monthly maintenance report. A 99.9% uptime figure is the clearest possible answer to "what did I pay for this month?"
# Retrieve uptime data for a monthly report
curl -s "https://miterl.com/api/v1/monitors/1" \
-H "Authorization: Bearer YOUR_API_KEY" | \
jq '{name: .name, status: .status, uptime_30d: .uptime_30d}'
For report templates and SLA documentation, "Uptime SLA Report Guide for Client-Facing Reports" walks through the format.
Pricing Structure: How to Reflect Monitoring in Your Rates
Whether to fold monitoring into your base maintenance price or offer it as an add-on depends on your client mix and sales approach.
Option 1: Include it in the base price (recommended for most agencies)
Add external monitoring to your standard maintenance package and raise the base price by a corresponding amount — typically the equivalent of your Miterl cost per client plus a margin for management time.
Why this works: "Monitoring is included" becomes a differentiator in competitive pitches. Clients are rarely motivated to purchase monitoring as a standalone add-on; they accept it as part of a complete service more readily.
When it makes sense: When you manage enough sites that the per-site Miterl cost is low relative to the maintenance fee.
Option 2: Tiered maintenance plans
Create a structured tier that gives clients visible choices:
| Plan | What Is Included | Monthly Fee (Example) |
|---|---|---|
| Basic | Backups + plugin updates | $50 |
| Standard | Basic + uptime monitoring + status page | $80 |
| Pro | Standard + monthly report + incident investigation | $120 |
Tiering creates a natural upsell path. Clients on Basic have a concrete reason to consider upgrading when they experience their first incident. For a detailed pricing framework, see "How to Price Monitoring Into a Maintenance Contract."
Proposing Monitoring to Existing Clients
Adding monitoring to existing contracts is often harder than building it into new ones. A low-friction approach:
- Set it up and show them first: Send the status page URL with a note — "I've added uptime monitoring to your site, you can check its status here at any time."
- Include uptime data in next month's report: One line — "Site uptime last month: 99.8%."
- Adjust pricing at the next renewal: "We've upgraded the monitoring coverage on your plan, so the renewal reflects that."
Presenting the value first and adjusting pricing at a natural renewal point is less friction than requesting an immediate contract change.
For the full agency configuration walkthrough, "Miterl Setup Guide for Agencies" covers workspace setup, alert routing, and client access permissions.
Tool Selection Criteria
The key criteria when choosing an external monitoring tool for a WordPress maintenance business:
| Criteria | Priority | Why It Matters |
|---|---|---|
| Multi-site management | Required | Per-client logins are not workable at scale |
| SSL certificate monitoring | Required | Prevents the most common WordPress incident type |
| Client-facing status pages | High | Reduces inbound inquiries during incidents |
| Automated uptime reports | High | Makes maintenance value visible without manual work |
| API access | Medium | Necessary for bulk operations as site count grows |
For a full feature and pricing comparison against UptimeRobot and Better Stack, see "Uptime Monitoring Tools Compared: UptimeRobot, Better Stack, and Miterl."
Common Questions
Will 1-minute monitoring intervals create server load for WordPress sites?
A single HTTP GET request from an external monitor is equivalent to one browser page visit. On any standard WordPress hosting, this is negligible. If load is a concern for resource-constrained plans, 5-minute intervals are available.
I already use Jetpack Site Monitoring. What does external monitoring add?
Jetpack monitors from WordPress.com infrastructure, but it relies on your server being reachable enough to respond to a WordPress heartbeat. A complete server outage — out-of-memory crash, hosting suspension, network issue — may prevent the Jetpack check from running. Miterl's checks originate from a fully independent network, so they detect complete server failures that Jetpack would miss. Additionally, Miterl provides Slack/Chatwork/LINE notifications, client status pages, SSL monitoring, and API access — features oriented toward agency operations rather than individual site owners.
How does cost scale as I take on more WordPress maintenance clients?
Miterl pricing is based on monitor count. As the number of sites grows, the per-site cost decreases. If you charge clients a consistent maintenance fee, the monitoring cost as a percentage of revenue shrinks with scale. The ROI analysis in "Monitoring ROI for Agencies" walks through the numbers.
Summary
Adding external uptime monitoring to a WordPress maintenance plan is a four-step process:
- Register each WordPress site as an HTTP monitor
- Add SSL certificate expiry monitoring
- Publish a client-facing status page
- Include uptime data in monthly maintenance reports
The result: higher perceived value of the maintenance service, fewer incident-related client calls, and documented proof of uptime for every renewal conversation.
Start with a free plan to test the setup on one client site, or review the documentation for the full configuration options. For agency-specific use case examples, the use cases page shows how other agencies have structured their monitoring operations.