Synthetic Monitoring Series — Part 3 of 8

TLS, HTTP, and the Full Request Lifecycle

“The site is slow.” That sentence tells you almost nothing. Slow where? Slow for whom? Is it the network, the server, the certificate negotiation, the DNS resolver?

A single, well-constructed HTTP check answers all of those questions simultaneously — by decomposing a web request into its component phases and measuring each one independently. Add TLS monitoring on top, and you’ve covered one of the most consequential and consistently overlooked failure modes in production: the expired certificate that nobody caught.

Start Here: What the Videos Cover

▶  Video 6 — “TLS/SSL — Trust, Encryption, and Certificate Monitoring”

▶  Video 7 — “HTTP/HTTPS — Anatomy of a Web Check”

TLS: The Failure Mode That’s Always Preventable

Certificate expiration is the most preventable type of outage. And it still takes down billion-dollar companies — major streaming services, large banks, even government portals have gone offline because a certificate expired or an auto-renewal silently failed.

How the TLS handshake works

When a browser connects to an HTTPS site, a TLS handshake happens before any application data flows. In TLS 1.2 this takes two round-trips; TLS 1.3 (RFC 8446, 2018) reduced it to one. Faster, more secure, and now the standard you should expect from any modern server.

What a synthetic TLS check actually validates

Most engineers think of TLS monitoring as “check if the cert is expired.” That’s necessary but not sufficient.

A check running every hour, tracking days-to-expiry across all your domains, costs almost nothing. The cost of forgetting is measured in incident minutes and customer trust. Set alerts at 30 days out and again at 7 — the first is a reminder, the second is a fire drill.

The auto-renewal failure problem: Let’s Encrypt and similar services automate certificate renewal, which has dramatically reduced cert-expiry outages. But automation fails silently. A misconfigured renewal job, a DNS propagation issue, a firewall rule blocking the ACME challenge — any of these can cause auto-renewal to fail without triggering any visible alert. Continuous certificate monitoring is the safety net for the safety net.

HTTP: Turning “Something Is Slow” Into a Diagnosis

Once TLS is established, an HTTP check has five distinct phases to measure. Each one points to a different layer of your infrastructure.

DNS | Phase 1 — DNS Resolution

The check resolves the hostname to an IP address before any connection is established.

Slow result → misconfigured or overloaded resolver; investigate DNS before anything else.

TCP | Phase 2 — TCP Connection

The three-way handshake. A pure measurement of raw network latency — geographic distance and routing efficiency.

Slow result → network congestion or routing inefficiency. Application tuning won’t help here.

TLS | Phase 3 — TLS Handshake

Certificate exchange and encryption key derivation.

Slow result → check certificate chain depth, OCSP configuration, and TLS 1.3 support.

TTFB | Phase 4 — Time to First Byte

How long the server takes to start responding after the connection is established. This is where application processing lives: database queries, authentication, rendering, business logic.

Slow result → application bottleneck. Pull application logs, not network logs.

DL | Phase 5 — Content Download

How long the full response body takes to transfer after the first byte arrives. A bandwidth measurement.

Slow result → network capacity constraint or unexpectedly large response payload. Check response size first.

Reading the Waterfall: Three Diagnostic Patterns

The real power of HTTP phase decomposition is pattern recognition. Here are three scenarios that appear regularly in production environments — and what they tell you to do.

Pattern 1 | The Resolver Problem

DNS 400msTCP 28msTLS 45msTTFB 180msDL 12ms

DNS is disproportionately slow; everything else is normal. This is a resolver issue — misconfigured upstream, failing cache, or DNS-based load balancing misbehaving. Start there, not in the application.

Pattern 2 | The Application Bottleneck

DNS 30msTCP 25msTLS 40msTTFB 3,200msDL 15ms

Every infrastructure layer is fast. The server is slow. Something in the application is blocking: a long database query, a downstream API timeout, or resource contention. Pull application logs — not network logs.

Pattern 3 | The Oversized Response

DNS 28msTCP 24msTLS 38msTTFB 120msDL 4,500ms

Everything is fast until content transfer. Check the response size — an uncompressed asset, an unexpected data payload, or a misconfigured response is the likely culprit.

One check. Five phases. Three completely different diagnoses — each pointing to a different team, a different tool, and a different fix. That’s why HTTP phase decomposition is the backbone of every synthetic testing strategy.

The Operational Takeaway

Start your HTTP monitoring here: one check per critical endpoint, running every 60 seconds, with phase-level timing recorded. Add SSL expiry tracking with alerts at 30 days and 7 days out, across every public-facing domain you operate.

This combination covers the majority of availability and performance issues that affect users directly — before any user needs to tell you something is wrong.

Next in the Series

Part 4 — Beyond HTTP: WebSockets, Databases, and AI Services. The protocols that HTTP checks will never see.

Synthetic MonitoringTLS MonitoringSSL Certificate MonitoringHTTP MonitoringTTFBWeb PerformanceInfrastructure ObservabilitySRECertificate Expiry

About Parlon
Parlon is an infrastructure observability platform built for enterprise teams operating complex, hybrid environments. Parlon combines active synthetic validation, real-time telemetry normalization, and learning-based alerting into a single platform — shifting operations from firefighting to foresight. Learn more at parlon.io.