Nagios HTTPS monitoring: practical check_http and check_curl checks

By Greg Nowak. Last updated 2026-07-15.

A green port-443 check does not prove that a customer can use your website. The server may return the wrong virtual host, an expired certificate, a broken redirect or a generic error page while the monitor still reports success.

Useful HTTPS monitoring starts with a business question: can a real user reach the correct page or endpoint, receive the expected content and do so within an acceptable time? Nagios can answer that question, but only when each check has an explicit purpose.

There is also an important maintenance change. The current Monitoring Plugins documentation marks check_http as deprecated and recommends check_curl as its replacement. Existing checks do not need to disappear overnight, but new and revised checks should normally use check_curl.

Decide what each check must prove

Business risk	Signal to monitor	Practical choice
The wrong site answers	Expected hostname and content	Use `-H` and a stable content marker
A key journey is unavailable	Controlled application path	Check `/health`, `/login` or another meaningful endpoint
TLS becomes invalid	Trust, hostname and remaining validity	Use `check_curl -D -C`
A redirect goes somewhere unexpected	Redirect policy and final content	Follow only when the destination is intentionally acceptable
The site is technically up but unusably slow	Response time	Set warning, critical and timeout values from operational expectations

A useful monitor connects each technical check to a failure somebody actually needs to handle.

Avoid making one check prove everything. Separate service availability, certificate expiry and important application journeys when they have different owners or escalation paths. More checks are worthwhile only when each alert tells the responder what to investigate.

A practical check_curl baseline

For a public website with a predictable marker, this is a sensible starting point:

/usr/local/nagios/libexec/check_curl -H example.com --ssl -D --onredirect=curl --string 'Example Domain' -w 5 -c 10 -t 15

This requests the correct virtual host, uses HTTPS, verifies the certificate and hostname, follows redirects using libcurl, confirms the expected content and applies response-time thresholds. The explicit 15-second timeout sits above the 10-second critical threshold; leaving the plugin’s default 10-second timeout alongside -c 10 can make the resulting alert less clear.

Replace the example thresholds with values based on normal performance and user impact. Review historical response times first. A warning should indicate degradation worth investigating, while critical should mean the service is no longer commercially acceptable—not simply slower than an ideal laboratory result.

Prefer a controlled health endpoint

Homepages are fragile monitoring targets. Redesigns, translations, consent banners and personalization can change their content without affecting availability. If the application team controls a stable endpoint, use it:

/usr/local/nagios/libexec/check_curl -H example.com -u /health --ssl -D --string 'ok' -w 3 -c 8 -t 12

The endpoint should test enough of the application to be meaningful. A hard-coded ok response can remain green while the database or a required dependency is broken. Conversely, an endpoint that exercises every third-party integration can create noisy alerts. Agree what “healthy” means with the application owner.

Use --string for fixed text, -r for a regular expression or -R for a case-insensitive expression. Choose a durable application marker rather than marketing copy.

Check a specific origin without losing the hostname

During a CDN migration, DNS cutover or load-balancer investigation, you may need to contact one address while retaining the production host header:

/usr/local/nagios/libexec/check_curl -H example.com -I 203.0.113.10 -u /login --ssl -D --string 'Sign in' -w 5 -c 10 -t 15

With check_curl, -I changes the network destination while -H preserves the virtual host. Test this manually from the Nagios server before deploying it because firewalls, split DNS and proxy environment variables can make the monitoring route differ from the public user route.

Treat redirects as part of the journey

Following redirects is appropriate when several valid entry points intentionally converge on one canonical page. It is dangerous when a redirect to staging, another brand or an authentication error should itself trigger an alert.

Use --onredirect=curl when the final destination and its content define success. For stricter monitoring, configure redirects as warning or critical and create a separate check for the expected destination. That makes accidental redirect changes visible instead of hiding them behind a successful final response.

Make certificate monitoring explicit

For a focused certificate check, warn 21 days before expiry and become critical at seven days:

/usr/local/nagios/libexec/check_curl -H example.com -C 21,7 -D

The -D option matters: check_curl does not verify the certificate chain and hostname by default. Certificate age alone is not complete TLS validation.

If you intentionally combine certificate and content monitoring, add --continue-after-certificate:

/usr/local/nagios/libexec/check_curl -H example.com -u /health --ssl -D -C 21,7 --continue-after-certificate --string 'ok' -w 3 -c 8 -t 12

Separate checks usually produce clearer alerts, but the combined form can suit a small estate with simple ownership.

Migrate check_http without creating noise

Inventory existing definitions, group them by pattern and test equivalent check_curl commands from the monitoring host. Compare exit codes, output, redirect handling, timing and proxy behavior before changing production definitions. Prioritize revenue sites, client portals and TLS-sensitive services, then move routine checks in controlled batches.

During triage, this remains a handy first pass over a text log:

grep -Ei 'critical|invalid|warning' logfile.log

GNU recommends grep -E rather than the obsolete egrep command. The search is useful for investigation, but recurring failure phrases should eventually become explicit checks, documented thresholds and assigned actions.

Monitoring should make the next action obvious

The strongest Nagios setup is not the one with the most services. It is the one where a warning has a known owner, a critical alert reflects genuine impact and responders can quickly distinguish DNS, TLS, application and performance failures.

If your monitoring estate contains inherited one-liners, inconsistent thresholds or checks that nobody quite trusts, Greg can help review the definitions and turn them into a small, maintainable operating system for your sites and client handovers. Talk to Greg about practical monitoring improvements.