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. We recommend using your browser's search function to identify specific fields within this guide for additional information, but we've also included a table of contents below to help browse these explanations:
Table of Contents
- URL/Domain IP
- String to POST/Send
- String to Expect
- String Comparison
- HTTP Headers
- Max Load Time
- Record Type
- DNS Server
- Before Expiry
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.
Set or alter 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 run additional retries based on the number of retries you've configured 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 the additional retries at two-minute intervals to verify the failure before recording the location as "down".
Editing check intervals can be done in bulk.
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.
Assigning contacts can be done in bulk.
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.
Editing probe server locations can be done in bulk.
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.
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.
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.
Specifies the type of DNS record (eg. A, AAAA, TXT) you would like to test for.
Address of the DNS nameserver which should be used to query for DNS records (example: ns1.registrar.com or 126.96.36.199).
Where relevant, use STARTTLS to check over a secure connection.
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 dependent on the needs of your organization.
Sensitivity designates how many locations can register as down before an alert is sent. We highly recommend a minimum of three locations with the recommend the default value of “2”. 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.
Configuring the Number of Retry Attempts
The number of retry attempts determine how many times a check should be re-run before a location is considered down. The default setting is 2, but Uptime.com allows users to choose from 1-3 attempts. We recommend using 2 retries for fast alerting that avoids false positives.
Please note: The retry intervals for API and Transaction checks are two minutes, as opposed to one minute for other checks.
Setting retry attempts and sensitivity can be done in bulk.
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 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.
See our article on creating smart escalations to see this in action.
Escalations can be configured in bulk.
During Maintenance, failed checks will be ignored in uptime calculations and alerts are logged but not issued to check contacts. 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).
It is possible to set maintenance windows in bulk.
Uptime.com allows users to make certain updates to multiple checks simultaneously. Bulk check updates help save time and remove the odds of human error when making changes to many checks.
Click Monitoring>Checks to view the checks you’ve created. You can either tick the box next to the checks you wish to change:
Or select all checks visible on the page when you tick the box next to Name:
Once you’ve selected checks to update, click More and select from the following options:
- Set Check Intervals
- Set Locations
- Set Contacts
- Set Retries and Sensitivity
- Set Escalations - See our article on creating smart escalations to see this in action.
- Set Maintenance Windows
- Set Tags
- Delete Checks