Uptime.com monitors your infrastructure for failure, notifying you the moment something goes down. Some use cases require more refined conditions under which an alert is issued. Advanced Options provide additional options that control when a check issues an alert, and other technical details.

When a check fails, IT personnel could waste effort researching false positives that didn’t signify a real problem. Uptime.com’s Advanced Check Options provide a number of methods to reduce the likelihood of receiving alerts for failed checks that aren’t problematic and better controlling the conditions under which a check functions.

Table of Contents

• Advanced Check Options At A Glance
• Sensitivity, Retries, and Timeout
  • Sensitivity
  • Retries
  • Timeout
• IP Version
• Setting Target SLA% & Response Time SLA
• Checker Version
• Escalations
• Maintenance
  • Maintenance Windows
  • Pausing Checks
  • Setting One-Off Maintenance
  • Maintenance and Group Checks
• Ignoring Alerts

Advanced Check Options At A Glance

• Adjust the sensitivity, number of retries, and timeout to avoid false positives

• Create escalations to ensure the right parties are notified when downtime exceeds a set duration.

• Set Maintenance schedules to ensure your downtime percentage is not affected by known occurrences.

Setting Check Conditions

Once you have created a check, there are several options under Advanced, Escalation, and Maintenance that control when and how a check alert is issued. Let’s begin with the Advanced tab, which is used to set your Sensitivity and IP Version.

Advanced

Sensitivity, Retries, and Timeout

Return

Sensitivity

Sensitivity is the number of Locations that can fail before a check is considered failed. We recommend that every user monitor from at least three Locations, then set the Sensitivity to a value that matches or accounts for the majority of those Locations. This way, Uptime.com provides the best balance between alert speed & accuracy, while avoiding the false positives that low sensitivity could create.

Note: You can select up to 15 locations.

Some examples:

When using fewer than 3 locations, a check will return to UP status once all locations have returned to UP status. 

When using 3 or more locations, adjust sensitivity to be 3 or higher. The check will return to UP status once all but one location has returned to UP status. 

If a single location should fail, and remain DOWN for 3 days, a warning will be sent to the contacts configured for the check. This will not register as downtime for the check, or place the check in DOWN status. We recommend reviewing single failed locations that have remained DOWN for 72 hours and resolving them to prevent downtime should another single location fail.

Retries

The number of retry attempts determines 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.

 

Timeout

Users can also designate a Timeout, measured in seconds and limited to a maximum value of 60, to further control when and how alerts are issued. A timeout error typically signifies a problem with the connection to a specific function of a website. There may be too many users attempting to access a single resource, or a localized outage affecting connection time. Use of the Timeout (available only for HTTPS, API and Transaction checks) provides the first indication, with technical data, that there is a problem connecting to your website that requires investigation.

Please note: Timeout is not available for Real User Monitoring, Group Checks, Malware/Virus, SSL Certificate, WHOIS/Domain Expiry, Ping ICMP, SSH, TCP/UDP, POP/IMAP/SMTP, and Blacklist checks. Global check timeout is limited to the total run-time of a check.

 

IP Version

Return

All checks (except for Group checks, API, and Transaction checks) default to IPv4 for connections unless IPv6 is specified. IPv6 is gaining in popularity as more routers and consumer devices utilize the addressing scheme. In specific instances, such as monitoring uptime to an interconnected device or a specific usage of API, it’s important to utilize an IPv6 address. To use any available address, leave this option on Any.

 

Setting Target SLA% & Response Time SLA

 

Target SLA%

Target Uptime SLA % indicates the minimum SLA% your check needs to meet for SLA accountability. Our default Target SLA% value is 99.00 for all check types. 

 

Response Time SLA

Response Time SLA indicates the minimum average response time (in seconds) your check needs to meet to uphold your SLA accountability. Our default Response Time SLA is dependent upon which check type is selected.

Updates to Uptime SLA% and Response Time SLA can be done in bulk. 

 

Checker Version (Http(s) Check Only)

There are two HTTP(S) Checker Versions available for use. Newly created HTTP(S) checks will default to the latest version.

Please Note: The HTTP(S) check will default to the newest version. If HTTP is specified in the provided URL, the checker will not verify certificates.

V1.0 Legacy Version

The legacy HTTP(S) checker does not support certificate verification.

V2.0 Curl Version

Version 2.0 is based on curl with support for SSL and TLS certificate verification. V2.0 also supports newer technologies such as HTTP/2, SSL v 3, and chunked content.

 

Escalations

Return

Escalations allow users to receive a notification that a check has stayed down longer than a designated period of time (from one minute up to several hours). You can choose the Escalations tab from the check screen to designate the amount of time that must pass and who will be notified. You can escalate any check with a wide range of options available as to how your escalation will work.

Escalations you create will notify your selected contacts at your designated intervals. For example, in the following screenshot, the designated contacts will be notified within 5, 20, 15, or 20 minutes once downtime occurs, depending on the contact’s configuration.. Additionally, you can define the number of Repeat Times, which determines how many times the contact is notified of downtime, up to a maximum of 50 repeats. It is important to note that an escalation only applies to downtime that occurs after the escalation was created.

See our article on creating smart escalations to see this in action.

Escalations can also be configured in bulk. by clicking the check boxes next to the desired checks to be edited, clicking the bulk Options menu, then clicking the Set Escalations button

 

Maintenance

Return

During Maintenance, failed checks will be ignored in uptime calculations and alerts are logged but not issued to check contacts. This includes checks with escalations. 

Here is an example of a check in maintenance state:

 

In the alert history, you will be able to see any alerts detected during maintenance as faded out, indicating they are ignored:

When a check is in Maintenance state, Uptime.com will stop issuing alerts for the check until you re-enable it. During this period, Uptime.com will not log data for response or downtime. Statistics will not show any change of status during the time paused.

Once the maintenance window has ended, the check will issue an alert (and corresponding escalations) if it still reports as down. 

Maintenance is the preferred alternative to pausing a check because maintenance only ignores alerts for the specified period, and maintenance windows require less human input to return the check to a normal state. Maintenance can be set to:

• No Maintenance Window when no maintenance has occurred (This is the default setting)
• Under Maintenance Now, where all failed checks are ignored until the feature is returned to No Maintenance Window
• Use a Maintenance Schedule where you can Set a Maintenance Window.

Set a Maintenance Window

Return

First, click the Maintenance tab from your Check screen. Click the option to Use Maintenance Schedule and then designate your maintenance window. You can schedule maintenance windows for weekly and/or monthly recurrence and will need the following:

• Day or days of the week maintenance will be performed
• Single day or date range for the month maintenance will be performed
• Block of time (determined by Start and End time in HH:MM format for your Timezone) indicating number of hours needed to perform maintenance

 

Pausing Checks

Return

Stop check execution during maintenance mode: when this option is checked while creating the maintenance schedule, checks will not be paused for the duration of the schedule. This may be useful in cases where URLs should not be hit by our probe servers during maintenance to avoid undesirable effects on infrastructure.

To find the setting, you will need to select the Use maintenance schedule option.

This setting can also be found within our REST API endpoints below:

•  /api/v1/checks/{pk}/maintenance/
• /api/v1/checks/bulk/maintenance/

Please note: To have this feature added, please contact support@uptime.com

Please note: all maintenance windows are set based on your account's preferred timezone. It is possible to use the Uptime.com REST API to set maintenance windows. It is also possible to set maintenance windows in bulk.

 

Setting One-Off Maintenance

Return

Use the One-Off Schedule option to configure any maintenance window(s) that should occur on a planned date without conforming to any existing weekly or monthly schedule(s). Click +Add a Schedule, then choose a Start Date/Time and End Date/Time:

Maintenance and Group Checks

Return

A Group Check nests individual checks, and maintenance windows apply differently to this check type. If an individual check is in maintenance state, that check’s UP or DOWN state counts toward the fail conditions for your Group Check. 

A Group Check in this sense can be considered like an individual check. If the checks within a group check should not count against the group check’s downtime, it is advised to set the group check and the individual checks to the same maintenance schedule.

Ignoring Alerts

Return

Occasionally, it's important to ignore an alert that was a false flag or caused by some action in-house that maintenance windows did not account for. You can manually ignore the alert, which has several important implications.

Ignored alerts:

• Are logged in Alert history, but not in the Alert log of reports
• Do not factor into uptime calculations or reports
• May not appear in the Latest Alerts for custom dashboards dependent on settings
• Downtime resulting from ignored alerts will remain visible on check cards in your dashboard. 
• Do not change the state of a check (A down check will remain down even if alerts are ignored)

Navigate to Reports > Alerts, then click the Actions menu next to the alert. Click Ignore this Alert to manually ignore the alert, which fades the colored status indicator on all screens the alert is depicted on.

 

Note that a check that is experiencing downtime with an ignored alert will display DOWN on the internal Check Report page, as seen here:

This has been changed to match all other public areas of the Uptime.com platform (for example public shared reports and public Status Pages). In all areas, a check with an ignored alert will still display as DOWN until the check returns to UP status.

This is in contrast to previous behavior, in which a DOWN check with an ignored alert would display as UP in the internal Check Report as soon as the alert was ignored, as seen here:

 

Here is a quick reference as to how this behavior has changed in different viewable areas when a check is experiencing downtime but the alert has been ignored.