Lehmus uptime Support

Keep monitoring
on track.

Install Lehmus uptime, understand its results and solve the most common scheduling, email and website-check problems. Start with the guide; contact details are available at the end if you still need help.

Start setup Set up WordPress Cron Back to Lehmus uptime Pro

01 / Setup

Getting started

  1. Install and activate. Install Lite from WordPress.org or upload the Pro ZIP under Plugins > Add New Plugin. Pro monitoring needs an active 14-day trial or license under Lehmus uptime > License.
  2. Add a website. Open Lehmus uptime > Sites > Add New Site. Enter a name, public HTTPS URL, check interval, timeout, accepted status codes and notification details.
  3. Run the first check. The first check runs immediately after saving. Confirm the result on the Dashboard or use Run Check Now.
  4. Verify scheduling. Open Lehmus uptime > Settings. Monitoring Schedule should be Healthy and new completed rows should appear under Recent Cron Runs.
  5. Test email. Use Send Test Email before relying on down and recovery notifications.

Expected String is case-sensitive. Use a short, stable phrase that appears in the actual page response. Avoid text that changes frequently.

Edition limits: Lite supports up to three sites, 15-minute normal checks, five-minute failure rechecks and 14 days of detailed logs. Pro supports one-minute intervals, has no software site-count cap and uses an adjustable 30-day detailed-log default. Hosting capacity and WordPress Cron still determine practical timing and scale.

02 / Daily use

Statuses and results

Up

The latest check passed the configured HTTP and content rules. It describes the checked URL at that moment, not every function on the website.

Down

The required number of consecutive checks failed and an incident was confirmed. One down alert is sent, followed by one recovery alert when the site passes again.

Pending

No completed result exists yet. Run a manual check or verify WordPress Cron.

Late

The next expected check time has passed. If this persists, monitoring is not running consistently even if the latest stored result says Up.

Monitoring paused

Pro checks and notifications are paused because the trial or license is not active. The last result remains visible as historical information.

Outdated result

The latest result is too old to verify the current state. Review Monitoring Schedule, Recent Cron Runs and the site interval.

Interruption duration is based on observed check times. The real outage may have started between two checks, and very short outages between checks can be missed.

03 / Alerts

Email notifications

Lehmus uptime waits for the configured number of consecutive failures before sending a down alert. It sends a recovery message once when the confirmed incident ends.

Set the default recipient under Settings, or override it for an individual site. If a test email does not arrive:

  • Check spam and quarantine folders.
  • Confirm the recipient address.
  • Configure a WordPress SMTP plugin or the mail method supported by your host.
  • Review the notification log for a wp_mail_failed error.
  • Ask the hosting provider whether outgoing WordPress email is blocked.

The Settings page shows the latest recorded email attempt. A successful WordPress send result means the message was accepted for sending; it does not prove inbox delivery.

04 / Pro integrations

Webhook notifications

Lehmus uptime Pro can send signed JSON notifications to one HTTPS endpoint for confirmed downtime, recovery and recovered monitoring-schedule interruptions. Configure the endpoint, optional signing secret and selected events under Lehmus uptime > Settings > Webhook Notifications, then send a test delivery.

A webhook succeeds only when the endpoint returns a 2xx status. Failed deliveries are logged and do not stop email or monitoring. The current version does not retry failed webhook deliveries automatically. The endpoint and secret are stored encrypted when PHP OpenSSL is available.

05 / Investigation

Logs, charts and exports

Open Lehmus uptime > Logs and select a website. Filters apply immediately. Use the period, result, HTTP status and error filters to narrow the list.

CSV and JSON exports use the current filters and include all matching retained rows, not only the visible page. Pro also includes response-time and uptime charts.

Detailed history: Pro uses a 30-day default that can be adjusted. Lite keeps up to 14 days. Longer retention increases database and backup size. Compact daily summaries support longer reliability views.

06 / Reliability

Reports and monitoring coverage

Open Lehmus uptime > Reports to compare reliability for the selected period. Availability and downtime are estimates from recorded checks and daily summaries. Missing monitoring time is Unknown, not uptime or downtime, so always review the Observed coverage beside the percentage.

The Health Score requires at least 95% coverage. It starts from observed availability, subtracts points for interruptions and applies another penalty while the site is currently Down. Pro adds 30-day and 90-day periods plus provider summaries. Read a provider total together with average downtime per observed site and the number of sites that contributed observations.

07 / Reliable timing

Set up WordPress Cron

WordPress normally checks scheduled work during page visits. Quiet sites, caching and some hosting configurations can therefore delay checks. For reliable monitoring, configure a server-level Cron job on the WordPress installation where Lehmus uptime is installed.

Recommended schedule: once every minute. The server task belongs on the monitoring WordPress site, not on the websites being monitored.

Recommended setup

  1. Open the scheduled tasks or Cron Jobs tool in the hosting control panel.
  2. Create a task that runs once every minute.
  3. If the panel can open a web address, use the monitoring site’s WordPress Cron address, for example https://your-monitoring-site.example/wp-cron.php.
  4. If the panel accepts only a server command, use the command recommended by the hosting provider for running WordPress scheduled events. Executable and installation paths vary between hosts.
  5. Save the task and verify completed runs in Lehmus uptime.

Use your hosting provider’s command format. A command copied from another server may use the wrong PHP, WordPress or utility path. Ask the provider which command should run WordPress scheduled events once per minute for this installation.

DirectAdmin

  1. Open Cron Jobs.
  2. Set the schedule to once per minute.
  3. Use the WordPress Cron method documented by your host.
  4. Select Prevent Email if routine output is unnecessary.
  5. Save, wait about five minutes and check Recent Cron Runs.
If only a Command field is available, ask the host for the correct command and installation path.

cPanel

  1. Open Cron Jobs.
  2. Select Once Per Minute.
  3. Use the WordPress Cron command format documented by your host.
  4. Save and verify Recent Cron Runs.

Plesk

  1. Open Websites & Domains > Scheduled Tasks.
  2. Add a task that opens the monitoring site’s WordPress Cron address or runs scheduled WordPress events using the host’s supported method.
  3. Choose a one-minute interval, save and verify the result.

Should I disable visitor-triggered WordPress Cron?

Only disable it after the replacement server task is confirmed to work. Without a working replacement task, disabling visitor-triggered scheduling can stop WordPress scheduled work, including monitoring checks.

Verify the schedule

  1. Wait approximately five minutes.
  2. Open Lehmus uptime > Settings > Monitoring Schedule.
  3. Confirm the status is Healthy.
  4. Check that completed Recent Cron Runs appear regularly with a gap close to one minute.
  5. Use Saved / Attempted to confirm that due checks were stored.
An empty browser response from the WordPress Cron address is normally expected. The recorded completed runs are the useful confirmation.

Pro schedule interruption alerts

Lehmus uptime Pro can send an email or signed webhook after monitoring resumes from a schedule interruption. The default threshold is five minutes and can be changed under Lehmus uptime > Settings > Monitoring Schedule Alerts.

The alert is retrospective. The monitoring installation cannot send anything while WordPress Cron or the server itself is unavailable. One notification is sent after the next successful monitoring cycle. It identifies a gap in monitoring data, not necessarily a server outage.

08 / Troubleshooting

Common errors

The server did not respond before the timeout

The URL returned no usable response within the configured timeout. Check the site in a browser, run another check and compare other sites on the same provider. Possible causes include temporary load, network delay, DNS, firewall filtering or slow PHP workers.

The server closed the connection without a response

The connection reached the server, but no HTTP response was returned. A web-server restart, firewall, overloaded PHP workers or hosting/network issue may cause this. A cache-bypass probe can reveal it even when a cached homepage initially appears healthy.

DNS or connection failed

WordPress could not resolve the domain or connect to the server. Check the URL, DNS records, SSL certificate, firewall and whether the website works from another network.

Unexpected HTTP status

The site responded outside the accepted range. Typical examples are 403 blocked access, 404 missing page, 429 rate limiting and 500–503 server errors. Accept a different code only if it genuinely represents a healthy response.

Expected string was not found

Confirm that the exact case-sensitive text still appears in the uncached page source. Update or remove the expected string if the content changed intentionally.

WordPress returned HTTP 200 but the page is broken

Lehmus uptime checks the response body for common WordPress database, critical, maintenance and PHP fatal errors. It also recognizes language-independent WordPress error-page structures, common Finnish messages and entirely empty HTML responses. For custom error pages, configure an Expected String that appears only on the normal healthy page.

The site is Up but checks are Late

Up describes the latest stored result; Late describes the schedule. Review Monitoring Schedule and Recent Cron Runs. An old successful result does not prove that new checks are being recorded.

Cron works but website checks fail

Scheduling and website availability are separate. Open Logs and inspect the newest website-specific error, response status and technical details.

09 / Pro

Trial and license

The Pro trial lasts 14 days and does not require a card. When a trial or paid license expires, Pro monitoring and Pro-only reporting pause. No new checks are recorded during the pause, so charts cannot recreate that missing period later.

After activation or extension, monitoring resumes with new checks. If a valid key is not recognized, open License, run a manual status check and confirm that WordPress can make outbound HTTPS requests to the license server.

Still need help?

Contact support with the useful details.

For server Cron, DNS, firewall or mail-server configuration, send this guide to your hosting provider first. If the problem appears to be in Lehmus uptime, email jukka@lehmusmedia.fi.

Include the Lite or Pro edition and version, WordPress and PHP versions, hosting provider, affected site name, exact error, Monitoring Schedule status, a screenshot of Recent Cron Runs and the steps that reproduce the issue.

Never email passwords, API keys, Paddle credentials or private license keys.