Connect

Synthetic checks

Synthetic checks are scheduled probes against customer journeys and management endpoints. They are sources like any other: their results arrive as metrics, so detection, correlation and explanation treat them as they treat any other signal.

How it works#

A check exercises something a customer or an operator depends on and reports whether it worked and how long it took. MonitOps supports two shapes.

Shape	What it does	Example
Multi-step authenticated check	Obtains a token, then makes a call with it, so that sign-in and the first use of the service are both exercised	Request a token, then make one inexpensive call to a provider API
Single-request check	Makes one unauthenticated request and reports the outcome	A request to a health endpoint

Each check emits two signals on every run.

Signal	Meaning
`success`	`1` when the check passed, `0` when it failed
`latency`	How long the check took, in milliseconds

Checks run on a fixed cadence. The checks in the sample estate run once a minute. A check is tied to what it tests: a declared edge from the check to its target lets a failing check be placed on the service map and correlated with the alerts around it.

Detection#

A failing check is detected by the probe-failure kind of alarm definition. By default, a check is failing after two consecutive runs with success at 0, and the alert is major. It recovers after two consecutive successful runs.

These defaults are an alarm definition, so administrators can edit them: rename the alarm, change the severity or change how many runs are required. Changes are versioned, and past evaluations keep the version that fired them. See Alarm definitions.

A check that stops reporting is a source that stops sending. Silence is raised as its own problem rather than read as passing; see Source health.

Checks as evidence#

When a check fails in the same window as other alerts, it joins the incident like any other alert and appears among the alerts with its detector and fired time. In a cause assessment, a failing check is evidence that can be reopened: the evidence list links to the check result it came from.

Checks as recovery criteria#

Checks are also how recovery is verified. After an approved action runs, MonitOps does not rely on the result of the command. It checks fresh probe results and metrics against the action's recovery criteria, and the incident resolves only when they are met. In INC-20931 this is the card checkout check passing 20 of 20 runs over five minutes, with the order-api error rate back inside its baseline. If the checks do not confirm recovery, the incident stays open and says why. See Actions.

What you see in the console#

A check appears in Sources with its freshness like any other source, and its success and latency series are available to charts and dashboards. Its failure appears among the alerts of an incident, and its results appear in the evidence list and in the verification panel of a run.

Limits and defaults#

Item	Default
Failure	Two consecutive failed runs, severity major
Recovery	Two consecutive successful runs
Missing results	Raised as source silence, never counted as a pass
Edit	Through the probe-failure alarm definition

Last updated October 2026