HTTP and HTTPS Checks

Your website might be down right now. Not crashed-down, but quietly broken—returning blank pages, displaying error messages, or taking 30 seconds to load. The server thinks everything is fine. Your users know otherwise.

HTTP and HTTPS checks solve this by pretending to be users. They visit your website repeatedly—every 30 seconds, every minute—and verify it actually works. Not just that the server responds, but that it responds correctly, quickly, and with valid security certificates.

What an HTTP Check Actually Does

An HTTP check sends a request to your URL and interrogates the response. It's asking several questions at once:

Did the server respond at all? A timeout means something is seriously wrong—the server is unreachable, overloaded, or dead.

What status code came back? A 200 OK means the server handled the request. A 404 Not Found means the page doesn't exist. A 500 Internal Server Error means something broke on the server side. A 503 Service Unavailable means the server is overwhelmed.

How long did it take? A website that responds in 30 seconds is functionally unusable, even if the status code says success. Response time is availability.

Is the content correct? This is where it gets interesting. A 200 OK is the server saying "I handled your request." It's not saying "I handled it correctly." A server can return 200 OK while displaying an error page, serving a blank page, or returning completely wrong content. Smart HTTP checks verify the response contains what it should—your company logo, a specific heading, expected data.

The HTTPS Difference

HTTPS checks do everything HTTP checks do, plus they verify your SSL/TLS certificate before users encounter scary browser warnings.

Certificates expire. When they do, browsers display full-page warnings telling users your site might steal their data. Most users leave immediately. HTTPS checks catch expiring certificates weeks before this happens.

Certificates must also match your domain, form a valid trust chain to a recognized Certificate Authority, and support modern encryption. A certificate for example.com won't work for www.example.com unless configured correctly. HTTPS checks catch all of this.

Beyond the Homepage

Checking your homepage tells you the web server is running. It doesn't tell you the application works.

Effective monitoring checks the paths users actually take:

Health endpoints are URLs your application exposes specifically for monitoring. A good /health endpoint tests database connectivity, cache systems, and external dependencies, returning detailed status. When this fails, you know exactly what broke.

Authentication pages are critical but overlooked. If users can't log in, they can't use your application—even if the homepage loads perfectly.

API endpoints matter if you have integrations. Your checkout API failing means lost revenue even if the marketing site looks beautiful.

Static resources from CDNs should be monitored separately. A CDN outage leaves your site technically accessible but visually destroyed—missing images, broken layouts, no styling.

The Lying Server Problem

Here's the genuine strangeness of web monitoring: servers lie.

Not maliciously. But a server can return 200 OK for almost anything. Your application might catch an exception and render a friendly error page—with a 200 status code. Your database might be down, so the page loads with empty content—status 200. Your CDN might serve a stale cached error page from three days ago—status 200.

This is why content validation matters. A check that verifies your homepage contains "Welcome" catches the server that returns 200 OK with a blank page. A check that verifies your product page contains a price catches the database connection that silently failed.

The status code tells you what the server thinks happened. Content validation tells you what actually happened.

Response Time Breakdown

When your site is slow, you need to know why. HTTP checks measure each phase of a request:

DNS resolution: How long to look up your server's IP address. Slow DNS adds latency before the request even starts.

Connection time: How long to establish a TCP connection. This reflects network distance and server availability.

TLS handshake: For HTTPS, how long to negotiate encryption. Slow handshakes often indicate server performance issues.

Time to first byte: How long until the server starts responding. This is your application's processing time.

Total time: Everything together—what users actually experience.

If DNS is slow, the problem is your DNS provider. If time to first byte is slow, the problem is your application. If total time is slow but first byte is fast, you're sending too much data. The breakdown reveals the cause.

Geographic Reality

Your server might work perfectly from your office while failing for customers across the world.

Internet routing problems can affect specific regions. Users in Asia might experience outages while North America has no issues. Your CDN might be misconfigured in Europe. A network provider's problem in South America might make your site unreachable there.

Checks from multiple geographic locations catch regional problems. They also reveal what users actually experience—the latency for someone in Tokyo connecting to your San Francisco server is fundamentally different from your local tests.

Request Configuration

HTTP checks can be configured for different scenarios:

GET requests retrieve pages—the standard check for websites.

POST requests send data, useful for testing APIs or health endpoints that require specific inputs.

HEAD requests retrieve only headers without the body, reducing bandwidth when you only care about status codes.

Custom headers let you include authentication tokens, API keys, or application-specific headers. This allows monitoring protected resources without exposing them publicly.

Redirect handling matters because websites redirect constantly. http:// redirects to https://, example.com redirects to www.example.com. Checks should follow redirects (up to a limit, to catch infinite loops) and measure the total time across the chain.

Timeout Strategy

Timeouts determine when "slow" becomes "down."

Set timeouts too high and users experience minutes of pain before monitoring notices. Set them too low and you get false alarms every time the server hiccups.

A reasonable starting point: 5 seconds to establish a connection, 10-15 seconds for the complete response. Adjust based on what your users will tolerate. If a 10-second page load means abandoned carts, your timeout should reflect that business reality.

Effective Patterns

Shallow and deep: Run frequent lightweight checks (every 30 seconds) for basic availability, plus less frequent thorough checks (every 5 minutes) that validate content and functionality.

Critical paths: Monitor what matters for your business. For e-commerce, that's product pages, cart, and checkout. For SaaS, that's login and core application features.

Dependency isolation: Monitor external services separately. When your payment provider's API is down, you want to know it's them, not you.