To monitor DNS/hosting separately from app downtime, split monitoring into layers so each failure mode has its own check and alert.

1) Monitor DNS resolution independently

Track whether your domain resolves correctly, even if the app is down.

What to check

• A/AAAA records: do they return the expected IPs?
• NS records: are nameservers correct?
• TTL / propagation: did recent DNS changes propagate?
• DNS response latency and SERVFAIL/NXDOMAIN errors

How

Use a DNS-specific monitor from multiple regions:

• dig yourdomain.com A
• dig yourdomain.com NS
• dig yourdomain.com @1.1.1.1
• dig yourdomain.com @8.8.8.8

Alert on

• Record changes from expected values
• Resolution failure
• High lookup latency
• Nameserver failures

---

2) Monitor hosting / infrastructure separately

This tells you whether the server or platform is reachable, regardless of the app.

What to check

• Ping/ICMP (if allowed)
• TCP port checks: 80/443/22/etc.
• Host uptime
• CPU, memory, disk, load
• Cloud instance health / VM status
• Load balancer / reverse proxy health

How

• Check if the server responds on the expected ports
• Use infrastructure monitoring tools:
  • Prometheus + node_exporter
  • Datadog / New Relic / Grafana Cloud
  • UptimeRobot / Pingdom / Better Stack for external checks

Alert on

• Host unreachable
• Port closed
• Instance stopped/rebooting
• Resource exhaustion

---

3) Monitor the app separately

This is your “is the application actually working?” check.

What to check

• HTTP status codes
• Response content
• API health endpoints like /health
• Synthetic transactions: login, search, checkout, etc.
• Dependency checks: DB, cache, queue

How

• GET /health should return a simple success
• Better: GET /ready or /status to check real dependencies
• Use synthetic checks from outside your network

Alert on

• 5xx responses
• Slow response times
• Incorrect page content
• Health endpoint failing due to app dependencies

---

Best practice: layer your checks

A clean setup is:

1. DNS monitor
   “Can the domain resolve?”

2. Host monitor
   “Can I reach the server/IP/port?”

3. App monitor
   “Does the app return the right response?”

This helps you distinguish:

• DNS problem: domain doesn’t resolve, but server might still be up
• Hosting problem: DNS works, but server/port is unreachable
• App problem: DNS and server are fine, but app returns errors

---

Example alert logic

• DNS alert if A record changes or domain doesn’t resolve
• Hosting alert if port 443 is unreachable for 2–3 checks
• App alert if /health returns non-200 or content is wrong
• Escalation alert if both host and app checks fail

---

Recommended setup

If you want this separated cleanly, use:

• External DNS monitor
• External TCP/HTTP uptime monitor
• Internal host metrics
• App synthetic checks

That way you can answer:

• “Is it DNS?”
• “Is it the server?”
• “Is it the app?”

If you want, I can also show you a sample monitoring architecture or a tool-specific setup for Datadog, Prometheus, Cloudflare, or UptimeRobot.