> ## Documentation Index
> Fetch the complete documentation index at: https://pulse-41cf5b0d.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitor Your Services with PulseGuard

> PulseGuard checks your services every 30 seconds from 50 global locations, using a double-check protocol to eliminate false positives.

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.

<Info>
  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.
</Info>

### Double-Check Protocol

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

<Steps>
  <Step title="Initial check fails">
    The primary probe reports a `DOWN` result for your monitor.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Declare downtime">
    Only when all verification vectors confirm `DOWN` does PulseGuard open an incident and fire your configured alerts.
  </Step>
</Steps>

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:

<CardGroup cols={2}>
  <Card title="UP" icon="circle-check">
    The most recent check succeeded and the response passed all assertions.
  </Card>

  <Card title="DOWN" icon="circle-xmark">
    All verification vectors confirmed a failure. An incident is open.
  </Card>

  <Card title="PAUSED" icon="circle-pause">
    Checking is suspended. No checks run and no alerts fire.
  </Card>

  <Card title="MAINTENANCE" icon="wrench">
    A maintenance window is active. Checks run but failures are suppressed and no incidents are created.
  </Card>
</CardGroup>

## Creating a Monitor

<Steps>
  <Step title="Open the dashboard">
    Navigate to **Monitors** in the left sidebar and click **New Monitor**.
  </Step>

  <Step title="Choose a monitor type">
    Select from 15 available types including HTTP, SSL, DNS, Browser, WebSocket, and more. See [Monitor Types](/monitors/monitor-types) for a full breakdown.
  </Step>

  <Step title="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`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Add assertions (optional)">
    Define expectations on the response — status code, body content, or a JSONPath expression. See [Response Assertions](/monitors/response-assertions) for configuration details.
  </Step>

  <Step title="Select check regions">
    Choose which geographic regions should run the check. Multi-region monitoring gives you visibility into localized failures. See [Regions](/monitors/regions) for the full list.
  </Step>

  <Step title="Save and activate">
    Click **Create Monitor**. PulseGuard schedules the first check immediately.
  </Step>
</Steps>

## Configuration Reference

The following fields are available when creating or updating a monitor via the dashboard, CLI, or API.

<ParamField body="name" type="string" required>
  A human-readable label for the monitor. Appears in alerts, incidents, and status pages.
</ParamField>

<ParamField body="url" type="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.
</ParamField>

<ParamField body="type" type="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](/monitors/monitor-types).
</ParamField>

<ParamField body="interval" type="integer" default="60">
  Check frequency in seconds. Minimum: `30`. Maximum: `86400` (24 hours). Defaults to `60`.
</ParamField>

<ParamField body="timeout" type="integer" default="10">
  Maximum seconds to wait for a response before classifying the check as a timeout failure. Maximum: `30`.
</ParamField>

<ParamField body="method" type="string" default="GET">
  HTTP method for HTTP/HTTPS monitors. Accepted values: `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD`, `OPTIONS`.
</ParamField>

<ParamField body="headers" type="object">
  Custom request headers as a JSON object or an array of `{ key, value }` pairs. Example: `[{ "key": "Authorization", "value": "Bearer token" }]`.
</ParamField>

<ParamField body="body" type="string">
  Request body for POST, PUT, or PATCH requests. Send raw JSON, form data, or GraphQL query strings.
</ParamField>

<ParamField body="expectation" type="object">
  Response assertion rules. Defines expected status codes, body content checks, and JSON path assertions. See [Response Assertions](/monitors/response-assertions) for the full schema including all supported fields.
</ParamField>

<ParamField body="alertThreshold" type="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`.
</ParamField>

<ParamField body="checkRegions" type="array">
  A JSON array of region codes specifying which locations should run this check. When omitted, PulseGuard uses its default probe location. See [Regions](/monitors/regions) for all available codes.
</ParamField>

<ParamField body="runbookUrl" type="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.
</ParamField>

## Related Pages

<CardGroup cols={3}>
  <Card title="Monitor Types" icon="list" href="/monitors/monitor-types">
    Descriptions of all 15 monitor types and when to use each one.
  </Card>

  <Card title="Regions" icon="globe" href="/monitors/regions">
    Full list of 50 probe locations grouped by continent.
  </Card>

  <Card title="Assertions" icon="check-double" href="/monitors/response-assertions">
    Configure status code, body regex, and JSONPath expectations.
  </Card>
</CardGroup>