Monitors

Larm supports five monitor types. Each type has its own configuration, but they all share common settings for check intervals, timeouts, and disruption confirmation.

Common settings

These settings apply to all monitor types.

Setting	Default	Description
Check interval	3 min	How often to run the check (minimum varies by plan: 3 min Free, 1 min Pro, 30s Business)
Timeout	10s	How long to wait for a response (1s–60s)
Confirm down	1 min	Minutes the monitor must stay failing before being marked down
Confirm up	3 min	Minutes the monitor must stay passing before being marked recovered

Confirmation windows help smooth out brief interruptions. Set Confirm down to a few minutes if you want to avoid alerts for momentary blips.

HTTP

Checks a URL and validates the response status code, headers, and body content.

Field	Description
URL	The URL to check (http or https)
Method	HTTP method (GET, POST, HEAD, etc.)
Expected status codes	Status codes that count as healthy (e.g. 200, 301)
Follow redirects	Whether to follow HTTP redirects
Headers	Custom request headers (up to 20, each value up to 8KB)
Body	Request body for POST/PUT/PATCH (up to 64KB)
Expected keyword	A string that must appear in the response body (up to 1000 bytes)
Unexpected keyword	A string that must not appear in the response body (up to 1000 bytes)

Larm checks your URL from multiple global locations simultaneously and uses majority voting to confirm the result — a single probe failure won’t trigger a false alert.

TCP

Checks that a host is accepting TCP connections on a given port.

Field	Description
Host	Hostname or IP address
Port	TCP port number

Use this for databases, mail servers, game servers, or any service that listens on a TCP port.

DNS

Checks that a DNS record resolves to the expected values.

Field	Description
Host	The domain to query
Record type	DNS record type (A, AAAA, CNAME, MX, TXT, etc.)
Nameserver	IP address of the nameserver to query
Expected records	Values the DNS response should contain

Use this to verify DNS propagation, detect hijacking, or monitor record changes.

Heartbeat

Expects a periodic HTTP ping. If the ping stops arriving, the monitor goes down.

Field	Description
Expected interval	How often the ping should arrive (10s to 24h, plan-dependent)
Consecutive misses	Number of missed intervals before alerting (default 2)

When you create a heartbeat monitor, you get a unique token and URL. Ping it from your cron jobs, scheduled tasks, or background workers:

curl https://app.larm.dev/api/heartbeat/YOUR_TOKEN

See the heartbeat API reference for details.

Synthetic

Synthetic monitoring is available on Pro and Business plans.

Runs a Playwright browser script against your application. Use this for testing login flows, checkout processes, or any user journey that can’t be verified with a simple HTTP request.

Field	Description
Script	Playwright script to execute (up to 64KB)
Interval	How often to run the check (minimum 5 min on Pro, 3 min on Business)
Confirm down after	Consecutive failures before marking as down (default 3)
Confirm up after	Consecutive passes before marking as recovered (default 1)

Synthetic monitors use count-based confirmation instead of time-based. A confirm_down_after of 3 means three consecutive failing checks before we alert you. This prevents flaky scripts or transient runner issues from triggering false alerts.

Getting started

Guides

Common settings

HTTP

TCP

DNS

Heartbeat

Synthetic

​Common settings

​HTTP

​TCP

​DNS

​Heartbeat

​Synthetic

Common settings

HTTP

TCP

DNS

Heartbeat

Synthetic