If you look after a revenue site, client portal, or campaign landing page, a green port-443 check is not enough. The useful question is whether a real user can reach the right host, get the expected redirect, receive the expected page or endpoint, and do it within a response time your team would actually consider acceptable. That is why check_http has stayed popular in Nagios environments for years: it is readable, easy to hand over, and already present in many client estates.
The important update is that the current Monitoring Plugins documentation now marks check_http as deprecated and recommends check_curl as the replacement. That does not make your existing checks worthless. It does mean new checks, refreshes, and TLS-sensitive environments should be designed more deliberately, with clearer success criteria and a migration path that reduces alert noise instead of adding to it.
What a useful Nagios HTTPS check should prove
A good HTTPS check should answer a business question, not just a server question. For most teams, that question is simple: can a user reach the correct page or application endpoint quickly enough for the site to remain commercially usable?
- Use the real hostname with
-H, especially on shared hosting, CDNs, reverse proxies, and virtual hosts. - Check a stable path such as
/health,/status,/login, or another controlled endpoint instead of a noisy home page when you can. - Match a stable marker with
--string,-r, or-Rso the check proves the right app responded, not just any HTML page. - Set
-wand-cthresholds around user impact, support expectations, and client tolerance, not wishful server timings.
Those four decisions matter more than any single one-liner. They are also what separates a check people trust from a check everyone learns to ignore.
A sensible check_http baseline
For legacy Nagios setups, this is still a reasonable starting point for a brochure site, small client site, or public landing page where the content is fairly stable:
/usr/local/nagios/libexec/check_http -H example.com --ssl --onredirect=follow --string 'Example Domain' -w 5 -c 10That checks the correct host header, uses HTTPS, follows expected redirects, confirms a known string in the response body, and alerts on slow performance at levels a human can interpret quickly.
If you control the application, a purpose-built endpoint is usually better than checking the homepage:
/usr/local/nagios/libexec/check_http -H example.com -u /health --ssl --string 'ok' -w 3 -c 8This reduces false positives from redesigns, localization, cookie banners, and cached front-end fragments. If the response text varies, switch from --string to -r or -R and match a durable pattern instead of brittle exact wording.
Use host headers and paths intentionally
Many bad web checks fail for the wrong reasons. A shared server or load balancer can return a technically valid HTTPS response from the wrong virtual host. A homepage can render while checkout, login, or the client portal is broken. The fix is usually to be more explicit, not more complex.
If you need to test a specific address while preserving the correct host header, combine -H with -I:
/usr/local/nagios/libexec/check_http -H example.com -I 203.0.113.10 -u /login --ssl --string 'Sign in' -w 5 -c 10That pattern is useful when you are troubleshooting a load balancer member, validating a DNS cutover, or checking origin behaviour behind a CDN before public traffic moves. It gives operations teams a more targeted signal without changing the user's live path.
Handle redirects and certificate checks on purpose
Redirects are not automatically harmless. If HTTP should always move to HTTPS, following redirects is sensible. If a redirect to a staging hostname, the wrong language path, or an unexpected domain would represent a real business problem, then the check should warn or go critical instead of following it blindly. Monitoring should reflect the intended user journey, not hide mistakes inside a green status.
Certificate age is still worth checking on its own because expiry failures are public, disruptive, and often noticed first by clients rather than by internal teams:
/usr/local/nagios/libexec/check_http -H example.com -C 21,7That warns below 21 days and goes critical below 7. The limitation matters, though: current docs still state that check_http does not validate hostname matching or CA trust. So a passing result here is useful, but it is not the same as full modern TLS verification.
For new work, prefer check_curl
This is the practical recommendation for agencies and operations teams standardizing checks across multiple sites. The current Monitoring Plugins docs describe check_curl as the replacement for check_http, and it keeps a familiar command shape while adding certificate and hostname verification with -D.
/usr/local/nagios/libexec/check_curl -H example.com --ssl -D --onredirect=curl --string 'Example Domain' -w 5 -c 10For application-owned endpoints, you can also combine certificate-age monitoring with a content check in one definition:
/usr/local/nagios/libexec/check_curl -H example.com -u /health --ssl -D -C 21,7 --continue-after-certificate --string 'ok' -w 3 -c 8If you are refreshing an older Nagios estate, the sensible path is usually not a same-day rewrite of every web check. Keep stable legacy definitions where they already work. Make check_curl the default for all new services, high-value client sites, and environments where TLS correctness is part of the risk profile.
Keep triage simple and repeatable
The old grep note is still useful for first-pass log review:
grep -i -e 'critical' -e 'invalid' -e 'warning' logfile.logOn current GNU grep, the shorter equivalent below is the better habit than relying on old egrep muscle memory:
grep -Ei 'critical|invalid|warning' logfile.logThat is not a monitoring strategy by itself, but it is a fast way to spot recurring failure language while you turn manual troubleshooting into explicit checks, documented thresholds, and clear alert ownership.
If your current monitoring still depends on half-remembered one-liners, mixed plugin behaviour, or checks nobody fully trusts, the problem is usually not Nagios. It is the lack of agreed success criteria and operational ownership. Greg can help turn those ad hoc checks into a small, maintainable monitoring setup that works across client handovers, agency teams, and production environments.
Talk to Greg about practical monitoring improvements.
Need help with this kind of work?
Need help turning ad hoc site checks into dependable monitoring across client and production environments? Talk to Greg. Get in touch with Greg.