Website monitor
Check that a web page answers, quickly, with the right content.
What it checks
Uptiva requests the URL (a GET request) from the regions you choose. The monitor is up when the response status is inside your range and every rule passes. Redirects are not followed.
When to use it
For a site, a landing page, a login page or any URL that should load. To send another method, headers or a body, use the API monitor.
Create it
- Open /app and click New monitor.
- Under What to monitor choose Website.
- Under Details enter a Name and the URL, the full address, for example
https://example.com. - Optional: under Rules set the status range, a slow limit and content checks (below).
- Under Schedule pick Check every and, if you want, Alert after (failed checks in a row before an alert).
- Under Check from choose the regions that run the check.
- Under Alerts choose where alerts go (Send alerts to). See Alerts.
- Click Create monitor. The first check runs right away.
Check interval
Under Schedule, Check every offers 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 hour and 1 day. The shortest is 1 minute (on the Free plan 5 minutes). Intervals your plan does not allow are greyed out.
Rules: what counts as up
These are in the Rules card. A monitor is down unless the response passes every rule.
| Setting | How it works |
|---|---|
| Up when the status code is between | Two numbers, from 100 to 599. The default is 200 to 399. Redirects are not followed, so a 301 or 302 must be inside the range to count as up. |
| Degraded when slower than (ms, optional) | 50 to 120000 ms. A healthy but slow answer shows as Degraded, not down. |
| Page must contain (optional) | Text that must appear in the response body, up to 200 characters. Upper and lower case count as different. |
| Page must not contain (optional) | The monitor is down when this text appears, for example Fatal error. Case sensitive. |
| JSON checks (optional) | Up to 5 checks on fields of a JSON response. See below. |
| Response header checks (optional) | Up to 5 checks on response headers. See below. |
JSON checks
Each check has a path, an operator and a value. Write the path with dots and brackets, for example data.status or items[0].ok. The response must be JSON; if it is not, the monitor is down. Values are compared as text.
| Operator | Passes when |
|---|---|
| equals | the field is exactly the value, for example status equals ok |
| does not equal | the field is missing or different |
| contains | a text field includes the value, or a list has an item equal to it |
| is greater than / is less than | the field is a number above or below the value (the value must be a number) |
| exists | the field is present and not null (no value needed) |
Examples: status equals ok, data.items[0].price is greater than 0, error exists (use does not equal or the rule below to fail on it).
Response header checks
Each check has a header name (letters, digits and dashes, up to 60), an operator and, for most operators, a value (up to 200 characters). Names and values ignore upper and lower case.
| Operator | Passes when |
|---|---|
| exists | the header is present |
| does not exist | the header is absent |
| equals / does not equal | the header value is / is not exactly the value |
| contains / does not contain | the header value includes / does not include the text |
| starts with | the header value begins with the text |
content-type contains application/json
strict-transport-security exists
x-powered-by does not exist
cache-control starts with no-storePlan. Content, JSON and header rules are the plan feature Keyword and JSON rules. It is on in the standard plans. If your plan does not include it, saving a monitor with these rules is refused with a message that says so.
Advanced
- Timeout (seconds), 1 to 60. Retries on failure, 0 to 3.
- Ignore TLS certificate errors for self-signed sites. Use an SSL certificate monitor to watch the certificate itself.
- Headers (one per line,
Name: value) and Basic auth user and password. Sensitive values such as Authorization are shown as********after saving and kept unless you type a new value.
What the monitor page shows
Status, uptime and a response time chart, plus a Details card from the latest check of each region:
- Response: status code, final URL (the Location of a redirect), server, content type, content encoding, response size, powered by, Cache-Control and whether HSTS is set. If the request failed: where it failed and the error.
- Timing breakdown: DNS lookup, TCP connect, TLS handshake, time to first byte and download, in milliseconds.
Alerts
You are alerted when the monitor goes down and when it recovers, through the channels you pick. Alert after sets how many failed checks in a row are needed (1 to 5). Quiet hours, reminders and escalation work as described in Alerts.
Common problems
- Down on a redirect. Redirects are not followed. With the default range (200 to 399) a 301 or 302 counts as up. If you narrowed the range, widen it or use the final URL.
- Down on a keyword that is on the page. Matching is case sensitive. Check the exact text, and that it is in the HTML the server sends (not added later by scripts).
- Down only from one region. Switch the Details card between regions to compare the error.
- Timeouts. Raise Timeout or use Retries on failure for slow servers.