Automatic Host Monitoring: Uptime & TLS Alerts from Your Session Data

This article covers the automatic monitoring feature (host discovery, uptime checks, TLS certificate alerts) in LogNroll. Configuration values shown are defaults and are configurable per host and per company.

Why monitoring belongs next to replay

Session replay answers what happened in the browser; uptime and certificate checks answer is the service even reachable. The two are closer than they look. A checkout that suddenly fails for everyone is rarely a frontend bug—more often it is an API origin that went down, a CDN edge that started refusing HEAD requests, or a certificate that expired while the renewal pipeline silently stopped working.

Classic uptime tools ask you to configure a watchlist from memory: which hosts, which paths, which intervals. That setup drifts. Hosts get renamed, staging becomes production, someone spins up a second API region. LogNroll already records the URLs of every session—so the platform can build the watchlist from observed traffic instead of from what you remember.

The discovery loop: your sessions build the watchlist

Discovery runs on real traffic, not guesswork

A nightly job scans the URLs recorded in your sessions, extracts clean origins like https://app.example.com, and turns them into monitoring candidates. The watchlist builds itself from the hosts your users actually visit.

Private hosts are excluded by design

localhost, loopback, site-local, link-local, and pseudo-TLDs like .local, .lan, and .internal never become candidates. You only monitor the public endpoints that matter, and you never get surprise probes of internal infrastructure.

Candidates stay disabled until you say so

Discovered hosts are created as candidates with monitoring off. Activate the ones you care about with one click—discovery never re-enables or overwrites hosts you deliberately paused or deleted.

Concretely, a nightly job scans session URLs, normalizes them to origins (scheme://host[:port]), drops anything that is not a public HTTP(S) endpoint, and keeps only origins seen in at least a few sessions—so a stray link in an email does not create noise. Candidates land in the Monitoring tab with a session count, and you activate the ones you want. Nothing is monitored until you say so.

Engineering note

Discovery is deliberately one-directional. It can create a candidate, but it never enables monitoring, never re-enables a paused host, and never edits a manual host's settings. That invariant keeps automation safe: the system can suggest anything, but a human always owns the final decision.

Uptime checks that don't cry wolf

Every five minutes, from the same place that sees your users

Each enabled host is probed on its own schedule (default every 300 seconds) by a checker that wakes every minute. The probe uses HEAD first and falls back to GET when a server rejects HEAD—many load balancers return 403/404 for HEAD, and a naive checker would flag a perfectly healthy site.

Status, response time, and history in one place

Every probe writes a sample: up/down plus response time in milliseconds. Status moves UNKNOWN → UP or DOWN, samples are kept for 30 days, and uptime percentage plus average response are computed per host for 24h, 7d, and 30d windows.

Alerts fire once per incident, not once per probe

A DOWN transition sends exactly one alert; a later recovery sends exactly one more. You do not get a fresh email every five minutes while an outage lasts—just the state changes that actually need a human.

Probe behavior worth knowing

Probes use a browser user-agent and a 10-second timeout, and they keep the hostname check on during the TLS handshake. The checker does not fail a host just because its certificate chain is unusual—certificate health is judged by the daily certificate check, so the two signals stay independent instead of double-reporting the same problem.

TLS certificates: the outage you can schedule

Expiry is checked every day, automatically

A daily job reads the TLS leaf certificate of every enabled HTTPS host and classifies it as VALID, EXPIRING (within the renewal window), or EXPIRED. You see the issuer, the expiry date, and exactly how many days are left.

One alert when it enters the danger zone

The first time a certificate lands in EXPIRING (default: 30 days out) or EXPIRED, you get one email. When the certificate is renewed, the alert state clears automatically—so the next expiry cycle alerts again.

Renewal verification, not just detection

The check confirms the renewed certificate on the wire. Teams that see the alert, fix the automation, and redeploy get silent confirmation in the dashboard: days left resets and status returns to VALID.

Certificate expiry is the most predictable outage in web operations—and still one of the most common. Public CAs now issue certificates that live for roughly three months, which means the renewal pipeline must fire successfully twelve times a year per host. One broken cron, one expired API token for the DNS challenge, one cert-manager upgrade that changes the issuer—and you discover the problem the same way your users do: the browser's red warning screen.

Alerts that respect your inbox

Exactly once per incident

DOWN fires one email, RECOVERY fires one email, certificate expiry fires one email. State transitions alert; steady states stay quiet.

Control at every level

Per-host alert toggle, a per-company master switch in Settings → Alerts, and a global kill switch for alert emails. Defaults are on, so the feature works out of the box.

Test before you trust it

Both the error digest and the monitoring alert card ship test buttons that send a sample email to the signed-in user, so delivery, templates, and spam filtering are verified before an incident.

The monitoring dashboard

The Monitoring tab in the company dashboard is split into three parts: Discovered hosts (candidates with session counts and an Activate action), Monitored hosts (status, uptime 24h/7d/30d, average response, last checked, certificate badge with days left and issuer), and recent alerts. Each host gets an uptime chart, a check-now button for an instant probe, pause/resume, edit, and delete.

One row, the whole story

Host origin, check interval, check path, alerts on/off
Status tag (UP / DOWN / UNKNOWN / PAUSED) with uptime % across three windows
Certificate badge (VALID / EXPIRING / EXPIRED) with days left and issuer
Chart, check now, pause/resume, edit, delete—without leaving the row

What to monitor first

A good first pass takes ten minutes and covers the hosts that can actually take the product down:

Activate the discovered hosts that match your app, API, and marketing origins
Add manual hosts for anything session traffic never visits (internal status pages, partner endpoints)
Set tighter check intervals for checkout and auth paths than for marketing pages
Point checkPath at a real endpoint (e.g. /healthz) when "/" is served by a cache
Leave certificate alerts on the default 30-day window; act on the first EXPIRING email
Send test alerts once to confirm delivery and check the spam folder
Route alert emails to a group inbox or an email-to-Slack bridge
Use pause/resume during maintenance windows instead of deleting hosts

Common mistakes

Monitoring only what you remember

Hand-built watchlists miss the second API region, the new marketing host, the CDN origin. Discovery from session data closes exactly that gap—activate candidates rather than typing URLs from memory.

Ignoring cert alerts until the red screen

A certificate is either renewed on schedule or it isn't. Treat the first EXPIRING email as a ticket, not a notification—the 30-day window is there so renewal can be fixed while users still see a valid site.

Probing a cache, not the real origin

Checking "/" on a CDN-backed site verifies the edge, which is healthy by construction. Point checkPath at an endpoint that exercises your origin and database for a meaningful signal.

Where LogNroll fits

Monitoring is one more signal in the same product that already holds your sessions, errors, and network traces. When a host goes DOWN, the alert is the beginning of the investigation, not the end: the same platform can show you the replay of the user who hit the failure, the network timeline of the failed request, and the error group behind it—without stitching together three tools.

For the full capture pipeline that feeds discovery, see our session replay architecture guide. To turn production failures into debugging sessions, read When Error Logs Lie: Reproducing Production Failures with Session Replay, and for tracing the network side of an incident, Network Tab + Replay: Debug Failed API Calls in Context.

Conclusion

Automatic monitoring works because it reuses data you already have. Session URLs reveal the public hosts that matter; scheduled probes turn them into uptime history; a daily certificate read catches the expiry that would otherwise surface as a browser warning; and exactly-once alerts keep the signal loud without turning into noise. The result is a watchlist that builds itself, alerts that arrive once, and one fewer class of 3 a.m. outages.