Monitoring methodology
What we check, how changes are recorded, and the limits of observation.
Main principle
We separate resource state from observation quality. A problem means a confirmed resource condition; observation failure means we could not complete a reliable check.
DNS and mail
We observe published DNS records and selected rules. SPF, DMARC and MX describe domain settings. DKIM without a selector and the outbound path require a real test message.
DNS cache and TTL
DNS responses reflect the available resolver at observation time. Caches and TTL can delay changes; a resolver failure does not establish that a record was removed.
HTTP / HTTPS
We check DNS resolution, connection, HTTP status, redirects, timeout and response time. Failure at one observation point does not establish a site outage.
TLS / certificates
We check the TLS handshake, certificate, hostname and expiry. Expiry warnings are based on the observed certificate. Website TLS and MX STARTTLS describe different connections.
Website code and tags
You can monitor HTML, meta/script/verification tags and selected fragments of a chosen URL. A signal reports an observed value change, rather than its cause.
Blocklists
Results describe the tested sample and available sources. Inbound MX IPs do not establish outbound sender reputation. Failed or unavailable sources do not count as clean results.
Event types
Problem · Change · Recovery · Observation failure. Changes retain before → after, time and linked history. The first measurement establishes a baseline, rather than a change event.
Frequency
Frequency depends on the check and resource settings. The interface shows observation times; a snapshot time does not guarantee simultaneous checks or continuous availability.
Method limits
A snapshot records an observation, rather than continuous operation. Unknown, partial and stale evidence does not count as healthy. Inbox placement and the outbound IP require a separate message test.
Incomplete observations are marked directly in the event and report.