Settings Reference
All BD Uptime Monitor settings are stored in a single WordPress option called bdum_settings. You can configure them from the BD Uptime → Settings tab.
Enable Monitoring
This is the master switch for uptime monitoring. When turned off, no checks are performed and the cron event is not rescheduled. The default is enabled.
Even when monitoring is enabled, checks will not run unless you also have a valid, activated license.
Check Interval
How often the plugin pings your site. Available options:
- 1 minute — most frequent, best for critical sites (Professional and Agency tiers)
- 5 minutes (default) — good balance between responsiveness and resource usage
- 10 minutes
- 15 minutes
- 30 minutes
- 1 hour — least frequent, lowest resource usage
When you save settings with a new interval, the existing cron event is cleared and a new one is scheduled based on the updated interval.
Important: WordPress cron is triggered by site visits. On low-traffic sites, checks may not fire at exact intervals. Consider setting up a system cron job (wget -q -O /dev/null https://yoursite.com/wp-cron.php) for more reliable timing.
Alert Email
The email address where down and recovery notifications are sent. If left empty, the plugin uses your site’s admin email address (from Settings → General).
Failure Threshold
The number of consecutive failed checks required before the plugin creates a downtime incident and sends an alert email. Options range from 1 to 10 consecutive failures. The default is 3.
Setting this higher reduces false positives from momentary glitches. Setting it to 1 means you get alerted on the very first failed check.
How the threshold works internally:
- Each time a check returns a non-2xx/3xx status or a connection error, a transient counter (
bdum_consecutive_failures) is incremented. - When the counter reaches the threshold and there is no open incident, a new “down” incident is created in the
bdum_incidentstable and an alert email is sent. - After the alert fires, the counter resets. If the site remains down, it will count up again from zero before sending another alert.
- When the site comes back up, the counter is deleted and the open incident is closed.
Request Timeout
How long the plugin waits for a response from the health endpoint before marking the check as failed. Options:
- 5 seconds
- 10 seconds (default)
- 15 seconds
- 30 seconds
If your site is slow, increase the timeout to avoid false positives. If you want faster detection, decrease it.
Recovery Alerts
When enabled (default: on), the plugin sends an email notification when your site comes back online after a downtime incident. The recovery email includes the site name, URL, when the downtime started, total downtime duration, and when recovery was detected.
Email Alerts
Down Alert Email
When the failure threshold is reached, the plugin sends an HTML email with the subject line “Your Site Name is DOWN“. The email contains:
- Site name and URL
- HTTP status code returned (or “N/A” if the request failed entirely)
- Error message (e.g., “HTTP 500” or a connection error like “cURL error 28: Operation timed out”)
- Detection timestamp
- A note that a recovery notification will follow when the site comes back online
Recovery Alert Email
When an open incident is resolved (the site returns an HTTP 2xx/3xx response), the plugin sends an HTML email with the subject line “Your Site Name is back UP“. The email contains:
- Site name and URL
- When the downtime started
- Total downtime duration (formatted as hours, minutes, seconds)
- Recovery timestamp
Both emails use a styled HTML template with the BD Uptime Monitor branding. They are sent using wp_mail(), so they will go through whatever SMTP plugin you have configured (e.g., Fluent SMTP).
Incident Lifecycle
BD Uptime Monitor tracks downtime through the bdum_incidents database table. Here is the lifecycle of an incident:
- Detection — after N consecutive failures (where N is your failure threshold), a new incident record is created with
type = 'down', the current timestamp asstarted_at, andended_at = NULL. The alert email is sent. - Ongoing — while the site remains down, the existing open incident stays in the database. The failure counter resets and begins counting again. No additional down alerts are sent while an incident is open.
- Recovery — when the next successful check occurs, the open incident is closed by setting
ended_atto the current time and calculating thedurationin seconds. A separate “recovery” incident record is also created for the log. If recovery alerts are enabled, the recovery email is sent.
Incident Table Columns
| Column | Description |
|---|---|
type | “down” for downtime events, “recovery” for recovery events |
started_at | When the incident began (or when recovery occurred) |
ended_at | When the downtime ended (NULL if still ongoing) |
duration | Downtime duration in seconds (calculated on close) |
details | Error message (for down) or response time (for recovery) |
notified | Whether an email notification was sent (1 = yes, 0 = no) |
Ping History
Every check result is logged in the bdum_pings table with the following data:
| Column | Description |
|---|---|
status | “up” or “down” |
response_time | Response time in milliseconds |
status_code | HTTP status code (200, 500, 0 for connection failure, etc.) |
error_message | Error details (empty for successful pings) |
created_at | When the check was performed |
This data feeds the response time chart and the uptime percentage calculations on the Dashboard tab.
Uptime Statistics
The uptime percentage is calculated as: (up_count / total_pings) * 100 for the selected time period. If there are no pings for a period, the uptime defaults to 100%.
The average response time is the mean of response_time values for successful (“up”) pings only.
Manual Check
Click the Check Now button on the Dashboard tab to trigger an immediate ping. This performs a real HTTP request to the health endpoint, logs the result, and updates the displayed stats. The manual check does not affect the scheduled cron timing.
Clearing History
The Clear History button on the Dashboard tab truncates the entire bdum_pings table. This resets all uptime statistics and chart data. Incidents are not affected by this action.
Daily Cleanup
BD Uptime Monitor automatically cleans up old data to keep your database lean. A daily cron event (bdum_daily_cleanup) runs and performs the following:
- Pings older than 90 days are deleted from the
bdum_pingstable. - Closed incidents older than 90 days are deleted from the
bdum_incidentstable. Open (unresolved) incidents are never auto-deleted.
This cleanup runs automatically and cannot be configured. The 90-day retention period is hardcoded.
Deactivation
When you deactivate the BD Uptime Monitor plugin, all scheduled cron events (bdum_check_site) are cleared. Your settings and database tables are preserved so that reactivating the plugin picks up where it left off.
To completely remove all plugin data, you would need to manually delete the bdum_settings option and drop the bdum_pings and bdum_incidents tables from your database.