Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.larm.dev/llms.txt

Use this file to discover all available pages before exploring further.

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.
SettingDefaultDescription
Check interval3 minHow often to run the check (minimum 30s)
Timeout10sHow long to wait for a response (1s–30s)
Confirm down1 minMinutes of consecutive failures before marking as down
Confirm up3 minMinutes of consecutive successes before marking as 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.
FieldDescription
URLThe URL to check (http or https)
MethodHTTP method (GET, POST, HEAD, etc.)
Expected status codesStatus codes that count as healthy (e.g. 200, 301)
Follow redirectsWhether to follow HTTP redirects
HeadersCustom request headers (up to 20, each value up to 8KB)
BodyRequest body for POST/PUT/PATCH (up to 64KB)
Expected keywordA string that must appear in the response body (up to 1000 bytes)
Unexpected keywordA 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.
FieldDescription
HostHostname or IP address
PortTCP 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.
FieldDescription
HostThe domain to query
Record typeDNS record type (A, AAAA, CNAME, MX, TXT, etc.)
NameserverIP address of the nameserver to query
Expected recordsValues 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.
FieldDescription
Expected intervalHow often the ping should arrive (10s to 24h, plan-dependent)
Consecutive missesNumber 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.
FieldDescription
ScriptPlaywright script to execute (up to 64KB)
IntervalHow often to run the check (minimum 5 min on Pro, 3 min on Business)
Confirm down afterConsecutive failures before marking as down (default 3)
Confirm up afterConsecutive 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.