By Greg Nowak. Last updated 2026-09-08.
A green Nagios dashboard should mean something useful to the business. An open port 443 tells you a server is listening; it does not tell you whether a customer can reach the right website, trust its certificate or use an important service.
For business owners and agency teams, the practical question is: what would this check catch before a customer calls? Start there, then choose the endpoint, expected response and person responsible for acting.
There is also a maintenance decision. The Monitoring Plugins documentation marks its check_http as deprecated and recommends migrating to check_curl. Plan that migration, but check your installed package: the online manuals describe a development build, and available options can differ.
Decide what each HTTPS check must prove
Keep checks separate when failures need different responses. A certificate renewal warning belongs in a planned maintenance workflow; an unavailable customer portal may need immediate attention.
| Check | What success means | First action on failure |
|---|---|---|
| Public website | Correct hostname, valid TLS and expected content | Check DNS, CDN and application response |
| Application health | A controlled endpoint confirms required dependencies work | Review application and dependency status |
| Certificate | Trusted certificate with enough validity remaining | Check renewal and certificate deployment |
| Canonical redirect | The entry URL follows the agreed redirect policy | Inspect redirect rules and destination |
| Specific origin | The selected backend answers for the production hostname | Inspect that backend and its network route |
A successful request to a login page does not prove that login works. Keep browser or transaction tests for journeys that require JavaScript, authentication or several steps.
Start with a readable check_curl command
Confirm the executable path and supported options on your monitoring server:
/usr/local/nagios/libexec/check_curl --version
/usr/local/nagios/libexec/check_curl --helpThen adapt this public-page example:
/usr/local/nagios/libexec/check_curl -H example.com -u / --ssl -D --onredirect=critical --string 'Example Domain' -w 5 -c 10 -t 15This checks HTTPS content and certificate validity, treats redirects as critical, and sets warning, critical and timeout values in seconds. The timeout sits above the critical response-time threshold. See the check_curl option reference for supported flags.
Replace the hostname, content marker and thresholds. Agree what response time is acceptable for the service, using historical measurements as a starting point. Plugin timings measure the monitoring request, not a browser's complete page load.
Use an endpoint the application team can maintain
Homepages change with campaigns, translations and redesigns. A controlled health endpoint gives the monitoring configuration a more durable contract:
/usr/local/nagios/libexec/check_curl -H example.com -u /health --ssl -D --onredirect=critical --string 'application-health:ok' -w 3 -c 8 -t 12The marker here is illustrative: your endpoint must actually return it. Avoid a broad string such as ok, which could appear in unrelated content. Fixed text works well for a stable response; -r and -R support regular-expression matching when needed.
Agree what the endpoint checks. A static response can stay green while the database is unavailable. Testing every optional integration can make a minor supplier problem look like a complete outage. Include dependencies required for the service you are promising, and keep diagnostic details out of public responses.
Make redirects and origin checks deliberate
For an entry URL that should redirect, --onredirect=curl follows redirects using libcurl. Validate the final content, and remember that following successfully does not enforce an approved destination hostname. Where the destination itself matters, add an explicit redirect-target assertion in a dedicated check.
During a DNS cutover or CDN investigation, contact a particular origin while retaining the production hostname:
/usr/local/nagios/libexec/check_curl -H example.com -I 203.0.113.10 -u /login --ssl -D --onredirect=critical --string 'Sign in' -w 5 -c 10 -t 15Replace the documentation address with your origin address. This is a separate diagnostic view: it bypasses public DNS selection and may bypass the CDN. Keep the public check too. Check proxy settings and firewall access before interpreting a failure as an application problem.
Check certificate trust as well as expiry
Use a separate certificate check to give renewal work a clear owner:
/usr/local/nagios/libexec/check_curl -H example.com -C 21,7 -DThis warns below 21 days remaining and becomes critical below seven. Adjust those windows to your renewal process. The -D flag enables certificate and hostname verification; check_curl does not enable that verification by default.
Certificate checking with -C normally stops before checking the requested page. Add --continue-after-certificate when intentionally combining expiry and content checks.
If an internal service uses a private certificate authority, configure trusted CA material rather than disabling verification. The curl certificate verification guide explains trust stores; the plugin provides --ca-cert for a CA file. Do not assume the standalone curl command and check_curl share option names or defaults.
Migrate check_http and test the failures
Inventory existing definitions and group similar checks. Run replacements as the Nagios service account on the actual monitoring host. Compare status, output, timing, redirects and proxy behaviour before switching notifications.
In a controlled test environment, deliberately try a missing content marker, an unexpected redirect and an untrusted certificate. A green result alone cannot demonstrate that the check catches its intended failure. Move definitions in batches and retain the previous configuration for rollback.
For a quick log review, this existing command remains useful:
grep -Ei 'critical|invalid|warning' logfile.logAlso review retry settings. Nagios uses soft and hard states to distinguish initial failures from confirmed problems. Retries reduce transient alerts but add detection delay; choose that tradeoff deliberately.
Give every alert an owner
For each service, document the business purpose, responder and first investigation step. In agency handovers, make certificate renewal and out-of-hours responsibility explicit.
If inherited checks are difficult to trust, Greg can help review the definitions, plan the migration and clarify ownership. Talk to Greg about your monitoring setup.
Related on GrN.dk
- NGINX 1.30 changed upstream connection reuse: what to check before you upgrade
- AI automations need a spend dashboard before the first runaway bill
- Cloudflare BYOIP customers need a rollback plan, not just trust
Need help with this kind of work?
Talk to Greg about your monitoring setup Get in touch with Greg.
