Monitoring that runs whether or not you are looking
Uptime and content
HTTP availability, response time and status code, plus assertions on what the page actually said.
Read moreExpirySSL certificates and domains
A real TLS handshake and an RDAP registry lookup, both warning weeks before anything lapses.
Read moreDriftDNS records
Eight record types plus SPF, DMARC and DKIM, compared against what you declared and against last time.
Read moreRegressionSecurity headers
HSTS, CSP, frame protection, cookie flags and the https upgrade, scored and watched for regressions.
Read moreWhat makes a check a monitor
A monitor is scheduled. You give it an interval, and from then on a worker claims it when it is due, runs it, records the outcome and — if the outcome changed — opens an incident and notifies you.
That work happens in a separate process from the API on purpose. Checks are slow, bursty and entirely I/O bound, and the one thing that must stay fast when fifty sites are being checked at once is the dashboard you opened to find out why.
Intervals, and the floors under them
You choose the interval. Two things can raise it: your plan, and the check itself. Both are shown in the dashboard rather than applied silently.
- Uptime
- 5 min
- Content assertion
- 5 min
- SSL certificate
- 6 h · floor 1 h
- Domain expiry
- 1 day · floor 6 h
- DNS
- 1 h · floor 15 min
- Security headers
- 1 h · floor 15 min
The per-check floors are not upsells. Domain expiry moves once a year, and registry RDAP servers block source addresses that hammer them. DNS answers change on the order of hours, and a public resolver queried every thirty seconds per site starts refusing to answer. A floor that keeps you welcome at someone else’s service is worth more than a number that looks impressive.
One outage, one message
An incident opens when a check transitions from passing to failing, and closes when it transitions back. Notifications go out on those transitions — not on every failed run.
The difference matters more than it sounds. An hour of downtime at a five-minute interval produces around a dozen failed runs, and the alert rules layered on top can produce a hundred rows. All of that collapses into one incident, so you get one message when it breaks and one when it recovers.