Skip to content

Uptime, domain & service checks

While the server agent watches your hosts from the inside, WatchTower15 watches your domains and services from the outside — the way your users experience them. A fleet of independent scanner workers runs each check on a schedule; no agent, no cron, nothing to install.

Check Target What it verifies Interval
DNS domain Resolves A, AAAA, MX, TXT, CNAME, NS, SOA, CAA records and captures the values. 60 s
Domain reachability domain Probes four endpoints independently — http/https × www/apex — treating any HTTP response as reachable. 60 s
SSL/TLS certificate domain Common name, issuer, validity dates, days-to-expiry, self-signed and chain-valid flags. daily
Domain expiry domain Registration expiry, registrar and nameservers via WHOIS/RDAP. daily
Domain info domain Registrant/registrar detail and domain status. daily
Server reachability server ICMP ping with an automatic TCP-connect fallback; reports RTT and the method used. 60 s
Service reachability service Connects over http/https/tcp/udp and confirms the endpoint answers. per service (60 s default)
Service response service Validates HTTP status, body content, and optional JSON/XML well-formedness. per service (60 s default)

A scheduler runs every minute and, for each check type, selects the resources whose next-scan time is due, claims them with a row lock so two schedulers never double-book the same resource, and enqueues them in batches. Workers pick jobs off the queue, run the check, archive the full result, and report a compact summary back. This design scales horizontally — add workers, not complexity — and naturally rate-limits itself so a large estate spreads its load across the minute rather than stampeding.

Status vs outcome — why you don’t get false alarms

Section titled “Status vs outcome — why you don’t get false alarms”

Every check records two independent things, and understanding the split is key to trusting your alerts:

  • Status is the health of the check itself: queued, running, completed, failed, timeout.
  • Outcome is the finding: data_found, no_data, target_not_found, blocked, lookup_unavailable.

Crucially, outcomes of blocked (something actively refused the probe) and lookup_unavailable (a resolver or upstream was momentarily unavailable) are excluded from change detection and alarm evaluation. A flaky resolver or a transient network refusal does not open an incident — only a genuine, classified finding does.

SSL/TLS. The certificate check performs a direct TLS handshake and extracts the certificate chain. If the host is unreachable for a handshake, it falls back to public Certificate Transparency logs so you still get certificate visibility for endpoints that aren’t directly reachable.

Domain reachability. All four endpoint variants are probed independently and redirects are not followed, so you can see exactly which of http://, https://, www. and the apex actually answer — a redirect chain can’t mask a broken variant.

Service response. Beyond “is it up”, you can assert an expected HTTP status, require the body to contain a keyword, and validate that the response is well-formed JSON or XML. A short snippet of the response body is captured to help you diagnose mismatches.

Server reachability. ICMP ping is attempted first; where ICMP is blocked the check automatically falls back to a TCP connect and reports which method succeeded, so a firewall that drops ping doesn’t read as an outage.

For DNS, SSL, domain-expiry and domain-info checks, WatchTower15 tracks whether each result changed versus the last successful scan and links the two, so you can see when a certificate rotated or a DNS record moved. The heavy scan payloads are archived to object storage and only the extracted fields plus a pointer live in the database — you keep full history without ballooning storage.