In Uptrends, there are two ways of monitoring the uptime, performance and correct behavior of your websites, web services and servers: Standard monitoring and Concurrent monitoring.
A monitor check is done from one checkpoint. If an error occurs, this is regarded an unconfirmed error. Directly afterwards, the same monitor check is done from a different checkpoint. If the same error is received again, the result is a confirmed error. Only confirmed errors can lead to alerts and messages (SMS, email, Slack, other third-party systems).
A number of monitor checks are done at the same time (concurrently) instead of one after another. You define how many checks are done concurrently and from which checkpoints.
There are also two limits which are a percentage of the checkpoints returning an error: one limit for when an error is regarded an unconfirmed error and another limit for when an error is regarded a confirmed error. It’s up to you to decide which percentage is enough to signal an error. If the first level (for example 30%) is reached, the error is classified as an unconfirmed error. If the second level is reached (for example 60%), you’ll see a confirmed error instead.
When a significant (as defined by the user) percentage of checks has returned an error, the result immediately is a confirmed error. An alert can be generated and a notification can be sent quickly.
Concurrent monitoring works within the following scope:
- It is available for all monitor types.
- The monitor checks must be at usual monitoring frequencies, which are 1 minute for basic monitors and 5 to 15 minutes for browser monitors.
- For concurrent monitoring, special rules apply for selecting checkpoints: either choose from all checkpoints (at least 5), or choose from checkpoints marked as high availability (at least 3). High availability checkpoints are generally those locations with more than one server available.
- In all cases, the maximum number of selected checkpoints is 50.
Based on concurrent checks, Uptrends computes one overall measurement (with basic metrics). The data can be used like with other monitors, e.g. in dashboards, alerts or SLA calculations.
The individual measurements will be available:
- In the Monitor log
- When opening the overall measurement from the Monitor log, you get a details popup which points to the partial measurements
- Per individual measurement, we will record the usual debug information (screenshots, waterfall, traceroute etc.)
Advantages and disadvantages
The advantages are that Concurrent monitoring detects an error faster and has higher reliability. Note that the latter depends on the number of checkpoints used.
A disadvantage could be that we do not aggregate transaction steps or calculate an average of the waterfall for reporting purposes (for transactions, full page checks, etc).
The Concurrent monitoring comes at a higher price. However, you’ll get faster detection and higher reliability in return. Please see the examples below to get an idea about the pricing.
The feature will be included in the following pricing plans: Business and Enterprise.
In order to use Concurrent monitoring, you have to individually choose the checkpoints that will be included in the checks. This is possible in the Business and Enterprise pricing plan. Other plans do not offer this option and therefore are not suitable for Concurrent monitoring.
The price is calculated following the credit system, where different types of monitors have different base prices, expressed in credits. So in general the calculation is:
Price = the base Monitor price x the number of Checkpoints included in the check
In the following table you find two examples of how the pricing works, compared between concurrent and standard monitoring.
|Concurrent monitoring||Standard monitoring|
|Transaction (cost of 4 credits), user-defined to run on 3 Checkpoints|
4 credits x 3 = 12 credits
|Transaction (cost of 4 credits)|
4 credits x 1 = 4 credits
|Uptime (HTTPS) Monitor (cost of 1 credit), user-defined to run on 20 Checkpoints|
1 credit x 20 = 20 credits
|Uptime (HTTPS) monitor (cost of 1 credit)|
1 credit x 1 = 1 credit
In general you should keep in mind that a Monitor type with a high base price (credits per Monitor) will lead to high credit use, when including many checkpoints.