Pulse

Pulse runs HTTP checks against endpoints you define, on a schedule you choose, and alerts you when they start failing. Unlike SDK health checks — which report on code running inside your own service — Pulse probes your endpoints from the outside, the same way a user or an integration partner would.

Find it in the dashboard under Observe → Pulse.

Monitor types

Creating a monitor

The wizard has four steps.

1. Basics

Name the monitor and pick its type. The name appears in alerts, so make it something you'd want to read at 3am — "Checkout API health" beats "monitor 4".

2. Request

For an API endpoint monitor: the URL, HTTP method, any request headers, and a request body for POST/PUT/PATCH.

For a multi-step flow: the same fields per step, plus extract variables — see Multi-step flows below.

3. Assertions

The rules that decide whether a check passed. Covered in detail in Assertions.

4. Schedule and alerts

Assertions

Every assertion does two things: it pulls one value out of the response, then compares it to the value you supply. A check passes only when every assertion passes.

What each type reads

The last two show a second input once selected. Leaving it empty fails the assertion with an explicit message rather than passing silently.

Operators

Every comparison is a string comparison except less than and greater than, which coerce both sides to numbers.

Each type only offers the operators that make sense for it — response time has no useful substring comparison, and "Body does not contain" already carries a negation, so it accepts only positive operators.

Common assertions

Status code            equals        200        # is it up
Status code            less than     400        # accept any 2xx or 3xx
Response time          less than     3000       # latency budget
Body contains          contains      healthy    # plain-text health endpoint
Body does not contain  contains      exception  # catch a stack trace in a 200
JSON path $.status     equals        ok         # structured health endpoint
JSON path $.data.count greater than  0          # assert records came back
Header value content-type  contains  json       # guard against an HTML error page

New monitors start with Status code equals 200 and Response time less than 3000 already filled in.

Behaviour worth knowing

A failed request skips assertions entirely. If the request times out or the connection fails, the check fails immediately and no assertion is evaluated — you'll see a transport error instead of assertion results. Use the Timeout setting to catch slow endpoints, not a response-time assertion.

Missing values only satisfy the negative operators. If a header isn't present or a JSON path doesn't resolve, the extracted value is empty, and only not equals and not contains pass. equals against a missing header fails — usually what you want.

Response time is per-request. On a multi-step monitor each step's assertion covers only that request. The figure shown on a timeline row is the total across all steps.

Header names are case-insensitive; their values are not. Content-Type and content-type both work as the name. For the value, prefer contains json over equals application/json — servers routinely append ; charset=utf-8.

Numbers arrive as text but compare numerically. A JSON path returning 42 is read as "42", and less than 100 still works, because that operator coerces both sides.

Multi-step flows

Steps run in order. A step that fails stops the run — every remaining step is recorded as skipped, so the timeline shows exactly where the chain broke.

Passing values between steps

Any step can pull values out of its own JSON response and hand them to later steps. In extract variables, give the variable a name and a path:

token   ←   $.data.token

Later steps reference it as {{token}} anywhere in their URL, headers, or body:

GET  https://api.example.com/me
Authorization: Bearer {{token}}

Extraction only happens on a step that passed. If a path doesn't resolve, the variable is simply unset and {{token}} is left in place literally — the dependent step then fails on its own assertions, which points at the real problem more precisely than a generic extraction error would.

Supported path syntax

Paths are a deliberate subset — enough to pull one field out of a response:

$.token
$.data.token
$.items[0].id
data.token          # the leading $. is optional

Wildcards, filters, and recursive descent are not supported. Point a path at a single value; if it lands on an object or array you'll be comparing against its JSON text.

Alerting

A monitor alerts when its consecutive failure count reaches the Alert after threshold. It alerts once per outage, not once per failed check — and sends a recovery notification when it starts passing again.

Each outage opens an incident, visible in the monitor's incident history with its start, end, and duration. A monitor has at most one open incident at a time.

Pausing a monitor stops its checks; resuming clears the failure streak, so an outage you paused through doesn't immediately re-alert.

Limits

Response bodies are stored only when a check fails, truncated, so failures stay debuggable without retaining every successful payload.