Concurrent vs Round-Robin Monitoring Explained

You’re setting up synthetic checks from eight locations. Should every location run on every cycle, or one location at a time in rotation? That one setting decides how fast you catch a regional outage and how many checks you burn doing it.

Most monitoring platforms pick a default and hide the choice. Dotcom-Monitor exposes it, and the two options behave differently enough that the wrong pick either floods you with redundant checks or lets a regional failure sit unnoticed for a full rotation. Here’s how round-robin and concurrent monitoring actually work, where they diverge, and how to choose.

One thing to clear up first. This is not round-robin load balancing. Load balancers use round-robin to spread incoming user traffic across backend servers. Here, round-robin describes how a monitoring platform schedules its own outbound checks across geographic locations. Same name, opposite direction of traffic.

What Round-Robin and Concurrent Monitoring Mean

Two terms make the rest of this easier to follow. A monitoring session is a single check run from one location. A monitoring cycle is one full pass across all the locations you’ve selected.

Round-robin and concurrent describe how sessions get spread across a cycle. Round-robin runs one location per cycle and rotates to the next location next time. Concurrent runs every location on every cycle. The gap between those two patterns is where detection speed, cost, and data quality all get decided.

How Round-Robin Monitoring Works

Round-robin is the default, and it’s built to be economical. At your configured frequency, the platform fires a session from one location, then the next location on the next interval, cycling through your list. As long as every check agrees that the site is up, you get broad geographic coverage without paying to test all eight locations at once.

The clever part is what happens on disagreement. The moment one location reports a state that differs from the rest, say an error while the others succeed, round-robin stops rotating and runs sessions from all locations. It does the same thing right after you create, edit, or restart a device, when it has no baseline to trust yet.

So round-robin isn’t blind to regional problems. It’s adaptive. It stays cheap while everything looks healthy and escalates to full coverage the instant something looks off. The cost of that thrift is timing, which the next sections get into.

How Concurrent Monitoring Works

Concurrent monitoring drops the rotation. Every selected location runs its session on every cycle, no matter what the previous cycle reported. Eight locations at a one-minute frequency means eight checks a minute, every minute.

That gives you a complete geographic snapshot on each interval. If your CDN edge in Frankfurt slows down while everywhere else stays fast, you see it on the next cycle instead of waiting for the rotation to land on Frankfurt. On Dotcom-Monitor, concurrent monitoring is an add-on that needs to be activated, and because it multiplies your check volume, it can raise your package price.

Detection Speed Versus Monitoring Cost

The whole decision comes down to a trade between how fast you spot a location-specific failure and how many checks you’re willing to spend.

Detection delay is the figure people underestimate. With round-robin, a failure that only hits one region waits until the rotation reaches that region before the error fires and triggers full escalation. Across eight locations on a five-minute frequency, that’s up to 40 minutes of a regional outage before the platform reacts. Concurrent closes that gap to a single cycle.

The flip side is data. Because concurrent tests every location continuously, it produces an even, comparable record per location, which is exactly what you need to prove a regional SLA or chase down a slow CDN edge. Round-robin’s record is sparser and harder to compare location against location. If you’re tracking the cost of downtime by region, that difference matters.

Why Browser-Based Checks Run One at a Time

There’s a wrinkle that catches people configuring real-browser checks. Dotcom-Monitor has an Allow Simultaneous Checks setting that controls whether all-location runs fire at the same moment or one after another. For HTTP-based checks (ServerView and WebView) it’s on by default, because each request is stateless and independent, so firing them at once is safe. For browser-based checks (BrowserView and UserView) it’s off and can’t be changed.

The reason is state. A lot of web apps tie a logged-in session to one set of credentials. Sign in from a second location and the first session gets kicked out. Run a multi-step EveryStep transaction from five locations at once and they’ll trip over each other, producing false failures that have nothing to do with your app’s real health.

Shared state breaks under parallel access. A cart, a booking record, or an inventory count updated by five simultaneous sessions returns results that don’t reflect what a single user would see.

So even under concurrent monitoring, browser-based sessions run sequentially by design. You still get every location on every cycle. They just don’t fire at the same instant, which keeps credential conflicts and shared test data from poisoning your results.

When Round-Robin Is the Right Default

Round-robin is the right call more often than its modest reputation suggests. Reach for it when:

• You’re running broad uptime coverage. A marketing site or blog served from one origin behaves the same everywhere. Rotating locations confirms it’s reachable globally without paying to test all of them each minute.
• Your content is geographically uniform. If there’s no CDN routing or regional infrastructure to validate, every location is testing the same thing, and concurrent’s extra checks tell you little new.
• Budget is tight and your SLA is global, not regional. Round-robin’s escalation still catches outages; it just trades a bit of detection time for a much lower check count.

Picture a SaaS company watching its public uptime page across ten regions. Nothing about the page changes by geography. Round-robin keeps a steady global pulse, and the first regional error escalates to full coverage on its own. That’s the design working as intended.

When Concurrent Monitoring Earns Its Cost

Concurrent monitoring pays for itself when geography is part of what you’re testing or when minutes of delay carry real cost. Turn it on when:

• You serve content through a CDN or geo-routing. Edge performance varies by region, and a problem in one POP won’t show until you test that region. Concurrent watches every edge on every cycle.
• You hold regional SLAs. Proving 99.9% in three regions takes continuous, comparable per-location data, not the uneven sample round-robin leaves behind.
• A checkout or login path drives revenue. For an ecommerce checkout, a regional failure that sits unnoticed for half a rotation is lost orders. Immediate detection is worth the add-on.

Take a retailer running a transaction check through checkout from six regions during a sale. A payment gateway that fails only for European traffic needs to surface in seconds, not after the rotation eventually reaches Europe. Concurrent monitoring, paired with fast monitoring alerts, is what makes that possible.

The Bottom Line

Round-robin is the economical default: one location per cycle, automatic escalation to all locations the moment a check disagrees. It fits broad, geographically uniform uptime coverage. Concurrent monitoring tests every location on every cycle for immediate regional detection and clean per-location data, at the cost of more checks and an add-on fee. It fits CDN-served apps, regional SLAs, and revenue paths where delay is expensive.

Match the pattern to what you’re actually testing. If geography changes the answer, run concurrent. If it doesn’t, round-robin already has you covered. Either way, getting monitoring from multiple locations right starts with knowing how your checks are scheduled.