--- title: Locations & scheduling description: Check intervals, probe regions and cities, round-robin vs. parallel checks, and how a failed check is confirmed before it becomes an incident. canonical: https://watchfor.io/docs/monitors/scheduling --- # Locations & scheduling Check intervals, probe regions and cities, round-robin vs. parallel checks, and how a failed check is confirmed before it becomes an incident. Every monitor has three scheduling settings — **interval**, **locations** and **strategy** — and one behavior that ties them together: a failure has to be **confirmed** before WatchFor calls anything Down. This page explains all four. ## Check interval The interval is how often a check runs. In the dashboard it is a slider from 30 seconds to 24 hours (10- and 20-second intervals are reserved for Enterprise). Through the API you pass `interval` in seconds. The **minimum interval depends on your plan and on the monitor type**: fast types such as HTTP or ping can run every 30 seconds on the right plan, while heavy or rate-limited types (domain expiry, breach lookups, Core Web Vitals audits) have higher floors. The form shows the effective minimum for the selected type, and the API rejects intervals below it with a clear message. Two types work differently: - **Heartbeat / cron** monitors have no check interval — you define the expected ping period or cron expression instead. See [Heartbeat & cron jobs](/docs/monitors/heartbeat). - **SSL monitors with TLS grading** keep checking the certificate on the interval, but the heavier grade scan runs at most once a day. See [Certificates & domains](/docs/monitors/certificates#tls-grade). ## Locations WatchFor checks from **20 probe locations across seven world regions** — Europe, Asia, Middle East, North America, South America, Oceania and Africa. The full list, with IPv4/IPv6 addresses for allowlisting, is at [Probe locations & IP ranges](/docs/reference/probe-locations). How you pick locations depends on your plan: | Picker | What you choose | Plans | | --- | --- | --- | | **Region-level** | One or more whole regions. Each region is a rotating pool of its cities. | Every plan (the number of regions per monitor depends on the plan). | | **Individual locations** | Expand a region and tick exactly the cities you want, e.g. *Vilnius + Stockholm*. | Plans with multi-location selection. Selecting a whole region never counts against the per-monitor location budget; hand-picked cities do. | | **Private locations** | Probes running inside your own network. | Enterprise. | A monitor's locations are also filtered by capability: Core Web Vitals monitors only offer locations that run a real browser. Heartbeat monitors have no locations — your systems ping WatchFor, not the other way round. ## Scheduling strategy | Strategy | Behavior | When to use | | --- | --- | --- | | **Round Robin** (default) | One location per check, rotating through your selection. | Most monitors: global coverage over time at the lowest load on your target. | | **Parallel** | Every selected location checks at the same time, on every interval. | When you need a simultaneous view from all vantage points (regional outages, CDN edges). Plan-gated (Pro and above), and plans cap how many monitors may use it. | With round robin, a whole selected region behaves as one rotating pool; when you hand-pick cities, only those cities are used. ## How a failure becomes an incident 1. **A check fails** at one location. The monitor shows **Degraded** — a failure has been seen, but it is not confirmed. 2. **Confirmation re-checks start immediately** on an accelerated schedule — every 30 seconds for the first 5 minutes, then every minute up to 15 minutes, then every 5 minutes for up to an hour — rotating through the monitor's locations, so the same failure has to be reproduced from other vantage points. 3. **The alert rule's failure threshold is reached** (for the built-in *Availability Check* that is 3 consecutive failed checks). An **incident** opens, notifications go out, and the monitor shows **Down**. 4. **Recovery.** The accelerated cadence continues while the incident is open, so recovery is noticed within seconds; the incident resolves and the normal interval resumes. A failure that stops reproducing during step 2 never becomes an incident and never pages anyone. Read more in [How incidents work](/docs/alerting/incidents) and [Alert rules](/docs/alerting). ### Types with a different confirmation policy Some checks are too slow, too expensive or single-sourced to re-run every 30 seconds. Their alert rules still apply their own failure thresholds, but there is no accelerated confirmation phase: | Type | Policy | | --- | --- | | **Core Web Vitals (browser)** | No accelerated re-checks — one Lighthouse audit already answers the question. Rules evaluate on the normal interval. | | **Heartbeat / cron** | No re-checks — the signal is the absence of a ping, and there is nothing another location could confirm. | | **Domain expiry (RDAP)**, **Data breach**, **Blacklist (RBL)** | No re-checks — registry and reputation lookups are rate-limited and change slowly. | | **MCP server** | No re-checks — tool-inventory drift is observed once and re-baselined, so it must alert on the first observation. | | **Network path (MTR)** | Re-checks every 2 minutes for up to 10 minutes instead of every 30 seconds. | ## IP version Checks prefer **IPv4**. For every type that connects to your target (all but heartbeat, domain expiry and blacklist) you can change this under **Settings → Advanced Options → Network Protocol (IP)**: **Auto (Prefer IPv4)**, **Force IPv4** or **Force IPv6** (`ipVersion`: `any`, `ip4`, `ip6` in the API). Every probe location is dual-stack. See [Choosing IP version](/docs/reference/probe-locations#choosing-ip-version). ## Also via API `interval`, `locations` (location IDs from [`GET /v1/locations`](/docs/api/locations)) and `schedulingStrategy` (`roundrobin` or `parallel`) are fields on [create](/docs/api/monitors#create-a-monitor) and [update](/docs/api/monitors#update-a-monitor) monitor calls. The same plan rules apply: an interval below the plan floor or a strategy the plan doesn't include is rejected with a descriptive error. --- Canonical page: https://watchfor.io/docs/monitors/scheduling · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt