ICMP Ping Monitor Configuration

This page details every option of the monitoring settings for ICMP Ping Monitors. We do not recommend reading it start to finish - instead, use it as a reference when needed.

For details about alert settings - which are common to all monitor types - check this page.

For information about ICMP Ping Monitors in general, check this page.

Basics

These options are the only ones that must be specified, to configure essential settings.

Monitor name

Default value: (blank)

Use this textbox to give your monitor a name. It is required, and any value up to 50 characters long is valid.

You should choose a name that makes sense to you, as it is shown throughout the console and on any alerts that are sent. The value has no other impact.

Note that this option is only present when creating a new monitor. To edit the name of an existing one, use the Rename panel on the General tab of the settings page.

Host

Default value: (blank)

Here, you should enter the hostname or IP address of the service you wish to monitor.

Enter the host in the textbox using correct formatting as appropriate. Do not include any port.

If the host is an IP address then it must not be in a private range. If it is a domain name then it must be publicly resolvable. localhost is not a valid hostname.

Check schedule

Default value: Interval: 5 minutes

This option determines when or how often the monitor performs checks.

To have your monitor fire on a regular schedule, enter a valid interval using the textbox and dropdown. Any combination is allowed, so long as the equivalent number of seconds is:

• a whole number (e.g. 0.5 minutes is allowed, 0.99 minutes is not)
• no more than 2592000 (30 days, in seconds)
• no less than the minimum allowed by your plan

The monitor will run for the first time as soon as you create it; then at every specified time interval thereafter.

Business and Enterprise accounts can also use crontab scheduling. For this, enter any valid crontab time expression into the textbox. The monitor will run according to this timetable. Crontab expressions are always evaluated against a clock in the UTC timezone, so you may need to adjust the hour portion accordingly.

You must provide exactly one of interval and crontab.

Using an interval of less than 60 seconds will cause the monitor to consume additional monitor credits. See this page for more details.

Parameters

These options alter how many pings to send and how long each one should wait for a response.

Timeout

Default value: 5 seconds

The timeout value controls the maximum length of time each check waits before considering the server as non-responsive (and therefore offline).

You can choose any whole number of seconds between 1 and 10, or leave blank to use the default of 5. The value is the length of time between sending the ping message and receiving a reply.

If the timeout is too short, then there is a risk of false positives. Your server may be online, but a random networking event (congestion) may cause a timeout where it would have succeeded if given a little longer.

If the timeout is too long, then it would increase the delay before alerts are sent. If your server stopped responding, then a monitor with a timeout of 10 seconds and that sends 10 pings would not trigger any alerts for at least 100 seconds.

Count

Default value: 4 pings

This option determines ping many pings should be sent during each check.

You can choose any whole number of pings between 1 and 10, or leave blank to use the default of 4.

Unlike the retries setting of other monitor types, all pings are always sent. The check is considered to have succeeded if any ping response is received.

Additional metrics are calculated and available in the console, including minimum, maximum, and average response times. However, these are purely for your information and form no part of any subsequent logic.

The pings are sent sequentially, meaning that a ping must receive a reply or timeout before the next will be sent.

Triggers

This configuration panel is used to control how the monitor status should be updated after each check.

The check first runs in each region concurrently. All results are then collated centrally, with the monitor's status set according to the triggers set here.

The Down trigger is checked first, then Partial, then Degraded. The monitor's internal status is set to the first trigger whose condition is met. If none of the conditions are met, then it is set to Online.

Down

Default: All regions

The value of this trigger determines under what condition the monitor's internal status should be set to Down, based on the results of a check.

By default, the check must have failed in all regions for it to be considered Down. This is because if any region succeeds, then it would appear that the service is at least partially available, and another status may be more appropriate.

However, you can use the dropdown to adjust this threshold according to your specific circumstances and to better suit your needs.

A check is considered to have failed if none of the pings receive a response.

A monitor accumulates downtime while its internal status is Down or Partial.

If the condition of this trigger is not met then the Partial trigger is considered next.

Partial

Default: 2 or more regions

The value of this trigger determines under what condition the monitor's internal status should be set to Partial, based on the results of a check.

By default, the check must have failed in 2 or more regions for it to be considered Partially down. This is to prevent a potential error in a single region from causing a false positive and sending alerts inappropriately.

However, you can use the dropdown to adjust this threshold according to your specific circumstances and to better suit your needs.

A check is considered to have failed if none of the pings receive a response.

It is not possible for a monitor with only a single region to be in a Partial state, as any value for this trigger would also meet the conditions of the Down trigger in that situation.

A monitor accumulates downtime while its internal status is Down or Partial.

If the condition of this trigger is not met then the Degraded trigger is considered next.

Degraded

Default: 1500 milliseconds

The value of this trigger determines under what condition the monitor's internal status should be set to Degraded, based on the results of a check.

By default, the average response time across all regions must be greater than 1500 milliseconds for it to be considered as having Degraded performance. This is because response times above this value may indicate a significant performance issue.

However, you can use the textbox to adjust this threshold according to your specific circumstances and to better suit your needs.

Response time is calculated as the time between sending a ping and receiving a reply.

If the condition of this trigger is not met then the internal status is set to Online.

Incidents

This configuration panel is used to determine various incident behaviours in response to a change in the monitor's internal status.

As alerts are sent when an incident is opened, it also affects when you will be notified about any potential issues.

Automatically open an incident

Default: True, for Down and Partial

This setting determines if an incident is created automatically when the monitor reaches a certain status.

Alerts (if any, as configured separately) are sent when an incident is opened.

By default, it is set to open if the monitor has an internal status of Down or Partial. This means that alerts will be sent if your service is down, but not if it is simply experiencing performance issues.

While for most users this is likely the right balance between false positives and false negatives, you are free to adjust it to better suit you needs, by selecting the relevant checkboxes. You may also wish to review the relevant trigger thresholds.

If you choose the Disable incident management for this monitor option, an incident will never be automatically opened. As this will effectively prevent any alerts being sent, it is not recommended in most cases. However, it could be useful for monitors that just gather metrics, or when other incident management services are already in place.

Show on public status pages

Default: True

This option determines if automatically-opened incidents are added to public status pages by default.

It is always possible to show incidents (of any type) on public status pages by choosing this option from the incident details page, but by default we can also do this automatically. This allows your users to see the latest details immediately, and may reassure them that the issue is being dealt with.

However, if you wish to have stronger control over your status pages, you may deselect this checkbox. Any future automatically-opened incidents will not appear on status pages until manually added. Existing incidents will still show, until manually removed.

As with all status page messages, an incident will only ever appear on status pages that feature the associated monitor as part of their content.

This setting does not affect internal status pages, which always show all incidents relevant to their contents, to keep staff up-to-date with the latest developments.

This option only applies to incidents opened automatically and thus has no effect if Automatically open an incident is disabled.

Incidents opened manually from the dashboard allow the choice of where they should be shown, during the creation process. Incidents reported by team members are never shown on public status pages until confirmed or acknowledged manually.

Automatically resolve incidents

Default: True

This setting controls how automatically-opened incidents are resolved.

With this option enabled, as is the default, they are automatically resolved as soon as the monitor reaches an internal status of Online.

Only automatically-opened incidents are ever automatically-resolved. It has no effect on those opened manually from the console, or reported by team members.

However, if you would rather ensure that all incidents raised by this monitor are only ever resolvable manually, you can uncheck this option.

Regions

Default: Worldwide

This option allows you to customize which regions your monitor performs checks in.

Using the default value of Worldwide allows us to choose the regions for you. We will always use at least three regions, each on a different continent.

Each check runs across the selected regions in parallel, with the results from each then collated centrally and processed according to the trigger settings.

If your server is only available from certain countries, or you wish greater control for another reason, you can specify exactly which regions should be used.

For example, if you run a server only accessible from Europe, you should not select any region outside this area. Otherwise, when running checks the server will appear offline in those regions and could cause false positives.

Specifying more than 3 regions will cause the monitor to consume additional monitor credits. This does not affect monitors set to Worldwide, regardless of how many regions they run in. See this page for more details.

You may also wish to control monitoring locations to comply with various legal requirements, particularly data localization or data residency regulations. Regardless of region setting, data is stored and processed in (at least) the United Kingdom and European Union.

For more information on data processing, read our data transparency statement or contact our support team. However, be aware that StatusCloud does not and cannot provide legal advice; please contact professional counsel for such queries.