Skip to content
pulseback
Docs menu

Monitors & check types

The nine check types, the settings every monitor shares, how multi-region confirmation decides when something is down, and importing from StatusCake.

Updated October 27, 2026

A monitor is one thing Pulseback checks on a schedule: a URL, a port, a DNS record, a certificate, a domain, or a job that should check in. Each monitor has a type and the settings below.

Settings every monitor has

Setting Default What it does
name — Shown on incidents, the dashboard and status pages. Up to 100 characters.
intervalSeconds 300 How often to check: 30 s, 1, 2, 5, 10, 15 or 30 minutes, 1 hour or 1 day. Your plan sets the fastest allowed. Ignored for heartbeat and cron monitors.
regions us-east, eu-west, ap-south Where checks run from, 1 to 7 of: us-east, us-west, eu-west, eu-east, ap-south, oc-east, sa-east.
confirmations 2 How many regions must fail, on a check and its immediate re-check, before the monitor is down.
timeoutMs 10000 Per-check timeout, 1–30 seconds.
escalationPolicyId none Who gets paged when the monitor goes down.
severity sev2 Severity of the incidents this monitor opens, sev1–sev4.
environment none Lowercase label such as production or staging. Groups monitors, incidents and deploys; likely-cause matching only looks at deploys in the same environment.
tags [] Free-form labels, up to 20.
notifyOnRecovery true Send a recovery notification when the monitor comes back up.
paused false Paused monitors don’t run, but count toward your plan.

Statuses

Status Meaning
Up The latest confirmed result is healthy.
Degraded Up, but slow (over your threshold) or close to expiry. Shown on the dashboard and status pages.
Down Confirmed failure. Opens an incident and starts escalation.
Maintenance Inside a maintenance window: checks still run, alerts are suppressed.
Paused Not running.
Pending Created, not checked yet.

Check types

HTTP

http requests a URL and checks the response.

Field Default Notes
url — http:// or https:// only.
method GET GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS.
headers {} Sent with every check, e.g. an auth header for a private health endpoint.
body none Request body, up to 10,000 characters.
expectedStatus 200-299 Ranges and lists: 200-299, 200,204,301. Anything else is down.
followRedirects true Follow 3xx responses before checking the status.
degradedAfterMs none Responses slower than this mark the monitor degraded.

Keyword

keyword is an HTTP check that also reads the response body. It takes every HTTP field plus:

Field Default Notes
keyword — Text to look for, up to 500 characters.
keywordMode contains contains: down when the keyword is missing. not_contains: down when it’s present, for error strings.
caseSensitive false

TCP

tcp opens a connection to host and port and closes it. Set tls: true to complete a TLS handshake too. Use it for databases, mail servers, brokers and anything else that listens.

Ping

ping measures round-trip time to a host. Checks run on Cloudflare’s network, where ICMP isn’t available, so a ping is a TCP connect round-trip to port (443 by default). Pick a port the host actually listens on.

DNS

dns resolves hostname over DNS-over-HTTPS and compares the answers.

Field Default Notes
recordType A A, AAAA, CNAME, MX, TXT, NS.
expected [] Down when no answer matches one of these (exact, case-insensitive). Empty: any answer is up.
resolver cloudflare cloudflare or google.

SSL

ssl checks the certificate on hostname:port (port 443 by default): down when it’s invalid or expired, degraded warnDays before it expires (14 by default, up to 90).

Domain

domain reads the registration expiry of domain over RDAP and goes degraded warnDays before it lapses (30 by default, up to 120).

Heartbeat

heartbeat monitors don’t check anything: your job pings them. The monitor goes down when no ping arrives within periodSeconds plus graceSeconds (grace 300 by default). See Heartbeats & cron.

Cron

cron monitors are heartbeats whose expected pings follow a cron schedule in a timeZone, with graceSeconds of slack. See Heartbeats & cron.

Confirmation

One failed request from one place is usually the network, not your service. Pulseback only pages when failures agree:

  1. Every region in the monitor checks on its interval.
  2. When a region fails, a re-check is scheduled immediately.
  3. The monitor goes down when at least confirmations regions fail on their latest check and the failure repeats.
  4. It comes back up when a majority of its regions are up.

Each result records the region and the Cloudflare data center it actually ran from. If you allowlist monitoring traffic, allow Cloudflare’s network.

Monitors that fail while another incident is open in the same environment, within five minutes, are attached to it as related alerts instead of paging again.

Maintenance windows

Schedule maintenance on a status page with a start, an end and the affected components. During the window the linked monitors show Maintenance and their alerts are suppressed (turn suppressAlerts off to keep alerting). Subscribers can be notified ahead of time.

History and retention

  • Raw check results are kept for your plan’s retention period: see Pricing.
  • Hourly p50/p95 response times per region are kept for 90 days.
  • Daily uptime, behind the 90-day bars on monitors and status pages, is kept for 13 months on every plan. Uptime is calculated from confirmed outages, not single failed checks.

Importing from StatusCake

In Monitors → Import, paste a StatusCake API key or upload a CSV export (name,url,type,interval). Pulseback creates a monitor for each check that maps to a Pulseback type and lists the rest as skipped, with the reason. With an API key it also brings each check’s last 90 days of up/down periods, so uptime percentages and status-page bars carry on where StatusCake left off. Imported monitors use your default regions and escalation policy; review them before you turn off the old alerts.

Over the API: POST /api/workspaces/:wid/monitors/import with { "source": "statuscake", "apiKey": "…", "history": true } or { "source": "csv", "csv": "…" }. It returns { "imported": 42, "withHistory": 40, "skipped": [{ "name": "…", "reason": "…" }] }.

Creating a monitor over the API

curl -X POST https://app.pulseback.io/api/workspaces/$WID/monitors \
  -H "Authorization: Bearer $PULSEBACK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Checkout API",
    "config": {
      "type": "http",
      "http": { "url": "https://checkout.example.com/health", "degradedAfterMs": 1500 }
    },
    "intervalSeconds": 60,
    "regions": ["us-east", "eu-west", "ap-south"],
    "confirmations": 2,
    "environment": "production"
  }'

A plan limit (too many monitors, or an interval faster than your plan allows) returns 402 with error.code plan_limit. See REST API & API keys.