Uptime monitoring types compared

At-a-glance comparison

Each type, in depth

1. HTTP monitoring

Sends requests to a target URL and records status codes and response time. Miterl checks from multiple regions (Tokyo / Singapore) so regional outages are also caught.

• Recommended interval: 1–3 minutes (Pro: 30 seconds)
• Best for: public sites and API endpoints
• Common false alarms: transient network spikes — tune retry thresholds

2. Keyword monitoring

Checks whether the response body contains a required keyword (or does NOT contain a forbidden one). Catches cases where the server returns 200 OK but the page itself shows an error — e.g. a Laravel exception page during DB outages.

• Required keyword examples: “My account” after login, “Thank you for your order” on confirmation
• Forbidden keyword examples: “Whoops, looks like something went wrong”, “Database connection failed”

3. DOM Integrity monitoring

Parses HTML and validates SEO-critical tags such as title, canonical, og:image, noindex, and robots. Prevents post-deploy disasters like a stray noindex or a missing OGP image breaking your share previews.

• Checked tags: title, description, canonical, og:title, og:image, robots, noindex
• Best for: media, LPs, corporate sites, blogs

4. Heartbeat monitoring

Your batch pings a Miterl-issued URL on completion. Miterl watches whether the ping arrives within the expected interval. Catches batch- and cron-level failures that external monitoring cannot see.

• Interval examples: 5 minutes, 1 hour, 1 day, 1 week
• Tunable grace periods avoid false alarms on slow runs

5. SSL monitoring

Periodically validates TLS certificate expiry and intermediate chain integrity. Prevents the “Let's Encrypt auto-renew silently broke” class of incidents. Typical alerts fire 30 and 7 days before expiry.

• Alert timings: 30 days, 7 days, and after expiry
• Covers wildcards and SAN certificates

6. Ping monitoring

Checks whether a host answers ICMP. Where HTTP monitoring asks “can visitors load the site,” Ping asks “is the machine alive.” A dead web server on a live host will not be caught here, so pair it with HTTP for public sites.

• Best for: non-HTTP servers and network equipment
• Note: unusable on hosts that block ICMP

7. TCP monitoring

Opens a TCP connection to a specific port. Catches outages in middleware that does not speak HTTP — MySQL on 3306, SMTP on 25, SSH on 22. It cannot tell you that an open port is answering with garbage.

• Best for: databases, mail servers, SSH, custom protocols
• Recommended interval: 1–5 minutes

8. WHOIS monitoring (domain expiry)

Reads domain expiry via RDAP (falling back to WHOIS where RDAP is unavailable) and alerts as the date approaches. Like SSL, it works without any access to the server, so an agency can watch domains that the client registered themselves.

• Alert timings: 30, 14, and 7 days before expiry
• Expiry dates appear alongside SSL in the expirations dashboard

9. robots.txt monitoring

Watches the contents of robots.txt. Shipping a staging “Disallow: /” to production and forgetting to revert it goes unnoticed until search traffic disappears — HTTP monitoring returns a healthy 200 the whole time.

• Best for: freshly launched or relaunched sites
• noindex via meta robots is covered by DOM Integrity instead

10. MX monitoring

Monitors the domain’s MX records. If MX vanishes or is rewritten, inbound mail stops while the site itself keeps looking perfectly healthy — which is why these incidents surface late, usually as “I think we stopped getting enquiries.”

• Best for: any site that depends on inbound mail
• Especially valuable right after a DNS or server migration

11. SPF monitoring

Checks that an SPF record exists and parses (RFC 7208), including the ten-lookup limit and syntax errors. A broken SPF does not bounce mail — it quietly routes it to spam, which looks like success from the sending side.

• Catches: missing records, syntax errors, lookup limit overruns
• Re-check after adding any new sending service

12. DMARC monitoring

Monitors the DMARC record and its policy (RFC 7489). As you move from p=none toward quarantine or reject, it keeps confirming the record has not silently reverted or been invalidated by a syntax error.

• Catches: missing records, syntax errors, policy changes
• Useful as evidence on projects with anti-spoofing requirements

13. DKIM monitoring

Monitors DKIM public keys per selector (RFC 6376). Catches the rotation mistakes — a selector deleted too early, or a new key never published. Multiple selectors can be registered per monitor.

• Catches: vanished selectors, malformed keys, unpublished rotations
• Valuable when sending through SendGrid, Amazon SES, and similar

How to combine them

Pattern A: Baseline (corporate / LP / blog)

HTTP + DOM Integrity + SSL — covers “down,” “broken content,” and “certificate expiring.”

Pattern B: E-commerce / checkout flows

Pattern A plus Keyword monitoring. Watch the post-checkout success message specifically — so you know when revenue-impacting flows break, not just the homepage.

Pattern C: SaaS / API backend

HTTP across multiple endpoints + Heartbeat for nightly/batch jobs + SSL. DOM Integrity is usually unnecessary here.

Pattern D: Agency maintenance fleet (50–200 sites)

HTTP + SSL + WHOIS on every site, DOM Integrity only on SEO-critical accounts. SSL and WHOIS need no server access, so they work on infrastructure the client owns. Where enquiry forms drive revenue, add MX and SPF to catch “the site is up but the mail never arrived.” Use Workspaces to segment by customer and route alerts.

FAQ

Q. Can I attach multiple types to one URL?

Yes. HTTP + DOM Integrity + SSL on the same URL is the most common setup.

Q. Which type fits internal systems behind a VPN?

Heartbeat is ideal — your server pings outward, so VPN/firewall restrictions don’t block monitoring.

Q. How do I avoid duplicate alerts?

Miterl collapses concurrent incidents on the same URL into one. You can also set notification suppression rules.