Open the target Device in the list to Edit. In the browser's address bar you'll see something like:
https://user.dotcom-monitor.com/ClientID/DeviceEdit?pid=dc7f4ff2ca944dekjh1078b96707002& deviceId=63698 & taskId=132834
The deviceId=63698 is the device ID.
The taskId=132834 is the task ID.
An Account ID provided on the Select an Account starting page in the list of available accounts.
Once you logged in, find your account ID upon pointing at the Account menu on the left sidebar.
Once logged in into a master account you can find your Department IDs under Account > Account Settings > Departments.
Each test in LoadView has a unique ID. Using the test ID you can call a specific scenario while configuring LoadView integration (e.g., for Jenkins or CircleCl builds).
The Test ID can be found on the test page.
The approach provides the ability to carefully define how Dotcom-Monitor interprets responses as either “Up” or “Down” responses. This is accomplished using filters.
Incidentally, a filter can also both be applied to a device (cutting false triggering) and to any type of reporting.
Filtering defines the Up/Down states using the following adjustable criteria:
All filters and their settings are available at Configure > Filters. After a filter is applied to a device all of the device’s notifications are based on the filter’s criteria. “Default Filter” is assigned to all new devices. The default filter has a balanced configuration and is suitable for most monitoring devices.
The formula for the Downtime calculation is as follows:
1. Downtime Duration is tied directly to the configurations within the filter:
2. Duration of “Undefined” state. An Undefined state can be set when the status of each agent involved in monitoring becomes Undefined. An agent status is considered as Undefined if the agent does NOT provide any response (error or success) in a certain amount of time:
Response Wait Time Duration = (the overall agents number+1) × monitoring frequency + 15 min
For example, we use three monitoring agents and a monitoring frequency of 5 minutes. Each agent will wait for a response for Response Wait Time Duration = (3+1)×5+15 min = 35 min. Once the time expired and no response received, an agent reports Undefined.
3. Duration of “Postponed” state. Postponing a device at any moment will stop any monitoring activity until it is re-enabled.
4. Duration Excluded by Schedule. Another entity that can significantly affect Uptime/Downtime calculations is Schedules. This is an option for managing your monitoring during routine maintenance. Monitoring can be postponed for specific days of the week as well as specific hours and minutes during a day. To set up a schedule, follow the instruction.
Any change in a device settings (including device restart) during the Down state will reset the state so no uptime alert will be sent.
EXAMPLE:
Let’s say we have device monitored from 7 locations and filter set that 3 locations must report an error for Downtime condition. First, monitoring node (agent 1) detects an error while the rest are still reporting success, then the second (agent 2) and at last third one (agent 4) detects an error at T4 which triggers filter to set Downtime beginning right from this moment. The Down state will remain until you set hypothetical Postpone at T5 because of the number of agent reporting errors higher than adjusted 3 throughout all this time. The time gap between T6 and T7 is an illustration of the fact we get the first response with a delay (monitoring session processing time includes network transfer delays and the execution itself), so “Postponed” time is being calculated as ∆ (T7–T5) (Postponed 2nd). Again, we fall into Downtime only on 3rd error from Agent 3 and get in the Up state only on the T9 response, when the number of failing agents becomes less than adjusted in the filter. Here comes the final downtime % calculation formula for this case:
LoadView uses Load Injector Servers from Amazon Web Services (AWS) and Azure Cloud Services. Dotcom-Monitor has 17 geographical regions Load Injector Servers can be stated and the load can be generated from. In each region, about 500 Load Injectors can be instantiated.
Capacity limits depend on the monitoring platform type due to the difference in test execution algorithms:
The limit for a particular Load Test type is calculated using the following formula:
500 x 16 x Number of Concurrent Users per Load Injector = Maximum User Load
Find the resulting Load Capacity Limits below:
| HTTP(S) Load Test (ServerView) | Web page Load Test (BrowserView) | Web Application Load Test (UserView) |
| 8,000,000 users | 225,000 users | 225,000 users |
The “Shanghai” (China) monitoring agent, is located behind the Great Firewall of China, which is administered directly by the Chinese government. The Chinese government has a filtering rule in place for all Internet traffic and it is not public. These filtering rules are modified frequently, which, in turn, affects monitoring results from the Shanghai, China Agent.
https://youtu.be/4py8zE5EtFc?si=LnpflrvFK1ESWYWQ
You can edit the monitoring agent locations for multiple devices at once on the Device Manager screen.
In short, UserView and BrowserView Platforms' tasks load a web page in a real browser and execute all page components, while HTTP(S) Task uses emulated "synthetic" browser and only downloads page element that was requested without rendering.
For more more details, see Differences between Monitoring via HTTP(S) and via BrowserView/UserView and Differences in Time Measurement Between HTTP(S) and BrowserView/UserView Tasks.
By default, exchange servers recognize if an email address is local. If this is the case, the server does not send the email across the public internet. This is a default of most email servers.
If you wish to test sending and receiving across the public internet we recommend using our round trip email monitor + a 3rd party email account such as Gmail.
Our Round trip email monitoring requires the use of POP3 or IMAP protocols either at your location or at the 3rd party (gmail).
There are three ways to test this with Round trip:
ActiveSync protocol also performs a round trip. Active sync DOES test the ability to send an email from a remote device (our monitoring locations) and to retrieve an email from the server by that remote device. But it does not send the email from one active sync server to another because the sending and receiving account are the same account on the same server, so it finds the shortest route to a local address does not require sending the message to the public internet until the message is retrieved from a remote device (our monitoring locations).
Here is the difference between Round Trip and ActiveSync- you can see email move across multiple servers using a 3rd party email provider such as gmail, while the email resides on 1 server using activesync:
The API is locked down by an IP address to only allow authorized users access. Upon configuring a Web API Integration (Manage > Integrations > New Integration), you must enable access to data beyond your Dotcom-Monitor account via the Web API. Please visit How to Whitelist IPs for Web API Access for details.
For more information on how to use the API, visit the API getting started page.
After you set up tasks with alerts and they begin running, you may find yourself receiving multiple alerts, yet when you check the service or website, everything looks fine. It is important to pay attention to the contents of the alerts in order to figure out what is causing the error. Some errors may contain custom Dotcom-Monitor error codes, while others may contain http status codes that can help you decipher the cause of the error.
Due to the detailed nature of the Dotcom-Monitor monitoring capabilities, you may want to tweak your alerts, reports, or your recorded scripts to exclude certain elements or errors to eliminate false positives. Some of those reasons include:
You can adjust for these false positives by creating Filters and applying the filter to the alerts and reports of the offending device.
You can also enable the False Positive Check on your devices. This will trigger a cascade of checks from a location that discovers a monitoring failure in order to confirm that the device is erroring more than once
The easiest way to create a large number of objects items (devices / tasks / filters / schedules / etc..) in the Dotcom-Monitor system is to open a support ticket and ask the support team for assistance.
Please be prepared to provide a spreadsheet with a list of all the objects that you want to be created. If required, the spreadsheet should be attached to the support ticket, so the support can make the necessary changes for you.
Once you have created a dashboard, you can view it at any time by copying and pasting the url into a new browser window. You do not have to be logged in to the system in order to view a dashboard.
To find the URL of the dashboard,
Now you can save the URL to a file, email the URL to others, or paste it into a browser window and bookmark the address to easily access it in the future.
You can silence individual device alerts for up to 24 hours from the Device Manager by clicking actions next to the device, selecting Alert Silence, and silencing for the desired period.
To silence multiple devices at once, click the checkbox next to each device you wish to silence, and then click the Alert Silence button at the top of the list, and select the period you wish.
You can also use the API to silence alerts for more than 24 hr. For information on how to do this, checkout API: Disable Alerts for a Device.
Dotcom-Monitor systems offer a robust set of monitoring tools that should be carefully adjusted to detect the level of performance required for each monitored target. Due to the number and variety of alerting factors, you may need to tweak some of the settings on your monitors in order to eliminate false positives.
To determine if the alerts you are receiving are valid, check out this article on identifying false positives.
If you still do not wish to receive alerts the way they are currently configured, running an online report from the Device Manager for the time during which you received the alerts will give you more insight into what is triggering the alerts.
If the error on the online report states "(300) task Maximum timeout expired" this means that the task took longer to complete than the maximum timeout specified for the task. This may point to a legitimate issue, but it is up to you to determine at what point you need to receive alerts. If you feel that you are receiving too many alerts, you can edit the task and increase the max timeout limit.
If you are monitoring from multiple locations, but are only experiencing issues from a single location, there are several things you can check.
If your server access is limited via IP address, you should make sure that you have added the ip addresses of all monitoring locations to your IP address access list.
If your server requires a certificate to access content, you must open a support ticket to upload the certificate to each monitoring location.
If you are experiencing issues from a location in China, you may be seeing the results of the "Great Firewall of China." As the Chinese government maintains tight control over what content is accessible from within the country, sometimes content is filtered out as inaccessible or bandwidth to certain sites are throttled so that elements from the site time out. In these cases there is often little you can do since the Chinese government is in control of the network.
If you are experiencing issues from one or a few specific locations, you can open up a support ticket and our support team will work with you to identify other possible issues. Sometimes there may be issues with a DNS server routing incorrectly, reverse DNS lookup, or an issue specific to the monitoring location.
If you are running a UserView script, you may need to add a delay to the script to give the site more time to load all elements properly. You can also repeat the step, such as clicking on an href after adding a delay, so in case the link was not rendered on the page the first time, it will try to click it again.
There are a number of factors that determine whether an alert message will be sent and to whom it will be sent.
When you create a device, a default filter is automatically applied to all devices. The default filter requires that more than one location (unless you only select one location) receives the error before an alert is triggered. This is done to eliminate false positive alerts when one location suffers from a small network hiccup. You can create a filter that does not require more than one location, but be aware that you will likely receive many false positive alerts due to the uncontrolled nature of traffic on the internet.
If you have applied a schedule to a device, the device will not be monitored during unscheduled periods, so no data will be recorded to set off an alert. We recommend that you do not apply a schedule directly to your devices so that the system is monitored 24/7 even if you do not wish to receive alerts around the clock. You can apply schedules to different alert groups so that different groups only receive alerts during their work shifts, for example.
When setting up group alerts, you can specify whether the group should receive a notification immediately when the error is detected, or if there should be a delay between when the error is first detected and when an error is sent. For example, perhaps you have a second tier support group that is only notified when an error continues to occur 30 minutes after the first tier support received an alert.
By default, the False positive check is turned on. This means that if a monitoring location experiences an error, it attempts to recreate the error before sending an error message. We do not recommend disabling this because it will increase the risk of receiving false positive alerts, however, if your task takes a particularly long time to complete one iteration, you may wish to turn off the false positive check so that you receive errors immediately rather than 10 minutes after the first error was detected (5 minutes to complete the first task, then when the error is detected, another 5 minutes to confirm the error)
Note that Alert groups can be set up and used for multiple devices. If you notice that someone is not receiving an alert, make sure that their contact information exists in all groups necessary. Be careful when editing or removing people from groups because that group may be used for additional devices.
There are many different errors that can occur while a website is still partially or fully accessible. Some of the most common errors that can occur while your website still appears to be available include:
If the error specifies that a timeout has occurred, edit the monitoring task details and look for a Maximum Timeout value. If you are getting many timeout errors you may want to consider increasing the max timeout value or removing it altogether. Alternatively, you can perform updates to your site to improve load speed or host individual elements at a content distribution network (CDN). If you have not specified a Maximum Timeout value, then the default timeout for a task is 120 seconds.
If the task includes validating a particular keyword or image is found on the page, the rest of the content might still load properly while the expected element is missing.
Some validation may fail if the task looks for an element before the element has completely loaded. If the task is a UserView script, you may need to add a time delay before validating this particular element.
Sometimes, due to various networking issues across the internet or local service providers, one of the specified or top-level DNS servers may be unable to fully qualify the DNS resolution to your site. In this case, most browsers continue to query the next available DNS server and complete the resolution, but depending on how your monitoring is set up, you may still receive alerts. For more information on How to Troubleshoot DNS Errors, visit our knowledge base article here.
In the Online report detail, when I expand an individual monitoring session to view granular details of the steps, why are we seeing errors but the overall monitoring task is succeeding?
There are a number of cases where an individual element or call to a server being monitored will result in a flagged or error response. Such responses are typically noted by a red exclamation mark and the text may be slightly grayed out.
