How to Monitor Your Full Infrastructure Stack

Most organizations discover outages the wrong way — a customer calls, a user tweets, or someone notices the website is down during a routine check. By that point, the incident has already been running for minutes or hours, and real damage has been done: lost revenue, broken SLAs, eroded trust.

Full-stack infrastructure monitoring inverts this dynamic. Instead of waiting to be told something is broken, your monitoring platform actively checks every layer of your infrastructure on a continuous basis — as frequently as every 30 seconds — and alerts the right people the moment a failure is detected.

The goal is simple: know before your users do.

The challenge is that modern infrastructure has many layers, and failures at each layer look different and require different detection methods. A web server can be online and responding to pings while its application is returning 500 errors. An SSL certificate can expire silently until browsers start blocking users. A mail server IP can get blacklisted without any obvious symptoms until email delivery drops. Each of these requires a different monitoring approach.

The cost of incomplete monitoring

• •Network-only monitoring misses application failures. A server can respond to ICMP pings while its web app is completely broken.
• •HTTP-only monitoring misses infrastructure failures. DNS hijacking, SSL expiry, and mail server problems don't show up in HTTP checks.
• •No log monitoring means internal errors — crashes, authentication failures, disk warnings — go undetected until they become user-visible outages.

Full-stack monitoring closes all of these gaps.

What it monitors

ICMP ping monitoring checks whether a host is reachable at the network layer. It sends ICMP echo requests to the target IP address and measures round-trip time.

What it catches

• •Host completely offline (server crash, power failure, network partition)
• •High latency indicating network congestion or degraded routing
• •Packet loss indicating intermittent connectivity issues

What it misses

Ping checks only verify that a host is reachable at the IP layer. A server can respond to pings while its web application is returning errors, its database connection is broken, or its services have crashed but the OS is still running.

Use ping monitoring as a baseline health check, not as your only check for any critical service.

What to monitor with ping

• •All servers (web, database, application, file)
• •Network devices (routers, switches, firewalls) that support ICMP
• •Remote offices and branch locations
• •VPN endpoints

What it monitors

TCP port monitoring attempts to open a TCP connection to a specific port on a host. A successful connection confirms the service is listening and accepting connections.

What it catches

• •Service process crashed (web server, database, mail server stopped)
• •Firewall rule change blocking a port unexpectedly
• •Service bound to wrong interface (listening on localhost instead of all interfaces)
• •Port exhaustion or connection limits reached

Common ports to monitor

What it monitors

HTTP/HTTPS monitoring makes a real HTTP request to a URL and evaluates the response — status code, response time, and optionally response content.

What it catches

• •Web application returning error codes (500, 502, 503, 404)
• •Slow response times indicating performance degradation
• •Application crashes (process up but returning errors)
• •Load balancer or reverse proxy misconfigurations
• •CDN or caching issues returning stale or incorrect content

Key metrics to track

Status code: A 200 OK confirms the application is responding correctly. Any 4xx or 5xx response should trigger an alert.

Response time (Time to First Byte): TTFB is the time from request to the first byte of the response. Consistently high TTFB indicates server-side performance problems. Sudden spikes indicate load, a slow database query, or a backend service degradation.

Response content: The status code being 200 does not guarantee the application is working correctly. A misconfigured maintenance page or a broken deployment can return a 200 with incorrect content. Keyword monitoring (Layer 4) catches these cases.

What it monitors

Keyword monitoring makes an HTTP/HTTPS request and checks whether a specific string is present — or absent — in the response body.

What it catches

• •Maintenance pages replacing live content (a 200 OK that isn't actually your site)
• •Broken deployments where the app loads but core content is missing
• •Database failures where dynamic content stops rendering
• •Defacement or injection attacks adding unexpected content
• •E-commerce platforms where a product or checkout element has disappeared

Presence vs. absence checks

Presence check: Assert that a string MUST be in the response. Example: check that your homepage contains your company name, or that your API response contains "status":"ok".

Absence check: Assert that a string must NOT be in the response. Example: check that the page does not contain "503 Service Unavailable", "database error", or "maintenance mode".

What it monitors

SSL certificate monitoring connects to your TLS endpoint and reads the certificate metadata — specifically the expiry date, issuer, and subject — and alerts you a configurable number of days before the certificate expires.

Why SSL expiry is a bigger problem than it looks

An expired SSL certificate doesn't just show a warning — modern browsers actively block users from reaching your site, displaying a full-page "Your connection is not private" error. For e-commerce or SaaS products, this can mean complete loss of access for all users until the certificate is renewed.

Certificate expiry incidents are almost always preventable. They happen because auto-renewal failed silently, a renewal reminder was missed, or a wildcard certificate covers many subdomains but only one person tracks its expiry.

What to monitor

• •Every domain and subdomain serving HTTPS traffic
• •Wildcard certificates (one expiry point covers many subdomains)
• •Third-party hosted services where you control the domain but not the SSL management
• •Internal services using self-signed or private CA certificates

DNS monitoring

DNS monitoring checks that your domain's DNS records resolve to the expected values and alerts you if anything changes unexpectedly.

What it catches

• •DNS hijacking: an attacker modifies your DNS records to redirect traffic to a malicious server
• •Accidental DNS misconfiguration during a migration or infrastructure change
• •Registrar account compromise leading to unauthorized record changes

Domain expiry monitoring

Domain expiry monitoring queries WHOIS records for your domain's registration expiry date and alerts you in advance. A lapsed domain registration can be immediately acquired by domain squatters or, in targeted attacks, by adversaries who use it to intercept email or serve malicious content.

Why domains expire unexpectedly

• •Auto-renewal fails because the payment method on file expired
• •The registrar account email is an old address that no one monitors
• •A domain was registered by a former employee and ownership was never transferred

Why email monitoring is often overlooked

Email failures are silent. If your mail server goes down or your SPF record breaks, you don't get an error message — emails simply stop arriving or get silently rejected. By the time someone notices, important emails (customer inquiries, order confirmations, password resets) have already been lost.

What a full email server check covers

• •SMTP connectivity: Can a mail client connect to your mail server on port 25 (inbound) and port 587 (submission)?
• •STARTTLS: Is the connection upgrading to TLS? An unencrypted SMTP connection is a security risk and increasingly rejected by modern mail servers.
• •Open relay test: Is your mail server accepting mail for arbitrary external domains? An open relay will get your server blacklisted within hours.
• •SPF record: Does your domain's SPF TXT record correctly authorize the IP addresses that send email on your behalf?
• •DKIM: Is a valid DKIM public key published in DNS for your signing selector?
• •DMARC: Is a DMARC policy published? A missing DMARC record leaves your domain vulnerable to spoofing.

What it monitors

Blacklist monitoring queries DNSBL (DNS-based Block List), SURBL, and DBL zones to check whether your IP addresses or domains appear on spam and malware blocklists.

Why blacklist monitoring matters

If your mail server IP gets listed on a major DNSBL like Spamhaus or Barracuda, email delivery to recipients using those blocklists will fail silently. The sender gets no bounce — the message is simply dropped or rejected.

Common causes of blacklisting

• •A compromised server or user account sending spam
• •A misconfigured mail server acting as an open relay
• •A shared hosting environment where a neighboring server was compromised (shared IP reputation)
• •A domain used in a phishing campaign (domain blacklisting)

Key zones to cover

A comprehensive blacklist check should cover the major zones including Spamhaus (ZEN, DBL), SpamCop (SCBL), Barracuda (BRBL), SORBS, and up to 60 zones in total to catch listings on less common but still impactful lists.

What to check

• •Your outbound mail server IP addresses (all of them, including backup MX)
• •Your primary domain and any domains used in marketing campaigns
• •IP addresses of web servers that send email

Why log monitoring is the last line of defense

Every other monitoring type in this guide detects failures from the outside. Log monitoring detects failures from the inside — it reads what your applications and operating systems are actually reporting about their own health.

A database connection pool exhaustion, a recurring authentication failure, a disk filling up, a service restart loop — all of these events write to log files before they become visible to external monitoring checks.

What to monitor in logs

Application logs: Error-level events and exceptions, database connection failures, authentication failures (potential brute-force attack indicator), payment processing errors.

System logs: OOM (Out of Memory) killer events, disk space warnings, failed systemd service restarts, SSH login failures from unexpected IPs, kernel errors.

Web server logs: Spike in 500 errors, unusual request patterns (scanning behavior), specific error messages.

Failure thresholds

Not every failed check should immediately trigger an alert. Transient failures — a single packet loss, a momentary 503 — happen constantly in healthy infrastructure. Configure a failure threshold of 2–3 consecutive failures before alerting to eliminate false positives without significantly increasing detection time.

On a 1-minute check interval with a threshold of 2 failures, you'll know about a real outage within 2 minutes. That's an acceptable trade-off.

Notification channels by severity

• •Critical (immediate response): SMS to on-call engineer, Slack/Teams channel alert, email to the team
• •Warning (response within the hour): Email notification, Slack/Teams channel message
• •Recovery: Always send recovery alerts — include the incident duration so the team knows it's resolved without needing to check manually

Escalation policies

For critical infrastructure, configure escalation policies that ensure someone responds even if the primary contact misses the initial alert:

• •Alert the on-call engineer immediately
• •If unacknowledged after 10 minutes, alert the backup engineer
• •If unacknowledged after 20 minutes, alert the team lead
• •If unacknowledged after 30 minutes, alert the manager

Maintenance windows

Schedule maintenance windows for planned downtime — deployments, reboots, infrastructure migrations. During a maintenance window, checks continue running (so you have data continuity) but alerts are suppressed. This prevents paging your team for expected downtime and keeps alert history clean.

Multi-tenant isolation

Each client environment must be completely isolated — separate monitors, separate incident history, separate users, separate notification settings. A monitoring platform that co-mingles client data is a serious liability. Ensure your monitoring platform uses proper multi-tenant architecture where each client's data is scoped to their own isolated environment.

Per-client alerting

Each client has different stakeholders who need to receive alerts. Your internal NOC team needs to know about everything. The client's IT contact may need to know about critical incidents. Their management may want weekly summary reports but not individual alert notifications.

White-label reporting

Clients want to see uptime reports that reflect your brand, not your tool vendor's. Monthly SLA reports with your company logo and their service name build confidence and make the monitoring program tangible for clients who aren't watching dashboards day-to-day.

Key reports for MSP clients

• •Monthly uptime summary: Uptime percentage per service, incident count, total downtime
• •SLA compliance report: Uptime percentage vs. contracted SLA threshold, pass/fail per service
• •Incident timeline: Every outage with start time, duration, and resolution

Use this checklist to audit your current monitoring coverage and identify gaps.