HTTP monitors
Every setting of an HTTP monitor. Method, headers with secrets, body, accepted statuses, timeout and slow threshold, redirects, TLS verification, the keyword check, and the certificate and domain expiry watches.
An HTTP monitor sends a request to a URL on every check and judges what comes back. It is the kind that tracks uptime and response time. A Keyword monitor is an HTTP monitor with the keyword check on; the create page offers it as its own kind so the keyword fields come first.
Request
The Request section says what to send and what counts as up.
| Field | Rules | Dashboard default |
|---|---|---|
| URL | An http:// or https:// URL, at most 2,048 characters. The host must resolve to a public address; some ports are refused (see below). | required |
| Method | GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS. | GET |
| Accepted statuses | Up to 20 rules: a code (301), a class (2xx) or a range (400-404). Any other status is unexpected_status, which counts as down. | 2xx |
| Timeout (ms) | 1,000 to 30,000 ms. The API has no default; the form preselects 10 s. | 10000 |
| Slow after (ms) | Optional. A response slower than this is Slow, a warning, not down. Must be below the timeout. In the form 0 turns it off; in the API, leave the field out. | off |
| Follow redirects | On or off. When on, At most n redirects, 0 to 10; more is too_many_redirects, which counts as down. | on, 5 |
| Verify the TLS certificate | On or off. Off accepts any certificate; the certificate is still reported, and a watch still judges its expiry. | on |
| Body and Content type | The form offers them for methods other than GET, HEAD and OPTIONS; the API refuses a body on GET and HEAD. The body is at most 64 KiB. | empty |
Checks identify themselves with the user agent
NorcubeMonitor/1.0 (+https://norcube.com/monitor/) and come from the
source IP 18.185.27.174.
What the dashboard refuses
- Hosts that don't resolve to a public address (private, loopback and other special-purpose ranges), and literal private IPs. A name that resolves to a private address fails the same way as one that doesn't resolve at all, so monitors can't be used to map internal names.
- Ports used by mail (25, 465, 587), remote shells (22, 23, 3389), caches (6379, 11211), databases (3306, 5432, 9200, 27017) and Docker (2375, 2376). Every other port works.
Headers
Add up to 20 request headers under Headers (Add header). Names are at most 128 characters, values at most 4,096. Tick Secret for a value that must not be stored in plain text:
- A secret value is encrypted at rest and never returned by the API or shown in the dashboard again. The edit form shows "Stored. Type a new value to replace it."; leaving it blank keeps the stored value.
- Secret headers are only ever sent to the URL's own origin. They are not sent on a redirect to another origin, and after you change the URL to another origin you have to enter them again.
- Cloning a monitor does not copy secret values.
- A secret that can no longer be decrypted makes the check fail with
config_error("Can't check"). Enter the header again to fix it.
Headers the transport owns can't be set: Host, Content-Length,
Transfer-Encoding, Connection, Keep-Alive, Proxy-Connection,
Proxy-Authorization, Te, Trailer and Upgrade.
Keyword
The Keyword section looks for text in the response body:
- Keyword: up to 512 characters.
- Up when it is: Present (the keyword must be in the body) or Absent (the body must not contain it, useful for error banners).
- Case-sensitive: off by default.
The keyword is looked for in the first 256 KiB of the body after
decompression. A keyword further down counts as missing. A monitor
without a keyword never reads the body at all. A failed keyword check is
keyword_missing or keyword_present and counts as down. Lists show a
monitor with a keyword as Keyword.
Conditions
Every check ends with one condition. For an HTTP monitor:
| Condition | Severity | Word |
|---|---|---|
ok | ok | Up |
slow_response | warning | Slow |
timeout, dns, connect, tls, unexpected_status, keyword_missing, keyword_present, too_many_redirects, blocked_destination, cert_expired, cert_invalid, cert_hostname, cert_not_yet_valid | critical (downtime) | Down |
config_error | critical | Can't check |
internal | inconclusive | Unknown |
With Verify the TLS certificate on, a certificate the handshake refuses is judged from what the server presented: expired, not yet valid, wrong hostname or untrusted chain. The request is not sent, the certificate is kept in the result, and the monitor is down.
Expiry watches
Under Expiry watches an HTTP monitor can watch two more things. Each watch is an aspect of its own: it has its own status and its own incidents, and it never changes whether the site is up, its uptime or its response times. It does move the monitor's overall status, which the list's counts, filter and sort read.
| Watch | Applies to | How it is checked |
|---|---|---|
| Watch the certificate | https:// URLs | The certificate every check sees is judged for expiry only, with Verify the TLS certificate on or off. Trust and hostname problems stay availability conditions. |
| Watch the domain registration | Hosts with a registrable domain (not an IP address, not a public suffix) | The URL's registrable domain (shop.example.co.uk watches example.co.uk) is looked up every 12 hours through DomainRadar, the way a domain monitor does it. |
Each watch has its own Warn before expiry (days) thresholds: 1 to 5
values of 1 to 365 days, 30, 14, 7 by default. The create form turns
both watches on for https:// URLs. A watch that doesn't apply to the
URL is shown off and not sent.
What a watch does:
- Within a threshold: a warning incident opens at once and an
expiringalert goes out. Each lower threshold crossed alerts again. - Expired, not registered: a critical incident and an
expiredalert. An expired domain always alerts; an expired certificate alerts from the watch only while the availability incident doesn't already page for it (an expired certificate the request is refused for is already Down). - Renewed: the watch's incident resolves with a
recoveredalert, and the renewal is listed in the monitor's history. - Turning a watch off, or changing the URL's host or domain, ends the watch's open incident. Changing its thresholds ends nothing.
The Expiry watches card on the monitor page shows each watch's days left, a small timeline with the thresholds, the host or domain, the thresholds, which alerts were already sent for the current expiry and when it was last checked. Domain lookups made for watches are not billed.
Create one from the CLI
nrc monitor monitors create "Shop" --type http --url https://shop.example.com/health
nrc monitor monitors create "Login page" --type keyword --url https://example.com/login --keyword "Sign in"
printf 'Authorization: Bearer %s\n' "$TOKEN" | nrc monitor monitors create "Admin API" \
--type http --url https://example.com/admin/health --secret-headers-file -Every flag is in the CLI reference.
Monitors
The kinds of monitors, intervals and statuses, the monitor list with filters and bulk actions, and the detail page with uptime, response times, history and CSV export.
SSL certificate monitors
A TLS handshake to a host and port on every check. Chain, hostname and validity are verified, expiry alerts fire at your thresholds, and the certificate's details and renewals are kept.