Synthetics

A synthetic check in LeanSignal is a scheduled HTTP request plus assertions, routed to your channels. Checks live under Synthetics in the LeanSignal app and belong to a demand, like alerts and dashboards. LeanSignal probes each check on its interval from the platform, tracks an up/down state, and — after a number of consecutive failures you choose — marks the check Failed and notifies your channels. When it succeeds again it returns to OK and notifies once more.

Unlike alerts, a check is not built on a metric — it actively calls an endpoint. So a synthetic works even for a service that emits no telemetry at all, and it never adds anything to what your agents collect (see Synthetics and demands).

Create a check

Go to Synthetics → Add check (editor or admin role). The form:

Field	What it does
Name	Shown in the list and in notifications.
Demand	The demand this check belongs to (required).
Method	GET (default), HEAD, POST, PUT, PATCH, DELETE, or OPTIONS.
URL	The http/https endpoint to probe.
Headers	Optional request headers (key/value rows) — for example an Authorization or a custom User-Agent.
Body	Optional request body, for POST/PUT/PATCH.
Timeout	How long to wait for a response before the run fails (default 10s; 1–30s).
Follow redirects	Follow up to 5 redirects (on by default); the asserted status is the final response.
Expected status	Which HTTP status codes pass — see Assertions. Default 2xx.
Max response time	Optional. If set and the response is slower, the run fails.
Body contains	Optional substring the response body must contain, or the run fails.
Every	How often to run the check. Whole minutes or coarser (1m, 5m, 1h) — the minimum is 1m.
Failure threshold	How many consecutive failed runs flip the check to Failed and notify. 1 alerts on the first failure.
Recovery threshold	How many consecutive successes return it to OK (default 1 — the first success recovers).
Severity	critical, warning, or info — a label carried into notifications.
Message	Optional text included in the notification — supports {{placeholders}}, see Message templates.
Notify on resolve	Also send a notification when the check recovers.
Channels	The channels to deliver to.

Before saving, press Test now to run the probe once against the current form and see the live outcome — status code, latency, and which assertion failed — without creating anything or changing any state.

No channel means paused

A check with no channel has nowhere to deliver, so it is always saved paused and cannot be resumed until you attach a channel — the same rule as alerts. Checks without a channel carry an amber warning icon in the list.

Message templates

The Message field works exactly like the one on alert rules: plain text plus {{placeholders}}, with a placeholder catalog and a live preview in the editor. Checks have their own set:

Placeholder	Fills with
{{check.name}}, {{check.url}}	The check’s name and the URL being probed.
{{check.status}}	failed or recovered.
{{check.status_code}}, {{check.last_error}}	The last observed HTTP status, and the most recent probe error if any.
{{severity}}, {{tenant.name}}, {{time.triggered}}, {{link}}	The severity label, the tenant, the transition time (UTC), and a link back to Synthetics in LeanSignal.

Assertions

A run passes only if every assertion you set passes:

• Status code (always checked). expected_status is a comma-separated list of terms — an exact code (200), a range (200-299), or a class shorthand (2xx = 200–299, 3xx, 4xx, 5xx). The response matches if it hits any term. Examples: 2xx (default), 200,201,204, 200-299,304, 2xx,3xx.
• Max response time (optional). The run fails if the response is slower than the value you set.
• Body contains (optional). The run fails if the response body does not contain the substring.

Anything that stops a response arriving — DNS failure, connection refused, a TLS error, or the timeout — is a failed run too. For an uptime check, unreachable is down.

How states work

Each run’s outcome moves the check through a small state machine:

Status	Meaning
OK	The last run passed.
Failing	A recent run failed, but the failure threshold hasn’t been reached yet — a silent in-between, no notification.
Failed	The threshold was reached. A notification went out on the transition.
Paused	Scheduling is switched off — manually, or because the check has no channel.

Details worth knowing:

• Notifications fire on transitions only — once when the check enters Failed, and once on Failed → OK if Notify on resolve is on. A check that stays failed does not re-notify.
• The thresholds count consecutive runs. A single success while Failing resets the failure count; a single failure while recovering resets the success count. This debounces flapping so a transient blip doesn’t page you — set a failure threshold of 2 or 3 for noisy endpoints.
• Pausing stops scheduling entirely and clears the check’s counters; on resume it starts fresh at OK.

Test, pause, run

• Test now (in the edit dialog) runs the probe live and reports the result without changing state or notifying — use it to validate a URL or an assertion before saving. You can also re-run a saved check on demand from its row in the list.
• Pause / Resume (in the list) stops and restarts scheduling. Resume is refused while the check has no channel.

Synthetics and demands

A check belongs to a demand — it is listed under that demand and is deleted with it, so every check is organised the same way as dashboards and alerts. A check is not part of the demand’s export/import bundle, though: that bundle carries only dashboards and alert rules.

But a check has no metrics, so — unlike an alert — it adds nothing to the demand set your agents forward. Creating, editing, or deleting a check never changes what your agents collect; it only schedules a probe from the platform. “Linked to a demand” (organisation) and “in the demand set” (collected telemetry) are two different things — a synthetic has the first, not the second.

Limits

• HTTP only for now — TCP, ICMP, browser, and multi-step checks are on the roadmap.
• Up to 20 checks per tenant. The Add check button tells you when you’ve reached the cap; delete a check to free a slot.
• 100,000 runs per month, all checks combined. At the cap, probing pauses for the rest of the month and resumes at rollover; the Synthetics meter on Home tracks the figure and flags the pause.
• Checks probe from the LeanSignal platform, so the target must be reachable from there. Internal/private addresses are blocked by default.

Next steps

• Channels — where checks deliver.
• Alerting — the metric-based sibling of synthetics.
• Work with demands — how checks fit the demand model.