Monitoring Algorithm

Before reviewing the Dotcom-Monitor monitoring algorithm, it’s helpful to define two key terms:

• Monitoring session: A single monitoring check executed from one location.
• Monitoring cycle: A full round of monitoring sessions across all selected locations.

How Monitoring Works

Under typical conditions, Dotcom-Monitor runs checks in a round-robin order — triggering monitoring sessions sequentially, one location at a time, at the configured frequency. This behavior continues until at least one location reports a different state from the others (e.g., one returns an error while the rest succeed) or other special criteria are met. Then, Dotcom-Monitor runs monitoring sessions from all selected locations.

When Checks Run from All Locations within One Monitoring Cycle

There are special cases in which Dotcom-Monitor doesn’t just run one check at a time, but instead triggers sessions from all locations:

• Right after creating, editing, or restarting a device.
• When an error is detected from one (or more) locations.

Simultaneous Checks

The Allow Simultaneous Checks option controls how sessions are executed when running from all locations (in the special cases above):

• When set to “YES“: all locations run their monitoring sessions simultaneously.
• When set to “NO“: locations run their monitoring sessions one after another, as soon as possible.

Default behavior:

• HTTP-based monitoring (ServerView and WebView): Enabled by default
• Browser-based monitoring (BrowserView and UserView): Disabled and cannot be changed.

Why Sequential Checks Matter for Browser-Based Monitoring

Some web applications don’t support multiple sessions using the same user credentials. For example, logging in from a second location may automatically log out the first session. If Dotcom-Monitor tried to run browser-based sessions simultaneously using the same credentials, it could cause false failures or other errors.

To avoid this, Dotcom-Monitor forces web app monitoring (UserView) sessions to run one after another. This behavior is also useful in other scenarios, such as:

• Applications where shared test data (like a cart or user profile) is updated in real time.
• Workflows involving shared resources (e.g., booking systems or inventory) that may produce inconsistent results when accessed concurrently.

Concurrent Monitoring

As an option, Dotcom-Monitor offers Concurrent Monitoring, which runs sessions from all selected locations in every monitoring cycle, regardless of previous results.