Feature
Uptime & performance
The check that answers the only question a client ever asks: is the site up right now, and how fast was it when you last looked?
What it does
Every site you add is polled on a schedule you choose, as often as every 30 seconds. The worker records the HTTP status code, the time to first byte and the size of the response, so a site that is technically answering but has started crawling shows up as a trend rather than a surprise.
Checks run on our own infrastructure. No third-party monitoring API sits in the middle, which means your clients’ URLs are never handed to a vendor, and the interval you set is the interval that runs, rounded up to the next pass of the worker — it wakes every 30 seconds, so 30, 60 or 300 are exact and 45 behaves as 60.
A failed check does not just colour a dot red — it opens an incident with the reason and the last status code attached, and the downtime window it produces feeds straight into the uptime figures your client sees.
- HTTP/HTTPS checks from 30 seconds upward
- Status code, response time (TTFB) and payload size recorded per check
- ICMP ping and TCP-port reachability for the host behind the site
- Response-size and page-weight tracking, so bloat is visible before it hurts
- Every failure opens an incident automatically
Works alongside
SSL, domain & security
Certificate-expiry and domain (WHOIS) expiry alerts days in advance, SSL chain validity, and a security-headers audit (HSTS, CSP, X-Frame-Options).
Read moreContent & keyword checks
Catch the “white screen of death” at HTTP 200: keyword present/absent, unexpected redirects to foreign domains, and page-defacement detection.
Read moreDNS & network
DNS resolution with A/AAAA/MX/NS change detection — the signal that a domain has been hijacked — plus TCP port and ICMP reachability checks.
Read moreFAQ
About uptime & performance
How often are the checks actually run?
From every 30 seconds, depending on the plan and what you set per site. The schedule is ours to run — there is no external service to throttle it.
Does a slow site count as down?
No. Response time is recorded as a measurement, not a failure. A site is treated as down when the check itself fails — a connection error, a timeout, or a status code outside the range you accept.
What happens during a brief blip?
An incident opens when the check fails and resolves itself when the site answers again, with the exact downtime window kept. Short blips stay in the record instead of being quietly rounded away.