Choosing the Right Monitoring Checks

Matching checks to your infrastructure

Different parts of your stack fail in different ways. A DNS misconfiguration looks nothing like an expired SSL certificate, and neither one shows up the same way as a broken API endpoint. Using the right check type for each service means faster detection and fewer false alarms.

Most production setups use a combination of check types. A typical web application might need HTTP checks for the main site, SSL monitoring for certificate expiration, DNS checks for name resolution, and API monitoring for critical endpoints.

HTTP and HTTPS checks

HTTP checks are the foundation of uptime monitoring. They send a request to a URL and verify the response status code, headers, and optionally the response body.

A basic HTTP check confirms that your server returns a 200 OK. More advanced configurations validate specific response headers, check that the response body contains expected content, or verify that redirects land on the correct destination.

HTTPS checks add TLS handshake verification. If your certificate is misconfigured, uses a weak cipher suite, or your server has a protocol mismatch, an HTTPS check catches it during the connection phase, before the request even completes.

When to use HTTP/HTTPS checks:

• Public-facing websites and web applications
• REST APIs that return standard HTTP status codes
• Webhook endpoints that need to stay reachable
• Landing pages and marketing sites

TCP monitoring

TCP checks operate at the transport layer. They open a socket connection to a specific host and port and verify that the connection succeeds. No HTTP protocol parsing, no content validation, just a raw connection test.

This makes TCP monitoring the right choice for services that do not speak HTTP: database servers (port 5432 for PostgreSQL, 3306 for MySQL), mail servers (port 25, 587, or 993), Redis instances (port 6379), and custom TCP-based services.

When to use TCP checks:

• Database servers exposed to application nodes
• Mail servers and SMTP relays
• Cache layers like Redis or Memcached
• Any non-HTTP service where you need to verify port accessibility

DNS monitoring

DNS monitoring verifies that your domain names resolve correctly. A DNS check queries a domain and validates that the response contains the expected record type and value (A, AAAA, CNAME, MX, or TXT).

DNS problems are insidious because they can take down your entire online presence while every individual server remains perfectly healthy. A misconfigured DNS record, an expired domain, or a registrar issue can make your site unreachable to the whole internet.

When to use DNS checks:

• After DNS migrations or record changes
• For domains using multiple DNS providers
• When monitoring MX records for email delivery
• For critical domains where resolution failures would be catastrophic

SSL certificate monitoring

SSL monitoring tracks your TLS certificates and alerts you before they expire. An expired certificate triggers browser warnings that scare users away and break API integrations that enforce certificate validation.

Good SSL monitoring checks more than just the expiration date. It should also verify the certificate chain, flag weak key sizes, and alert on certificates that will expire within a configurable window (e.g., 30, 14, or 7 days before expiration).

When to use SSL monitoring:

• Every domain serving HTTPS traffic
• Domains with certificates from different providers
• Environments where certificates are manually renewed
• APIs consumed by third parties who enforce certificate checks

Keyword monitoring

Keyword checks combine an HTTP request with a content assertion. The monitor fetches a page and searches the response body for a specific string or pattern. If the keyword is missing, the check fails.

This catches a category of problems that standard HTTP checks miss entirely: your server returns a 200 OK, but the page shows an error message, a blank template, or cached stale content. Keyword monitoring verifies that the actual content users see is correct.

When to use keyword checks:

• E-commerce product pages (verify the "Add to Cart" button text exists)
• Login pages (verify the login form renders)
• Checkout flows (verify pricing or payment form elements appear)
• Any page where a 200 response does not guarantee correct content

API monitoring

API monitoring sends structured requests to your endpoints and validates the full response: status code, response time, headers, and body content. You can chain multiple requests together to test multi-step workflows like authentication followed by data retrieval.

For teams building APIs that external customers depend on, API monitoring goes beyond availability. It validates that your API contract is intact, that response schemas match expectations, and that performance stays within acceptable bounds.

Hyperping supports API monitoring with configurable request methods, headers, body payloads, and response assertions.

When to use API checks:

• Public APIs with documented contracts and SLAs
• Internal microservice endpoints
• Third-party API dependencies your application relies on
• Webhook receivers that process incoming payloads

Putting it all together

Start with HTTP checks for your most important public URLs. Add SSL monitoring for every domain. Layer in DNS checks for critical domains and TCP checks for non-HTTP infrastructure. Use keyword checks where content correctness matters, and API monitoring for endpoints with strict response requirements.

The next chapter covers how to configure check intervals and thresholds to minimize false positives while catching real outages quickly.