Skip to main content
A monitor is a configured check that PulseGuard runs against a URL or endpoint on a recurring schedule. Each check measures whether your service is reachable, validates the response against your expectations, and records the latency from the probe location. When a check fails, PulseGuard doesn’t immediately raise an alert — it applies a double-check protocol to confirm the failure from alternate vantage points before declaring downtime.

​
How Monitors Work

PulseGuard runs on Cloudflare’s global edge network. Every monitor you configure is dispatched to one or more probe locations at the interval you choose. Results feed into latency heatmaps, uptime charts, and the incident lifecycle in real time via WebSocket.

​
Check Intervals

You can configure any interval between 30 seconds and 24 hours. The minimum interval across all plans is 30 seconds. The default interval for new monitors is 60 seconds.
Shorter intervals consume more of your plan’s check quota. A monitor checking every 30 seconds uses 2,880 checks per day — versus 144 checks at a 10-minute interval.

​
Double-Check Protocol

When a check returns a failure, PulseGuard does not immediately open an incident. Instead, it applies a multi-vector verification protocol:
1

Initial check fails

The primary probe reports a DOWN result for your monitor.
2

Wait 1 second and retry

PulseGuard waits 1,000 ms and repeats the check from the same probe location to filter out transient network blips.
3

Cross-verify via proxy mesh

If the local retry also fails, PulseGuard routes the check through two additional external proxy vectors. If either vector reports UP, the failure is classified as a false positive and suppressed.
4

Declare downtime

Only when all verification vectors confirm DOWN does PulseGuard open an incident and fire your configured alerts.
For multi-region monitors, PulseGuard requires a majority of selected regions to be DOWN before declaring a global outage. This prevents a single flaky probe from triggering unnecessary alerts.

​
DNS Fallback

If a check fails due to a DNS_ERROR, PulseGuard attempts to re-reach the host via a cached IP address stored from the last successful check. This avoids false positives caused by transient DNS resolution failures.

​
Monitor Statuses

Every monitor carries one of four statuses at any given time:

UP

The most recent check succeeded and the response passed all assertions.

DOWN

All verification vectors confirmed a failure. An incident is open.

PAUSED

Checking is suspended. No checks run and no alerts fire.

MAINTENANCE

A maintenance window is active. Checks run but failures are suppressed and no incidents are created.

​
Creating a Monitor

1

Open the dashboard

Navigate to Monitors in the left sidebar and click New Monitor.
2

Choose a monitor type

Select from 15 available types including HTTP, SSL, DNS, Browser, WebSocket, and more. See Monitor Types for a full breakdown.
3

Configure the target

Enter the URL or endpoint you want to monitor. For HTTP monitors this is a full URL including protocol (e.g., https://api.example.com/health). For TCP port checks use tcp://host:port.
4

Set the interval and timeout

Choose how often PulseGuard should check the endpoint and the maximum number of seconds to wait for a response before marking it as a timeout failure.
5

Add assertions (optional)

Define expectations on the response — status code, body content, or a JSONPath expression. See Response Assertions for configuration details.
6

Select check regions

Choose which geographic regions should run the check. Multi-region monitoring gives you visibility into localized failures. See Regions for the full list.
7

Save and activate

Click Create Monitor. PulseGuard schedules the first check immediately.

​
Configuration Reference

The following fields are available when creating or updating a monitor via the dashboard, CLI, or API.
​
string
required
A human-readable label for the monitor. Appears in alerts, incidents, and status pages.
​
string
required
The target endpoint. Use a full URL (https://) for HTTP/HTTPS monitors, tcp://host:port for port checks, ping://hostname for ICMP ping, or a bare domain for SSL, DNS, and Domain monitors.
​
string
default:"HTTP"
The monitor type. Accepted values: HTTP, HTTPS, PING, PORT, SSL, DNS, DOMAIN, BROWSER, HEARTBEAT, MCP, GRAPHQL, WEBSOCKET, DATABASE, BGP, SEQUENCE. See Monitor Types.
​
integer
default:"60"
Check frequency in seconds. Minimum: 30. Maximum: 86400 (24 hours). Defaults to 60.
​
integer
default:"10"
Maximum seconds to wait for a response before classifying the check as a timeout failure. Maximum: 30.
​
string
default:"GET"
HTTP method for HTTP/HTTPS monitors. Accepted values: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS.
​
object
Custom request headers as a JSON object or an array of { key, value } pairs. Example: [{ "key": "Authorization", "value": "Bearer token" }].
​
string
Request body for POST, PUT, or PATCH requests. Send raw JSON, form data, or GraphQL query strings.
​
object
Response assertion rules. Defines expected status codes, body content checks, and JSON path assertions. See Response Assertions for the full schema including all supported fields.
​
integer
default:"1"
Number of consecutive failures required before PulseGuard opens an incident. Increase this value to suppress alerts for intermittent failures. Defaults to 1.
​
array
A JSON array of region codes specifying which locations should run this check. When omitted, PulseGuard uses its default probe location. See Regions for all available codes.
​
string
A URL to an internal runbook or incident response document. Included in alert notifications so on-call engineers can jump directly to remediation steps.

Monitor Types

Descriptions of all 15 monitor types and when to use each one.

Regions

Full list of 50 probe locations grouped by continent.

Assertions

Configure status code, body regex, and JSONPath expectations.