Monitors
A failed check is not an outage.
A single probe timing out in Virginia doesn't mean your service is down. It means Virginia had a network hiccup. Most monitoring tools can't tell the difference. Larm checks from multiple locations and only alerts when a majority of probes confirm the problem.
Incident detection
Majority-of-probes voting
Every probe that checks your service casts a vote. Pass or fail. We take the most recent result from each probe and require a strict majority to change state. If 5 out of 7 probes say your service is down, it's down. If 1 out of 7 says it's down and 6 say it's fine, it's fine.
This is what separates Larm from tools that re-check from the same region or rely on a single confirmation. A regional routing issue, a CDN edge node going stale, a WAF blocking one IP. None of these become your team's 3 AM problem.
How it works
Probes check your service independently from multiple continents
Each probe casts a vote based on its most recent result
Strict majority required to change monitor state
Confirmation window must elapse before alert fires
Check types
More than just pinging a URL.
Four check types covering web services, infrastructure, DNS, and scheduled jobs. Check intervals from 30 seconds to 3 minutes depending on your plan.
HTTP
Any method, custom headers, request bodies, expected status codes, redirect following. Validate response bodies with expected and unexpected keywords. Full request waterfall for every check: DNS, TCP, TLS, TTFB, transfer.
TCP
Connect to any host and port. Optionally send data and verify the response contains an expected string. Databases, mail servers, game servers, message brokers. Anything with a TCP port.
DNS
Query specific nameservers for A, AAAA, CNAME, MX, NS, TXT, or SRV records and verify the response matches expected values. Catch DNS misconfigurations and propagation issues before your users do.
Heartbeat
Your service pings Larm on a schedule. If a ping doesn't arrive within the expected interval plus a grace period, it's down. Perfect for cron jobs, background workers, and batch processes that can't be checked from outside.
Deep data
See why it's slow, not just that it's slow.
Most monitoring tools tell you the total response time went up. That's useful for knowing something is wrong, but not for figuring out what. Is it DNS? TLS? The server itself?
Larm captures the full request waterfall for every HTTP check, from every probe location. You see exactly which phase is degrading, from which region, and how it's trending over time.
Check your site's response time right now →Waterfall breakdown
Confirmation windows
Even with majority voting, you might not want to alert on the first confirmed failure. Maybe your service recovers in 30 seconds, and waking someone up for that isn't worth it.
Confirmation windows let you set how long failures must persist before we transition to "down," and how long recovery must persist before we mark it as back up. A 2-minute confirm-down window means probes must report a sustained majority of failures for 2 full minutes before we alert you. A brief blip that resolves itself never reaches your team.
Start monitoring in minutes.
15 monitors on the free plan. No credit card required.
Sign Up Free