Monitoring

Domain Checks

Monitor a domain's registration expiry, DNS records, SSL certificates, and Certificate Transparency logs in one check. Get early warning for phishing, DNS hijacking, and lapsed renewals.

What are Domain Checks?

Domain checks watch everything that can break or change about a domain — not whether a server is up, but whether the domain itself is healthy and under your control.

A single domain check monitors four things:

  1. Domain registration expiry — so a forgotten renewal never takes you offline
  2. DNS records — so unexpected changes (or hijacking) get caught immediately
  3. SSL certificate expiry — so browsers never show your customers a security warning
  4. Certificate Transparency logs — so you know the instant a new certificate is issued for your domain, by anyone

No API keys or third-party accounts are required. Registration data comes from RDAP (the ICANN-standard successor to WHOIS), DNS is read via DNS-over-HTTPS, and certificate data comes from public Certificate Transparency logs.

Setting Up a Domain Check

  1. Navigate to Monitoring in the navigation bar
  2. Click Add Check
  3. Select Domain (expiry, DNS & certificates)
  4. Enter the registered domain to watch (e.g., example.com — no https:// or path)
  5. Configure the options below
  6. Click Create

[Screenshot: Domain check configuration]

Domain Registration Expiry

Alert24 looks up your domain's registration via RDAP and tracks:

  • Expiration date — when the registration lapses
  • Registrar — who the domain is registered with

You'll be alerted when the domain expires within your warning threshold (default: 30 days, configurable). Registration expiry is one of the most common — and most preventable — causes of total outage.

DNS Record Monitoring

Alert24 takes a snapshot of your DNS records on every check and alerts you when they change. Each record type is opt-in, so you watch exactly what matters:

Record Type What changes to it can mean
A Your site now points at a different IPv4 address — hosting change or hijack
AAAA Same as A, for IPv6
MX Your email is being routed somewhere else
NS Your entire domain is being served by different nameservers — a classic hijack signal
TXT SPF / DKIM / DMARC or domain-verification records were tampered with
CNAME A subdomain now points somewhere else — a common subdomain-takeover vector
CAA The list of certificate authorities allowed to issue certificates for your domain changed

By default, A, AAAA, MX, and NS records are watched. TXT, CNAME, and CAA can be enabled per check.

When a record changes, the alert tells you exactly which records were added and which were removed — so "If you made this change, no action is needed" takes two seconds to confirm.

Note: When you enable a new record type on an existing check, the first check establishes a baseline for that type. You won't get a false "changed" alert just for turning it on.

Certificate Transparency Monitoring

Certificate Transparency (CT) is a public, append-only log of every SSL/TLS certificate issued by participating certificate authorities. Because any certificate issued for your domain appears in CT — whether you requested it or not — watching these logs is one of the strongest early-warning signals for phishing and domain impersonation.

When CT monitoring is enabled, Alert24 watches the CT logs (via crt.sh, with Cert Spotter as a fallback) and alerts you when a new certificate appears for your domain or its subdomains.

Expected Issuers (Noise Suppression)

Let's Encrypt renews certificates every 60–90 days. CDNs reissue certificates on their own schedule. You don't want an alert for any of that.

The expected-issuer allowlist solves this: list the certificate authorities you legitimately use (e.g., Let's Encrypt, Google Trust Services, DigiCert), and routine certificates from those issuers stay silent. Only certificates from other issuers raise an alert — because those are the ones that might be someone impersonating your domain.

Leave the allowlist empty to be alerted about every newly issued certificate.

Subdomain Coverage

With Include subdomains enabled (the default), CT monitoring also covers certificates issued for any subdomain — so a certificate for login-secure.example.com that you never requested triggers an alert. Phishing campaigns frequently use unexpected subdomains of look-alike or compromised domains.

How Domain Alerts Work

Domain checks distinguish between two kinds of problems:

  • Availability problems (the domain has expired, RDAP/DNS can't be reached) follow the normal up/down path: consecutive-failure thresholds, linked service status, and incident creation.
  • Change and security events (DNS records changed, a new certificate was issued) do not mark your domain as down. They raise security events with their own severity, open a dedicated incident, and notify your organization's owners, admins, and responders by email — without polluting your uptime metrics.

Each event type opens at most one incident at a time per check. If DNS changes again while the previous DNS-change incident is still open, you won't get spammed with a second incident.

Event Default Severity
DNS records changed Medium
New certificate detected High
Domain expiring soon Follows check failure path

Configuration Reference

Option Default Description
Expiry warning threshold 30 days Alert when registration expires within this many days
Monitor DNS records On Snapshot and diff DNS records on every check
DNS record types A, AAAA, MX, NS Which record types to watch (TXT, CNAME, CAA available)
Certificate Transparency Off Watch CT logs for newly issued certificates
Include subdomains On Also alert on certificates issued for subdomains
Expected certificate issuers (empty) Comma-separated allowlist; renewals from these issuers stay silent

Recommended Setup

For most production domains:

  1. Watch A, AAAA, MX, NS, and CAA records
  2. Enable Certificate Transparency monitoring with subdomains included
  3. Add your real certificate authorities to the expected-issuer allowlist (check your current certificate's issuer if unsure)
  4. Link the check to the service that depends on the domain
  5. Assign an escalation policy so certificate events page the right person

See Check Configuration for intervals, thresholds, and service linking that apply to all check types.