Success criteria

By default, PathWatch aggregates a multi-region monitor’s status with sensible rules — “any region down = degraded, majority down = down”. Success criteria let you override that with explicit thresholds: how many regions must pass, how fast they must respond, and which HTTP status codes hard-fail the monitor regardless.

Configure them on the monitor edit page under Success criteria.

When to use them

The default aggregation works for most monitors. Reach for success criteria when:

• You want stricter uptime — require every region to succeed, not just a majority.
• You want looser uptime — accept a single region passing while others flake during a partial provider outage.
• You want a performance gate — a fast 200 is “up”, a slow 200 is “down”, regardless of region count.
• You want to hard-fail on specific HTTP codes (e.g. anything above 499 = always down, no matter what the rest of the regions return).

Configuration

Field	Type	Default	Notes
min_passing	"any" | "all" | "majority" | integer N	"any"	How many regions must pass for the monitor to be up. "any" = ≥ 1, "all" = every active region, "majority" = > 50 %, N = at least that many.
max_response_time_ms	integer	—	A region only counts as “passing” if its response time is ≤ this.
max_response_time_at_least_n	integer	1	Combined with max_response_time_ms — at least N regions must meet the response-time gate. Defaults to 1 when the gate is set.
fail_if_any_status_above	integer	—	If any region’s status code exceeds this, the monitor is forced to down regardless of other criteria. Useful as a hard ceiling — 499 rejects 500-series responses outright.

All fields combine with AND semantics. A region “passes” iff its status is success AND it meets the response-time gate (if set) AND its status code doesn’t exceed the fail_if_any_status_above ceiling.

When success criteria are set, the result is binary — up or down. The default degraded band is bypassed; the criteria are the contract.

Examples

Strict uptime — every region must pass:

{
  "min_passing": "all"
}

A single region timing out flips the monitor to down. Use this on critical-path monitors where you don’t want any region’s failure to be invisible.

Performance contract — three regions must respond under 1 s:

{
  "max_response_time_ms": 1000,
  "max_response_time_at_least_n": 3,
  "min_passing": "majority"
}

The monitor is up only if a majority of regions respond at all, and at least three of them respond in under 1 second. A slow-everywhere response goes to down.

Hard ceiling on 5xx:

{
  "fail_if_any_status_above": 499
}

Any single region returning a 500-class status forces the monitor down — useful when you want to alert on the first 500 you see without waiting for a majority of regions to confirm.

Resilient uptime — accept one region passing during a partial outage:

{
  "min_passing": 1
}

(Equivalent to the default "any", written explicitly.) The monitor stays up as long as one region succeeds — handy for geo-distributed services where you only care that some customer path is working.

How regions are counted

skipped results are excluded from the count entirely. A region that ran but was filtered out (e.g. IPv6 sub-check on a cloud-IPv4-only region) doesn’t penalise the monitor.

runner_unavailable results are treated as failures by the criteria path. Use a more resilient monitor (multiple cloud providers via hardened locations) to reduce this signal.

Interaction with alert rules

Success criteria affect the monitor’s overall status, not individual region results. Per-region alert rules (region X has failed N times in a row) still fire on per-region state. Use the monitor-level status alert to consume the aggregated verdict; pair it with confirmation regions for further noise suppression.