> ## 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 Types Supported by PulseGuard
> PulseGuard supports 15 monitor types from HTTP and SSL to Browser automation, GraphQL, WebSocket, Database, BGP, and multi-step Sequence scripts.
PulseGuard supports 15 distinct monitor types that cover every layer of a modern infrastructure stack — from basic HTTP reachability and TLS certificate health, through DNS and domain expiration, all the way to full browser automation, AI model endpoints, real-time WebSocket streams, and BGP network path inspection. Choose the type that best matches what you want to verify, and PulseGuard will run the appropriate check on the schedule you define.
## All Monitor Types
**What it checks:** Sends a real HTTP request (GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS) to your endpoint and measures the response time and status code. Optionally validates the response body against regex patterns or JSONPath expressions.
**Key configuration options:**
* `method` — HTTP verb (defaults to `GET`)
* `headers` — Custom request headers such as `Authorization` or `Content-Type`
* `body` — Request payload for POST/PUT requests
* `expectation` — Status code, body regex, or JSONPath assertion
* `timeout` — Max seconds to wait before classifying as a failure (up to 30 s)
**When to use it:** Use HTTP/HTTPS monitors for any web service, REST API endpoint, health check route, webhook receiver, or publicly accessible URL. This is the most common monitor type and works for the majority of uptime monitoring needs.
**URL format:** `https://api.example.com/health`
**What it checks:** Verifies that a host is network-reachable by attempting a TCP connection to port 80. Reports the round-trip time and flags the monitor `DOWN` if the host cannot be reached within the configured timeout.
**Key configuration options:**
* `timeout` — Max seconds to wait for the connection attempt
* `interval` — How often to run the check
**When to use it:** Use PING monitors to verify that a server or network device is online and responding to connections. Ideal for bare-metal servers, Docker hosts, and VMs where you care about raw reachability rather than application-layer health.
**URL format:** `ping://192.168.1.100` or `ping://hostname.example.com`
**What it checks:** Opens a TCP connection to a specific `host:port` combination and verifies that the port is open and accepting connections. Reports latency and reports `DOWN` if the connection is refused, times out, or returns a DNS error.
**Key configuration options:**
* `url` — Target in `tcp://hostname:port` format
* `timeout` — Max seconds to wait for the connection
**When to use it:** Use PORT monitors for any service that exposes a TCP port — database servers (PostgreSQL on 5432, MySQL on 3306, MongoDB on 27017, Redis on 6379), SSH (port 22), SMTP (port 25 or 587), and any custom TCP service. Port monitoring confirms the process is listening even when you can't make a full application-level request.
**URL format:** `tcp://db.example.com:5432`
**What it checks:** Connects to the HTTPS endpoint, retrieves the TLS certificate, and inspects it for validity, expiry date, issuer information, and protocol version. Automatically flags the monitor `DOWN` if the certificate is expired, invalid, or negotiated over TLS 1.0 or TLS 1.1 (deprecated protocols).
**What it reports:**
* `daysRemaining` — Days until certificate expiry
* `issuer` — Certificate authority name
* `protocol` — TLS version negotiated (e.g., `TLSv1.3`)
**Alert milestones:** PulseGuard sends proactive SSL expiry alerts at 30, 14, 7, 3, and 1 days before expiry. Each milestone notification is sent only once, so you won't receive duplicate warnings.
**When to use it:** Add an SSL monitor alongside every HTTP monitor for production domains. Certificate expiry is one of the most common causes of avoidable downtime. Set a longer interval (3,600 s or more) since certificates don't change frequently.
**URL format:** `https://example.com`
**What it checks:** Resolves the target domain and compares the returned DNS records against your expected values. Flags anomalies such as unexpected IP address changes, missing records, or resolution failures that could indicate DNS hijacking, misconfiguration, or propagation issues.
**Key configuration options:**
* `expectation.expectedIPs` — Array of IP addresses the domain should resolve to
**Supported record types:** A, AAAA, MX, CNAME, TXT
**When to use it:** Use DNS monitors to detect silent failures caused by DNS misconfiguration, expired records, or unauthorized DNS changes. Particularly valuable after domain transfers, CDN migrations, or infrastructure changes where DNS propagation could fail silently.
**URL format:** `example.com` (bare domain, no protocol)
**What it checks:** Queries the domain's WHOIS record to track the registration expiry date. Flags the monitor `DOWN` when the domain enters a critical state (expired or approaching expiry) and reports the number of days remaining and the registrar.
**What it reports:**
* `daysRemaining` — Days until domain registration expires
* `registrar` — Domain registrar name
**When to use it:** Use DOMAIN monitors for every production domain in your portfolio. Domain expiry is easy to miss and catastrophic when it happens — it takes down your entire service and can result in domain squatting. Set a long interval (3,600 s or once per day) since WHOIS data rarely changes.
**URL format:** `example.com` (bare domain, no protocol)
**What it checks:** Launches a full headless browser, navigates to the target URL, executes JavaScript, and evaluates the fully-rendered page. Captures real-world load behaviour including client-side rendering, JavaScript errors, and dynamic content injection.
**Key configuration options:**
* `timeout` — Max seconds for the page to load and settle
* `expectation` — Assertions applied against the rendered page content
**When to use it:** Use BROWSER monitors for Single-Page Applications (SPAs), React and Next.js apps, and any page where critical content is injected by JavaScript. A plain HTTP check on a client-rendered app only validates that the HTML shell loaded — a BROWSER check validates that the actual user-facing content rendered correctly.
Browser monitors are significantly more resource-intensive than HTTP checks. Use them selectively for critical user-facing pages rather than every endpoint.
**URL format:** `https://app.example.com/dashboard`
**What it checks:** Inverts the monitoring direction — instead of PulseGuard reaching out to your service, your service pings PulseGuard. If no ping arrives within the expected interval window, PulseGuard marks the monitor `DOWN` and fires your alerts.
**How it works:**
1. Create a HEARTBEAT monitor in the dashboard. PulseGuard generates a unique webhook URL with a secret token.
2. Configure your service, cron job, or background worker to call that URL at the expected cadence.
3. If the ping is late or missing, PulseGuard opens an incident.
**Endpoint:** `GET` or `POST` to `https://worker.pulseguard.app/api/heartbeat/`
**When to use it:** Use HEARTBEAT monitors for cron jobs, background workers, scheduled tasks, data pipeline jobs, and any process that runs on a timer. HTTP monitoring can't detect when a job silently stops running — HEARTBEAT monitoring is specifically designed for this case.
**What it checks:** Sends a JSON-RPC request to a Model Context Protocol (MCP) server endpoint and validates the response. Supports custom method names (e.g., `tools/list`, `resources/list`) and optional parameters, with assertion rules applied to the returned payload.
**Key configuration options:**
* `script.method` — MCP method to call (defaults to `tools/list`)
* `script.params` — Optional parameters to pass with the method call
* `expectation.assertions` — Array of assertion rules applied to the response
**When to use it:** Use MCP monitors to verify the availability and health of AI tool servers, LLM orchestration endpoints, and Model Context Protocol-compatible services. As AI infrastructure becomes part of production systems, MCP monitoring ensures your model-serving endpoints are online and responding correctly.
**URL format:** `https://mcp.example.com/api`
**What it checks:** Posts a GraphQL query to the target endpoint and validates the response. Supports introspection queries, custom operation names, variables, and assertion rules applied to the returned JSON data.
**Key configuration options:**
* `body` — GraphQL query string (e.g., `{ __typename }` for a lightweight introspection check)
* `headers` — Include `Content-Type: application/json` and any authorization headers
* `expectation.assertions` — Array of assertion rules applied to the JSON response
**When to use it:** Use GRAPHQL monitors instead of generic HTTP monitors when your backend exposes a GraphQL API. A standard HTTP check only confirms the endpoint returns 200 — a GRAPHQL monitor validates that the query actually executes and returns valid data, catching schema errors, resolver failures, and authorization regressions.
**URL format:** `https://api.example.com/graphql`
**What it checks:** Performs a full WebSocket handshake with the target server, listens for an optional specified number of seconds, and optionally validates a message received over the connection. Reports `DOWN` if the upgrade handshake fails, the connection is refused, or the expected message is not received within the timeout window.
**Key configuration options:**
* `timeout` — Number of seconds to listen for messages after connection (defaults to 5)
* `expectation` — Optional assertion applied to the first message received
**When to use it:** Use WEBSOCKET monitors for real-time applications — chat systems, live dashboards, financial data feeds, collaborative tools, and any service that relies on persistent WebSocket connections. An HTTP monitor cannot validate whether a WebSocket endpoint is accepting connections.
**URL format:** `wss://realtime.example.com/socket`
**What it checks:** Opens a TCP connection to the database host and port, then optionally executes a test query against the database and validates the result. Confirms that the database process is running, accepting connections, and capable of executing queries.
**Key configuration options:**
* `url` — Database connection URL (connection string format)
* `body` — Optional SQL or query string to execute
* `expectation` — Optional assertion applied to the query result
**When to use it:** Use DATABASE monitors when you need deeper assurance than a TCP port check. A port check confirms the database process is listening; a DATABASE monitor confirms it can actually accept connections and execute queries. Useful for catching connection pool exhaustion, read-only replicas, and query execution failures.
**URL format:** Database connection URL format appropriate to your database engine.
**What it checks:** Inspects the BGP routing table for a given IP prefix or autonomous system number (ASN). Verifies that the expected route is being advertised to the internet and that the prefix is reachable via the expected AS path. Flags `DOWN` if the expected BGP route is missing or the AS path deviates from the configured expectation.
**Key configuration options:**
* `expectation.expectedAsn` — The ASN that should be advertising the prefix
* `expectation.expectedPrefix` — The IP prefix (CIDR notation) that should be present in the routing table
**When to use it:** Use BGP monitors for network operators, ISPs, and any organization that peers directly on the internet. BGP route leaks, prefix hijacks, and AS path changes can silently redirect or black-hole traffic without triggering any application-layer alert. BGP monitoring gives you visibility at the routing layer.
**What it checks:** Executes a multi-step browser script in a full headless browser environment. Each step in the sequence can navigate to a URL, fill in form fields, click elements, wait for selectors, and assert on page state. The entire sequence must complete successfully for the monitor to report `UP`.
**Key configuration options:**
* `script` — A JSON object describing the sequence of browser actions to perform
* `timeout` — Max seconds for the entire sequence to complete
**When to use it:** Use SEQUENCE monitors for complex user flows that span multiple pages — login flows, checkout flows, sign-up funnels, multi-factor authentication, and any business-critical journey where you need to verify that every step works end-to-end. A SEQUENCE monitor catches regressions in user flows that no single-URL check could detect.
**Example use cases:**
* Log in → navigate to dashboard → verify user data loads
* Add product to cart → proceed to checkout → verify order summary renders
* Submit contact form → verify confirmation page appears
SEQUENCE monitors run full browser automation and are the most resource-intensive monitor type. Use them for your highest-value user journeys.
## Choosing the Right Type
Start with **HTTP/HTTPS**. Add an **SSL** monitor for the same domain to track certificate health separately.
Use **PING** for raw reachability and **PORT** monitors for each service port (SSH, database, etc.).
Use **HEARTBEAT** — your job pings PulseGuard instead of the other way around.
Use **BROWSER** for critical pages and **SEQUENCE** for multi-step user flows.
## Related Pages
Monitor configuration fields and the double-check protocol.
Run checks from 50 locations across 6 continents.
Validate status codes, body content, and JSON payloads.