This article will provide definitions for each field of an uptime check. Because each check is unique, some fields may appear as optional or required depending on the type of check.
The following describes the fields provided when adding or editing a check:
Provide a name for your check. Useful for quick searching or grouping your checks alphabetically.
Select the interval between each check. We will run the check from every location you’ve selected at the rate specified here. If a check fails, we will then run two additional retries at one-minute intervals to verify the failure before recording the location as “down”. If the check is a Transaction or API check, and the check fails, we will then run two additional retries at two-minute intervals to verify the failure before recording the location as “down”.
Select the contact group(s) for your check. The contacts you assign to a check will be notified of any incidents related to your checks via email, SMS message, phone call, and/or any of our integrations.
Select the probe server locations which will be used in monitoring your checks. At each interval defined by your Check Interval, we will run the check from every location you select here. Note we highly recommend selecting at least 3 locations to prevent false positives due to a location-specific anomaly.
Select your check type. Please refer to Overview of Checks for more information on the types of checks Uptime.com can run.
These parameters are required or optional fields based on the check type selected.
Required Parameter Screenshot Example (from the HTTPs Check)
Optional Parameters Screenshot Example (from the HTTPs Check)
The URL or IP you wish to check (example: https://google.com or 10.0.0.123).
The username required for authentication, for example Basic Auth for HTTP or email credentials for SMTP. Note: We highly recommend that you create unprivileged test credentials for your checks.
The password required for authentication, for example Basic Auth for HTTP or email credentials for SMTP. Note: We highly recommend that you create unprivileged test credentials for your checks.
String to POST/Send
Data to send to the server your are checking. For example, URL-encoded HTTP POST data for HTTP checks, or raw data for TCP/UDP checks. Be sure to format data in a way the server will understand.
String to Expect
Data that must be present in the server’s response, otherwise the check will fail. Different check types return different types of data; for example, for HTTP checks this is any text present in the returned HTML. For TCP/UDP checks this is the raw data returned by the server. For DNS/WHOIS checks it ensures your records have not been maliciously tampered with.
How to match the String to Expect, relevant for HTTP checks only. “Exact match” means the text must be present exactly in the returned HTML. “Regular expression” supports matching by patterns. “Fail if regular expression matches” means the check is successful only if the pattern is not matched.
HTTP headers to send, one per line, in regular HTTP format (eg Content-Type: application/json). You may set the Content Type, Cookies and other HTTP headers using this field. Please note the user-agent is not settable to prevent abuse or masquerading.
Max Load Time (RUM Check Only)
Raise an alert if your site’s average response time (in seconds) is more than this value.
Available for many check types, specifies the port number you would like to use. The default is sensible - 80 for HTTP, 22 for SSH etc.
Record Type (DNS Check Only)
Specifies the type of DNS record (eg. A, AAAA, TXT) you would like to test for.
DNS Server (DNS Check Only)
Address of the DNS nameserver which should be used to query for DNS records (example: ns1.registrar.com or 18.104.22.168).
Where relevant, use STARTTLS to check over a secure connection.
Before Expiry (Whois and SSL Checks only)
Raise an alert if there are less than this many days before the domain or SSL certificate needs to be renewed.
These tools are useful but may not apply to every potential check. Some are also situational, and dependent on the needs of your organization.
How many locations should be down before an alert is sent. With a minimum of three locations, we highly recommend the default value of “2”. This provides the best balance between alert speed & accuracy. Note that setting a value of 1 location will likely result in false positives as anomalies in individual locations do occur from time to time.
Use IP Version
Whether IPv4 or IPv6, or any available address should be used for connection. By default, all checks will go over IPv4 with ANY set, apart from the Transaction and API check, unless IPv4 is specifically selected.
Raise an alert if the check takes longer than this many seconds to complete. Timeout errors can signal anything from a firewall issue, a high volume of users, a temporary outage or slow connection, so use of this feature provides more context for certain outages.
Include in Metrics
Include this check in uptime/response time calculations for the dashboard and public status pages.
Escalations let you notify additional contacts if a check stays down for a longer period of time (from one minute up to several days). You have a wide range of options for escalating an outage. Designated contacts for escalation will receive notifications with relevant technical data about the downtime after the time interval specified.
During maintenance, failed checks will be ignored in uptime calculations and alerts are logged but not sent. In the alert listings you will be able to see any alerts detected during maintenance as faded out, indicating they are ignored.
- No maintenance window
- Apply a maintenance tag immediately (alerts will be suppressed until you change this setting)
- Schedule maintenance. When scheduling, alerts will be suppressed based on a predefined schedule. You will need to define the timezone, day(s) of the week and the time range (using a 24-hour clock).