Skip to content
Sign inStart free

Use case

Pulsy sends scheduled GET, HEAD or POST requests to your API. Configure expected status, response assertions and latency policy. Choose Cloud hosting or self-hosting.

Start monitoring free
Pulsy / Monitor overviewDEMO DATA

HTTP · GET

api.example.com/health

Down
Response trace90–130 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

  • A broken API endpoint can pass a homepage check while your integrations quietly fail.
  • Per-check SaaS pricing punishes teams that run many small services and endpoints.
  • Certificate and uptime checks bolted on from separate tools drift out of sync.

How Pulsy helps

  • Monitors each endpoint with the right method (GET/HEAD/POST) and expected status code, not just a homepage ping.
  • Records request duration; configure latency thresholds to identify slow responses.
  • Watches TLS expiry on HTTPS endpoints alongside up/down status.
  • Alerts through email, webhook, Slack, Discord, or Telegram and groups failures into incidents.

  1. Example: monitor your API health endpoint with GET. Add a JSON assertion for the application state you expect; store credentials as private values.
  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://api.example.com/health
HTTP 200
{ "status": "ok" }
$.status = "ok"

Add a JSON assertion: $.status equals the JSON string "ok". An HTTP 200 response alone does not validate this field.

Yes. Add the endpoint URL as a monitor, choose GET, HEAD, or POST, set the expected status code and timeout, and Pulsy checks it on your schedule, tracking response time and up/down status.

Yes. Every check records response time in milliseconds, so you can see an endpoint slowing down before it starts returning errors.

Yes. Pulsy uses flat plans rather than per-check pricing, so watching many endpoints does not multiply your bill.

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.

Start monitoring freeSelf-host on GitHub