DEV Community: DevHelm

Why We Built DevHelm

DevHelm — Sun, 17 May 2026 14:27:44 +0000

The era of monitoring tools built for human engineers is over.

Site reliability is undergoing a profound shift triggered by the agentic AI wave, and to understand why it matters, it helps to look at the pattern that came before. Every major innovation cycle until now was defined by a new environment that software runs in: on-premise to cloud, cloud to mobile, monolith to microservices. Through each of those transitions, humans remained indispensable to the SRE process. Humans debugged. Humans investigated. Humans identified root causes and remediated them, while communicating the full picture to customers and stakeholders along the way.

The next wave is different. AI SRE agents can now automate large parts of that process and free human time for the decisions that actually require judgment. An AI agent can conduct a root cause investigation, understand the blast radius of an incident, classify its priority, and surface that context to on-call engineers — all before a human has finished reading the first alert. In this environment, the speed of iteration on reliability increases dramatically. AI can investigate faster, identify patterns earlier, and be far more proactive about surfacing deep underlying issues by synthesizing information from sources that no single engineer would think to check at once.

In that world, the monitoring infrastructure itself becomes the agent's most critical tool. And for it to be effective, it has to be built in an agent-first, developer-first way. It must provide clear primitives for management, operations, and forensic investigation — alongside the external-facing artifacts that reliability demands, like status pages and incident communications. The old approach to SRE tooling, built around beautiful but unintegrated dashboards designed for human eyes, is fundamentally incompatible with this new paradigm.

That is why we built DevHelm. Our primary focus was to deliver a developer-first, API-first platform that supports operations in this new AI-driven reality. We are launching with uptime monitoring, dependency monitoring, status pages, and developer artifacts purpose-built for agentic operations: a native CLI, Cursor and Claude skills, Python and TypeScript SDKs, an MCP server, and a Terraform provider — all included from the free tier.

Our long-term goal is to build a unified reliability platform that powers the next generation of applications and services built in the agentic AI era.

We are just getting started. Try DevHelm free.

Originally published on DevHelm.

Introducing DevHelm

DevHelm — Sun, 17 May 2026 14:27:39 +0000

Today we are launching DevHelm — a reliability platform built to bring developer-first, agent-first monitoring infrastructure to the teams that need it most.

Seeing a massive shift in how site reliability is practiced, driven by the agentic AI wave, we decided that monitoring needed to be rebuilt around a different premise: something developers define in code, AI agents operate programmatically, and your entire team understands through clear external-facing artifacts. Everything we ship reflects that premise, from the core monitoring infrastructure to the way you interact with it.

Monitoring that understands your stack

At the foundation, DevHelm provides multi-protocol uptime monitoring — HTTP, DNS, TCP, and ICMP checks running from five continents at 30-second intervals with multi-region confirmation before any alert fires. That part is table stakes, and we made sure it works well.

What makes DevHelm different is what sits on top of it. We track over 100 external services — Stripe, AWS, GitHub, Auth0, OpenAI, and dozens more — and correlate their health with your monitors in real time. When a vendor degrades, you don't get a separate alert for every endpoint that happens to depend on it. You get one resource group alert that tells you what's affected and why, with the vendor incident already linked. The goal is signal, not noise: your team should spend time fixing problems, not figuring out whether a problem is even yours to fix.

Built for developers and their agents

The monitoring infrastructure is only useful if it's accessible to the tools and workflows that actually operate your stack. That's why every capability in DevHelm is available through a full developer surface from the free tier: a native CLI, Python and TypeScript SDKs, a Terraform provider, an MCP server, and pre-built skills for Cursor and Claude. Monitors can be defined in a YAML config in your repo and deployed through your CI pipeline — no dashboard clicks required.

In practice, this means an AI agent working in Cursor or Claude can define monitors, configure alert routing, set up a status page, and investigate an incident through the same programmatic interfaces a human developer would use. The platform doesn't distinguish between the two, because in the operating model we're building for, it shouldn't have to.

Status pages and incident communication

Reliability isn't just an internal discipline — it has an external face. Every DevHelm account includes a public status page with custom domain support, real-time monitor status, and subscriber notifications. Status pages are not an upsell; they are part of the reliability infrastructure, and they're included from day one.

What's next

We are launching with uptime monitoring, dependency intelligence, status pages, and the full developer artifact surface. This is the foundation. Our roadmap builds toward a unified reliability platform: deeper forensic investigation tools, richer incident lifecycle management, and tighter integration with the AI agents that increasingly operate alongside engineering teams.

Try DevHelm free — 50 monitors, a status page with custom domain, and the full developer surface. No credit card.

Originally published on DevHelm.

What SSL Error Means and How to Fix It

DevHelm — Sun, 17 May 2026 14:22:13 +0000

An SSL error means your browser or HTTP client could not complete the TLS handshake with the server. The connection was dropped before any data was exchanged. Instead of your page, your users see a full-screen warning — and most of them leave.

The term "SSL error" is a holdover. SSL (Secure Sockets Layer) was deprecated in 2015 when RFC 7568 declared SSL 3.0 obsolete. Every modern HTTPS connection uses TLS (Transport Layer Security) — versions 1.2 or 1.3. Browsers still display "SSL" in error codes because the names stuck, but the protocol under the hood is always TLS. Throughout this article, "SSL error" refers to any TLS handshake failure your browser surfaces.

What happens during a TLS handshake

When a browser connects to an HTTPS server, the TLS handshake negotiates a shared encryption key. The server presents its certificate, the browser verifies the chain of trust back to a root CA, checks the hostname, and confirms the certificate has not expired. If any step fails, the browser aborts and shows an error page.

The three most common failure points:

Certificate validity — the cert is expired, not yet valid, or revoked
Hostname mismatch — the cert was issued for api.example.com but the browser hit www.example.com
Chain of trust — an intermediate certificate is missing, or the cert is self-signed

Understanding which step failed tells you exactly where to look.

Decode the error message — Chrome, Firefox, and Safari

Different browsers surface different error codes for the same underlying TLS failure. This table maps the most common ones:

Problem	Chrome	Firefox	Safari
Expired certificate	`NET::ERR_CERT_DATE_INVALID`	`SEC_ERROR_EXPIRED_CERTIFICATE`	"This certificate has expired"
Wrong hostname	`NET::ERR_CERT_COMMON_NAME_INVALID`	`SSL_ERROR_BAD_CERT_DOMAIN`	"This certificate is not valid for the requested site"
Self-signed cert	`NET::ERR_CERT_AUTHORITY_INVALID`	`SEC_ERROR_UNKNOWN_ISSUER`	"This certificate was signed by an unknown authority"
Incomplete chain	`NET::ERR_CERT_AUTHORITY_INVALID`	`SEC_ERROR_UNKNOWN_ISSUER`	"This certificate is not trusted"
TLS version too old	`ERR_SSL_VERSION_OR_CIPHER_MISMATCH`	`SSL_ERROR_UNSUPPORTED_VERSION`	Connection refused (no specific code)
Revoked certificate	`NET::ERR_CERT_REVOKED`	`SEC_ERROR_REVOKED_CERTIFICATE`	"This certificate has been revoked"

If you see ERR_SSL_PROTOCOL_ERROR in Chrome, the server likely rejected the handshake outright — possibly because it only supports TLS 1.0/1.1 (both deprecated) or has a misconfigured cipher suite.

Fix 1 — Expired or not-yet-valid certificate

An expired certificate is the single most common cause of SSL errors. Certificates have a fixed validity window — typically 90 days for Let's Encrypt and up to 398 days for paid CAs.

Diagnose it with openssl:

openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -dates

Example output:

notBefore=Feb 15 00:00:00 2026 GMT
notAfter=May 16 23:59:59 2026 GMT

If notAfter is in the past, the cert has expired.

Fix it:

Renew the certificate through your CA or ACME client (certbot renew, for example)
Reload your web server — sudo systemctl reload nginx or sudo systemctl reload apache2
Verify the new cert is live: re-run the openssl command above and confirm the dates

If your cert is not yet valid (notBefore is in the future), either the cert was issued early and installed before activation, or your server clock is wrong. Check with date -u and sync via NTP if needed.

Fix 2 — Wrong hostname or missing SAN

Your certificate must cover the exact hostname the client connects to. A cert issued for example.com does not automatically cover www.example.com — that requires a Subject Alternative Name (SAN) entry.

Diagnose it:

openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Example output:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

If the hostname your users hit is not listed, you need to reissue the certificate with the correct SANs — or use a wildcard cert (*.example.com). Wildcard certs cover one level of subdomains only; *.example.com matches api.example.com but not v2.api.example.com.

A common mistake: deploying behind a load balancer or CDN and forgetting that the cert on the edge must match the public hostname, not the origin hostname.

Fix 3 — Incomplete chain or self-signed certificate

Browsers verify certificates by walking the chain from your server cert through intermediate CAs to a trusted root. If an intermediate is missing, the chain breaks and the browser shows ERR_CERT_AUTHORITY_INVALID.

Diagnose the chain:

openssl s_client -connect yoursite.com:443 -servername yoursite.com -showcerts 2>/dev/null | grep "s:" | head -5

A healthy chain shows your cert, then one or two intermediates, ending at the root:

s:CN = yoursite.com
s:CN = R11, O = Let's Encrypt
s:CN = ISRG Root X1, O = Internet Security Research Group

If you see only your cert with no intermediates, your server is not sending the full chain. Fix it by concatenating the intermediate cert(s) with your server cert. For Nginx:

cat server.crt intermediate.crt > bundle.crt

Then reference bundle.crt in your Nginx config's ssl_certificate directive and reload.

Self-signed certificates fail on public-facing sites because they are not issued by a trusted CA. Replace them with a cert from Let's Encrypt (free) or any recognized CA. Self-signed certs are fine for internal services — but add them to your internal trust store explicitly rather than telling users to "click through the warning."

Fix 4 — Mixed content and HSTS issues

Mixed content errors happen when an HTTPS page loads a resource (image, script, stylesheet) over plain HTTP. Modern browsers block mixed active content (scripts, iframes) entirely and show a broken padlock for mixed passive content (images).

Find mixed content using your browser's developer console (F12 → Console tab). The browser logs every blocked resource with its URL.

Fix it by updating hardcoded http:// URLs to https:// or using protocol-relative paths. If you use a CMS, update the site URL in settings.

HSTS (HTTP Strict Transport Security) adds another layer: once a browser has seen an HSTS header, it refuses to connect over HTTP at all — even if the cert is temporarily broken. If you deployed a broken cert and HSTS is active, users cannot click through the warning. The only fix is deploying a valid cert. You can inspect cached HSTS policies in Chrome at chrome://net-internals/#hsts.

Fix 5 — Client-side false positives

Not every SSL error is a server problem. Three common client-side causes:

System clock skew. Certificates are time-sensitive. If a laptop's clock is set to 2024, a cert valid from 2026 appears "not yet valid." Fix: enable automatic time sync in the OS.
Antivirus TLS inspection. Some antivirus software intercepts HTTPS connections by inserting its own root certificate. If the AV root is not trusted by the browser — or if the AV botches the re-encryption — the browser shows an SSL error. Temporarily disabling the AV's "web shield" or "HTTPS scanning" confirms this as the cause.
Corporate proxy. Transparent HTTPS proxies (common in enterprise networks) perform the same kind of TLS interception. The corporate root CA must be installed on the client machine. If it is not, every HTTPS site shows a certificate warning.

These are real scenarios, not edge cases. If users report SSL errors that you cannot reproduce, ask about their local environment first.

Prevent SSL errors with certificate monitoring

You have seen how certificates break: expiry, hostname mismatches, incomplete chains, mixed content, client-side false positives. Every one of these failures is predictable. Certificates do not expire by surprise — they have a fixed lifetime printed right in the X.509 data. The problem is never that the failure was unknowable. The problem is that nobody was watching.

The fix-then-forget cycle is the real trap. You renew the cert, confirm it works, and move on. Ninety days later, the same NET::ERR_CERT_DATE_INVALID reappears because the auto-renewal cron broke silently two weeks ago and nobody noticed until a customer opened a support ticket at 2 AM.

Here is how to build a monitor that catches every failure mode we covered — before your users do.

Set up two expiry thresholds, not one

Most monitoring setups check whether the certificate expires within some number of days and call it done. That is not enough. You need two thresholds: an early warning and a hard deadline.

Let's Encrypt certificates last 90 days. If auto-renewal is working, you will never think about expiry. But if it breaks — a DNS validation failure, a misconfigured certbot hook, a container rebuild that lost the renewal cron — you want to know at 30 days remaining, not the day it expires. A WARN-severity assertion at 30 days gives your team two full weeks to investigate and fix the renewal pipeline without any urgency. A FAIL-severity assertion at 14 days is the hard deadline: drop everything and renew manually, because you are two weeks from a full outage.

Validate the endpoint, not just the certificate

A valid certificate does not mean your site works. The cert could be fine while your origin returns 502s, or while a misconfigured cipher suite causes 15-second handshakes that make the page feel broken. Adding a status code check (expected: 200) and a response time threshold (thresholdMs: 2000) catches the class of problems where TLS technically succeeds but the user experience is degraded. Slow TLS handshakes often point to missing OCSP stapling, oversized certificate chains, or a server negotiating an expensive cipher when a faster one is available.

Monitor from multiple regions

This is the one most teams skip, and it is the one that bites hardest. If you run behind a CDN — Cloudflare, AWS CloudFront, Fastly — your certificates are managed per edge location. A cert that is perfectly valid on the us-east edge node might already be expired on an ap-south node because the edge cert rotation did not propagate uniformly. Checking from a single region gives you a false sense of security. Checking from us-east, eu-west, and ap-south catches regional cert failures before the affected users report them.

Pick the right check frequency

Certificates change slowly. Unlike an API endpoint that might go down and recover in seconds, certificate state transitions happen once every 90 days (or 398 days for paid CAs). Running SSL checks every 30 seconds is wasteful — you are burning check quota on a signal that changes a handful of times per year. A 5-minute interval (frequencySeconds: 300) gives you more than enough visibility. If a cert expires, you will know within 5 minutes. The trade-off is worth it: save the high-frequency checks for your API health endpoints where seconds matter.

The full config

Here is a DevHelm monitor that covers everything above — expiry thresholds, endpoint validation, multi-region checks, and a sensible frequency:

{
  "name": "production-ssl-health",
  "type": "HTTP",
  "frequencySeconds": 300,
  "regions": ["us-east", "eu-west", "ap-south"],
  "config": {
    "url": "https://yourapp.com",
    "method": "GET"
  },
  "assertions": [
    { "config": { "type": "status_code", "operator": "equals", "expected": 200 } },
    { "config": { "type": "response_time", "thresholdMs": 2000 } },
    { "config": { "type": "ssl_expiry", "minDaysRemaining": 14 } },
    { "config": { "type": "ssl_expiry", "minDaysRemaining": 30 }, "severity": "WARN" }
  ]
}

The first two assertions confirm the endpoint is healthy and responsive. The third fires a critical alert at 14 days before expiry — your hard deadline. The fourth fires a warning at 30 days — your early warning that gives you time to fix the renewal pipeline without scrambling.

You can create this monitor from the CLI in one command:

devhelm monitor create --type http

Or configure it through the dashboard. 50 monitors free, no credit card required.

Start monitoring free

Originally published on DevHelm.

How to Fix Slow DNS Lookup: A Complete Troubleshooting Guide

DevHelm — Sun, 17 May 2026 14:22:07 +0000

Every connection your application makes starts with a DNS lookup. When that lookup is slow — or fails entirely — the symptoms range from vague latency increases to hard-down pages that return ERR_NAME_NOT_RESOLVED. This guide walks through how to fix slow DNS lookup issues, diagnose two of the most common DNS errors (DNS_PROBE_FINISHED_NXDOMAIN and "DNS server not responding"), and set up monitoring so these problems never wake you up at 3 AM again.

Why DNS lookups slow down

A DNS lookup traverses multiple layers before returning an IP address. Your stub resolver asks a recursive resolver, which queries root nameservers, then TLD nameservers, then the authoritative nameserver for the domain. Each hop adds latency. In a best case — a warm cache hit on the recursive resolver — resolution takes under 1 ms. In the worst case — a cold cache, long CNAME chains, DNSSEC validation, and an authoritative server on another continent — it can exceed 500 ms.

The most common causes of slow DNS resolution:

Overloaded or distant ISP resolvers. ISP DNS servers are shared infrastructure. During peak hours, query times spike from 20 ms to 200 ms or more.
Low TTL values. A TTL of 60 seconds means every cache expires every minute, forcing full recursive lookups. TTLs under 300 seconds are a common source of unnecessary latency.
CNAME chains. Each CNAME adds an extra lookup. A domain with three CNAME hops requires four total resolutions before returning an A record.
IPv6 fallback. When a system queries for AAAA records first and the authoritative server is slow to respond (or doesn't support IPv6), the client waits for a timeout before falling back to A records — adding 2–5 seconds.
VPN and split-tunnel DNS conflicts. Corporate VPNs often route DNS traffic through a tunnel to an internal resolver, adding 50–150 ms of round-trip latency that doesn't exist when the VPN is off.

Measure first — what "slow" actually means

Before changing anything, measure your current DNS performance. The dig command (Linux/macOS) and nslookup (Windows) are the standard diagnostic tools.

Measure with dig:

dig devhelm.io

The output you care about is at the bottom:

;; ANSWER SECTION:
devhelm.io.          300     IN      A       143.198.168.42

;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sun May 11 14:32:07 UTC 2026
;; MSG SIZE  rcvd: 56

The Query time line is what matters. Here is a reference table:

Query time	Rating	Action
< 15 ms	Excellent	No action needed
15–50 ms	Good	Acceptable for most workloads
50–100 ms	Poor	Switch resolver or investigate upstream
100+ ms	Critical	Immediate action required

Compare resolvers directly:

dig @1.1.1.1 devhelm.io | grep "Query time"
dig @8.8.8.8 devhelm.io | grep "Query time"
dig @9.9.9.9 devhelm.io | grep "Query time"

If your default resolver is 3–5x slower than Cloudflare (1.1.1.1) or Google (8.8.8.8), that is the first thing to fix.

Measure with nslookup on Windows:

nslookup devhelm.io
Server:  resolver1.isp.net
Address:  192.168.1.1

Non-authoritative answer:
Name:    devhelm.io
Address:  143.198.168.42

nslookup does not show query time directly. For timing on Windows, use PowerShell:

Measure-Command { Resolve-DnsName devhelm.io } | Select-Object TotalMilliseconds

Fix slow DNS lookup on your machine

These fixes address the most common causes of slow resolution, in order of impact.

1. Flush your local DNS cache

Stale or corrupted cache entries can cause lookups to hang or return wrong results. Flush first, then re-test.

macOS:

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo resolvectl flush-caches
resolvectl statistics | grep "Current Cache Size"

Windows:

ipconfig /flushdns

2. Switch to a faster public resolver

If your ISP resolver is slow, change to Cloudflare (1.1.1.1), Google (8.8.8.8), or Quad9 (9.9.9.9). These resolvers have global anycast networks that consistently resolve in under 15 ms from most locations.

Linux (/etc/resolv.conf or systemd-resolved):

sudo resolvectl dns eth0 1.1.1.1 1.0.0.1
sudo resolvectl dns eth0 # verify

macOS (System Settings > Network > DNS):

networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1

3. Disable IPv6 DNS if you do not use it

If your network does not have working IPv6 connectivity, AAAA queries add timeout delays to every lookup. Test whether IPv6 is the problem:

dig AAAA devhelm.io @1.1.1.1 | grep "Query time"
dig A devhelm.io @1.1.1.1 | grep "Query time"

If the AAAA query is significantly slower or times out, consider disabling IPv6 resolution on your machine or configuring your resolver to deprioritize AAAA lookups.

4. Check your VPN's DNS configuration

VPNs commonly override DNS settings, routing queries through the tunnel. If DNS is slow only when connected to a VPN:

cat /etc/resolv.conf   # Linux: check which DNS server is active
scutil --dns | head -20 # macOS: check DNS configuration

If the resolver points to a VPN-provided address (e.g., 10.x.x.x), configure split-tunnel DNS so that only internal domains route through the VPN resolver.

How to fix DNS_PROBE_FINISHED_NXDOMAIN

DNS_PROBE_FINISHED_NXDOMAIN means the DNS resolver returned an NXDOMAIN response — the domain does not exist in DNS. Chrome, Edge, and Brave all surface this as an error page. The domain either genuinely does not exist, or something between your machine and the authoritative nameserver is blocking or misconfiguring the lookup.

Diagnosis, in order:

1. Verify the domain is correct. Typos account for most NXDOMAIN errors. Check for swapped letters, missing hyphens, and wrong TLDs (.com vs .io vs .dev).

2. Test from multiple resolvers. If your default resolver returns NXDOMAIN but a public resolver resolves the domain, your resolver has stale or filtered data:

dig example.com @1.1.1.1
dig example.com @8.8.8.8
dig example.com @$(cat /etc/resolv.conf | grep nameserver | head -1 | awk '{print $2}')

3. Check the authoritative nameserver directly. This confirms whether the domain's NS records are configured correctly at the registrar:

dig NS example.com @1.1.1.1
dig example.com @ns1.registrar.com

If the authoritative server itself returns NXDOMAIN, the domain's DNS zone is misconfigured or the domain has expired. Check with your registrar.

4. Flush DNS and restart the DNS client. A cached NXDOMAIN response (negative caching, per RFC 2308) can persist for the SOA minimum TTL, which defaults to hours on some zones.

5. Check your hosts file. A local override in /etc/hosts (Linux/macOS) or C:\\Windows\\System32\\drivers\\etc\\hosts (Windows) can shadow DNS entirely. Remove any stale entries for the domain.

6. Disable Chrome's secure DNS if it conflicts. Chrome aggressively prefetches DNS for links on a page. If prefetch queries go to a different resolver than your system default, you can get spurious NXDOMAIN errors. Navigate to chrome://settings/security and check the "Use secure DNS" setting — ensure it matches your intended resolver.

How to fix DNS server not responding

"DNS server not responding" means your machine sent a DNS query and received no reply at all — not even an error. This is different from NXDOMAIN (which is a valid response saying "this domain does not exist"). No response means the resolver itself is unreachable or unresponsive.

Systematic diagnosis:

Step 1: Confirm basic connectivity

Separate "network is down" from "DNS is down":

ping -c 3 1.1.1.1

If ping fails, the problem is your network connection, not DNS. Check cables, Wi-Fi, and router.

If ping succeeds, your network is fine but DNS is specifically broken. Continue.

Step 2: Test the DNS port directly

DNS uses UDP port 53 (and TCP 53 for large responses). Test whether your resolver is accepting connections:

dig @1.1.1.1 devhelm.io +tcp +timeout=5

If this works but normal queries fail, something is blocking UDP port 53 — commonly a firewall, router ACL, or ISP filter.

Step 3: Check your router

Home and office routers often run a local DNS forwarder. If the router's DNS process crashes or its upstream configuration is wrong, all devices on the network lose DNS.

Access your router admin panel (typically 192.168.1.1)
Check the configured upstream DNS servers
Try setting them to 1.1.1.1 and 8.8.8.8 as primary and secondary
Reboot the router

Step 4: Check for firewall or security software blocking DNS

Firewalls (especially on corporate networks), antivirus software, and parental control tools sometimes intercept or block DNS traffic. Temporarily disable them to isolate:

sudo iptables -L -n | grep 53

Step 5: Try DNS over HTTPS (DoH)

If your ISP is throttling or intercepting standard DNS (UDP/TCP port 53), DNS over HTTPS bypasses the interception by sending queries over HTTPS on port 443:

Firefox: Settings > Privacy & Security > Enable DNS over HTTPS
Chrome: Settings > Security > Use secure DNS > Select Cloudflare or Google
System-wide (Linux): Configure systemd-resolved with DNSOverTLS=yes

When the problem is upstream

Sometimes slow DNS is outside your control. Before blaming your resolver or network, check whether the problem is upstream:

Authoritative nameserver issues. The domain owner's nameserver may be slow or misconfigured. Test with dig +trace example.com to see exactly where in the resolution chain the delay occurs.
CDN misrouting. CDNs like Cloudflare and AWS CloudFront use DNS-based geographic routing. If your resolver's IP geolocation is wrong, you may be routed to a distant edge node. This is common with VPNs and small ISP resolvers.
Registrar glue record problems. If a domain's nameservers are under the same domain (e.g., ns1.example.com for example.com), the registrar must provide glue records — the A records for the nameservers themselves. Missing glue records create a circular dependency that manifests as timeouts.
Enterprise split-horizon DNS. In corporate environments, internal and external DNS zones overlap. A query for api.company.com might resolve to an internal IP on VPN and a public IP off VPN — or fail entirely if the split-horizon configuration has gaps.

Prevent DNS failures with monitoring

Everything you have done so far in this guide — flushing caches, switching resolvers, tracing NXDOMAIN responses, checking firewall rules — is reactive. You noticed a problem, diagnosed it, and fixed it. But the next DNS failure will not look like this one. An A record vanishes because someone fat-fingers a Terraform apply. A TTL gets dropped to 30 seconds during a migration and never gets reverted. Resolution times creep from 20 ms to 150 ms over three weeks because an upstream nameserver is quietly degrading. None of these announce themselves. They just erode your reliability until a user files a ticket or your on-call phone rings at 3 AM.

A single "is DNS working?" check does not cover this. What you need is a layered set of assertions that catches the different ways DNS silently breaks.

Layer 1: Does it resolve at all?

The most fundamental check. A dns_resolves assertion confirms that your domain actually returns records — that the A record exists, that the AAAA record exists, that the response is not NXDOMAIN or SERVFAIL. If your A record disappears because of a zone file mistake or a registrar lapse, you find out in five minutes instead of five hours when customers start reporting a blank page.

Check both A and AAAA record types. Even if your application is IPv4-only, a broken AAAA record causes timeout-based fallback delays on clients that try IPv6 first — the exact problem covered in the IPv6 section above. Monitoring both means you catch issues on either path.

Layer 2: Does it resolve fast enough?

DNS that technically resolves but takes 200 ms adds 200 ms to every single page load, every API call, every webhook delivery. This latency is invisible in dashboards that only track HTTP response time because the DNS overhead happens before the connection even opens.

Two thresholds give you the coverage you need. A hard failure assertion (dns_response_time with a maxMs of 100) fires when resolution exceeds a critical ceiling — something is actively broken, whether that is an overloaded resolver, a network path change, or an authoritative server on another continent. A softer warning assertion (dns_response_time_warn with a warnMs of 50) fires at a lower threshold so you catch gradual degradation before it compounds into an outage. The warning gives you time to investigate during business hours. The hard failure pages your on-call immediately.

Layer 3: Are the TTLs healthy?

Low TTLs are a silent performance killer, and they show up constantly in the kinds of issues this guide covers. A TTL of 30 seconds means every visitor's browser, every edge server, and every recursive resolver on the planet discards the cached record every half minute and triggers a full recursive lookup. During a migration, it is common practice to temporarily lower TTLs to speed up propagation — and then forget to raise them back afterward.

A dns_ttl_low assertion with a minTtl of 300 catches exactly this. If someone — or an automated provisioning tool — drops your TTL below five minutes, you get a warning before the extra lookup load starts inflating resolution times across the board.

Layer 4: Check from multiple vantage points

DNS is not globally consistent. A record that resolves correctly from a probe in us-east might be stale, missing, or pointing to the wrong IP in ap-south because of propagation delays, regional resolver differences, or geo-DNS misconfigurations. If you only check from one region, you are testing your DNS health from one perspective and assuming the rest of the world agrees. It often does not.

Running checks from at least three regions — us-east, eu-west, and ap-south — ensures your monitoring reflects what your actual users experience rather than what a single datacenter sees.

Layer 5: Check against specific nameservers

By default, each probe region uses whatever recursive resolver is locally available. That is usually fine, but it means you can miss issues that are specific to a particular public resolver. Explicitly setting your nameservers to 1.1.1.1 and 8.8.8.8 — Cloudflare and Google, the two most widely used public resolvers — lets you test resolution from the same infrastructure your users are most likely hitting. If your domain resolves from Google but not Cloudflare (or vice versa), that points to a propagation issue or a resolver-specific caching problem that would otherwise be invisible until someone on the affected resolver reports it.

Putting it all together

Here is a complete DNS monitor configuration that implements all five layers:

{
  "name": "production-dns-health",
  "type": "DNS",
  "frequencySeconds": 300,
  "regions": ["us-east", "eu-west", "ap-south"],
  "config": {
    "hostname": "yourapp.com",
    "recordTypes": ["A", "AAAA"],
    "nameservers": ["1.1.1.1", "8.8.8.8"]
  },
  "assertions": [
    {"config": {"type": "dns_resolves"}},
    {"config": {"type": "dns_response_time", "maxMs": 100}},
    {"config": {"type": "dns_response_time_warn", "warnMs": 50}, "severity": "WARN"},
    {"config": {"type": "dns_ttl_low", "minTtl": 300}, "severity": "WARN"}
  ]
}

Every five minutes, from three continents, this monitor resolves yourapp.com for both A and AAAA records against Cloudflare's and Google's DNS. It fails hard if the domain does not resolve at all or if resolution takes longer than 100 ms. It warns if resolution exceeds 50 ms or if the TTL drops below 300 seconds.

The severity: "WARN" on the TTL and response time warning assertions is deliberate. These are degradation signals, not outage signals — they belong in a dashboard and a Slack channel, not in your PagerDuty rotation. The resolution check and the hard response time ceiling default to error severity, which is what triggers your incident workflow. The distinction matters: you want to know about creeping latency during business hours, and you want to be woken up for a missing A record.

You can create this monitor through the DevHelm dashboard, or from the terminal:

devhelm monitor create --type dns

Start monitoring free — DNS, HTTP, TCP, and ICMP checks from five continents, with the full CLI and API surface included.

Originally published on DevHelm.