Find your account ID under the Account menu in the drop-down list or under Account < Account Settings < General.
Once logged in into a master account you can find your Department IDs under Account < Account Settings < Departments.
The approach provides the ability to carefully define how Dotcom-Monitor interprets responses as either “up” or “down” responses. This is accomplished using filters.
Filtering defines the UP/DOWN state 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.
The Formula for the Downtime calculation is as follows:
Let’s say we have device monitored from 7 locations and filter set that 3 locations must report 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. 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 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 UP state only on the T9 response, when the number of failing Agents becomes less than adjusted in Filter. Here comes the final downtime % calculation formula for this case:
LoadView uses Load Injector Servers from Amazon Web Services (AWS) and Google Cloud Platform (GCP). Dotcom-Monitor has 12 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 12 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)|
|6,000,000 users||150,000 users||150,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.
You can edit the 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.
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 IP address to only allow authorized users access. Before using the API you must contact support and give them the IP addresses of the locations where you will be accessing the API.
For more information on how to use the API visit the API getting started page.
Dotcom-Monitor automatically purges data from the system according to the following schedule.
For active accounts:
This retention policy applies to all task types.
Trial account data is not retained according to this schedule and may be deleted any time after the trial expires.
Closed account data may be purged from the system within 60 days of the last user login for the account.
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 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. They may direct you to input all of the objects that you want created into a spreadsheet with a column for each relevant field.
Once your spreadsheet is completed you can attach it to the support ticket or email it to support and they will populate the 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, log in to Dotcom-Monitor and in the navigation menu at the top of the Dotcom-Monitor website, navigate to Configure, Dashboards.
Expand the accordion menu containing your dashboards and click the actions button to the right of the dashboard you wish to access.
Selecting preview will open the dashboard in a new window while clicking copy url will copy the url of the dashboard to your clipboard.
Now you can save the url to a file, email the url to others, or paste the url into a browser window and bookmark the address to easily access it in the future.
You can silence individual device alerts from the Device Manager by clicking actions next to the device and silencing for the desired period.
To silence multiple devices, click the checkbox next to each device you wish to silence and then, click the blue actions label at the top of the table, and select Alert Silence for the period you wish.
If you wish to silence devices for more than 3 hours, You can use the API. For information on how to do this, checkout API: Disable Alerts for a Device.
Before you can use the API, you must notify support what IP addresses to allow API access from.
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 unaccessible 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.
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.