Skip to content

Use case

Pulsy checks WordPress pages over HTTP. Configure status and content assertions to detect observable failures; Pulsy does not diagnose plugin, PHP or database causes.

Pulsy / Monitor overviewDEMO DATA

HTTP · GET

blog.example.com/

Down
Response trace420–560 ms / HTTP 503
Successful responses, then failed HTTP 503 checks from 09:08. Incident opens at 09:10. No response-time value is plotted for failures.
Failed checks → threshold reached → incident at 09:10

The problem

  • WordPress goes down from plugin updates, PHP errors, or database issues, often silently.
  • A lapsed SSL certificate throws a browser warning to every visitor at once.
  • Managed-host status dashboards do not tell you when your specific site is unreachable.

How Pulsy helps

  • Checks the configured HTTP status and optional content assertions. Detecting a blank page or a 200 error page requires a suitable assertion.
  • Tracks TLS certificate expiry and warns you before the padlock breaks.
  • Groups repeated failures into incidents and alerts via email, webhook, Slack, Discord, or Telegram.
  • HTTP monitors share your plan’s monitor allowance. Self-hosting has no subscription monitor cap.

  1. Example: monitor a WordPress page and assert text that appears only in a successful response. A 200 response alone cannot detect a blank or misleading error page.
  2. Choose the interval, timeout and failure threshold. For HTTP checks, configure the expected status and any body, header or JSON assertions.
  3. Configure a notification channel, send an explicit test, and review the first recorded result.

Detection depends on the check schedule, timeout and failure threshold. Delivery depends on your channel provider; alerts are not instantaneous.

Example setup

Illustrative inputs and responses — not a live check or an import file.

GET https://blog.example.com/
HTTP 200
<body>… My Example Blog …</body>

Add a body-contains rule for a stable marker from your own site, such as "My Example Blog". A status-only check cannot detect every HTTP 200 error page.

Add your WordPress site's URL as a monitor in Pulsy. It checks the site over HTTP on your chosen interval, records response time and status, tracks SSL expiry, and alerts you when the site is down or recovers.

Detection depends on your configured status and assertions. A plugin conflict, database problem or white screen is not automatically diagnosed.

Pulsy has a free tier, and paid plans start at $12/mo with flat pricing — no per-site or per-monitor fees.

Track Linux host CPU, RAM, swap, filesystem use, load and uptime alongside website checks. Sustained resource pressure and a disconnected agent become actionable incidents.

Create a server monitor, then run its one-command systemd installer or Docker Compose setup. The agent reports over outbound HTTPS; Linux amd64 and arm64 are supported.

Default thresholds are 90% for CPU, RAM and each filesystem: 3 violating reports to alert, 2 healthy reports to recover. Missing reports cause an outage after 3 intervals. RAM alerts are not confirmed OOM events.

Available on every Cloud plan. Each server uses one monitor slot. Reports default to 60 seconds, subject to the plan’s minimum interval; history follows plan retention.

Explore Linux server monitoring

Start with one website or Linux server. Understand the incident and know what to tell your customers.