Skip to content

Use case

Pulsy checks websites over HTTP on a schedule, records timing and TLS expiry, and can alert when configured checks fail. Choose managed Pulsy Cloud hosting or a self-hosted release; check version compatibility before migrating.

Pulsy / Monitor overviewDEMO DATA

HTTP · GET

www.example.com/

Down
Response trace280–340 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

  • You find out your site is down from a customer, not from a tool.
  • Per-monitor pricing punishes teams that run more than a handful of sites.
  • Free tiers cap the number of monitors and lock the status page behind a paid plan.

How Pulsy helps

  • Schedules HTTP GET/HEAD/POST checks against every URL and records up, down, degraded, and response time.
  • Groups repeated failures into incidents so one flaky deploy does not flood your inbox.
  • Watches TLS certificate expiry so a lapsed certificate never quietly takes the site offline.
  • Publishes a status page on your own domain and alerts via email, webhook, Slack, Discord, or Telegram.

  1. Example: add https://example.com, expect HTTP 200 and choose a check interval. This is an illustrative endpoint.
  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://www.example.com/
HTTP 200
300 s · 10,000 ms

Check every five minutes with a ten-second timeout. HTTP timing measures this request, not a browser page load.

It is the practice of checking a website at regular intervals to confirm it is reachable and responding correctly. Pulsy does this over HTTP, records response time and status, tracks TLS expiry, and alerts you when a site goes down or recovers.

You set the interval per monitor, along with the request method, expected status code, timeout, and how many consecutive failures trigger an incident.

Pulsy has a free tier, and paid plans start at $12/mo with flat pricing — not billed per monitor — so you can watch every site you run.

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.