Skip to main content
Synthetic checks probe your endpoints from outside, on a schedule, so you find out an endpoint is down without waiting for a user to tell you.
A fresh install cannot create checks until a probe location is registered. Every check must name at least one location, and a location only exists once an operator has deployed a runner and registered it. There are none by default.If check creation is rejecting your location, this is why — it is not a malformed request. Ask whoever operates your deployment to register a probe location first. Nothing else on this page works until that is done.

​
Check types

Five types, each with a real executor. HTTP checks support GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS, with request bodies as JSON, text, XML or form-encoded.

​
Scheduling

Frequency is set per check, with a minimum of 30 seconds and a maximum of 24 hours. Checks can also be triggered manually, which is the sane way to iterate on a new check rather than waiting for its next scheduled run. Maintenance windows suppress checks during planned work, so a deploy does not generate a false page.

​
Assertions

An assertion is a type, an operator and an expected value. A check that fails its assertions is recorded as failed or degraded.
  • status_code
  • response_time
  • header
  • body_json
  • body_text
A typical HTTP check asserts a status_code of eq 200 and a response_time of lt some millisecond budget.
Asserting on body_text or body_json as well is what distinguishes “the server responded” from “the server responded correctly” — a 200 carrying an error page passes the first and fails the second.

​
Multi-step checks

A multistep check runs up to 10 steps in order. Each step needs a name and a request URL. Values captured from one step can be interpolated into later ones with {{variable}} syntax, which is how you test a flow that requires a token from a login step. Variables can be marked secret so their values are not displayed back. Ten steps is a real ceiling, not a soft guideline. If a flow needs more, it is usually better split into several checks anyway — a 15-step check that fails at step 12 tells you much less than the check that covers only that part.

​
Alerting on failures

Synthetic alerts are dispatched by the synthetics scheduler, not by the main alert evaluation loop. This is the practical difference from ordinary alert rules: creating a rule of type SYNTHETIC in the alerts UI and expecting the evaluator to run it will not work, because that loop skips the type. Configure notification on the check itself.

​
Next

Alerting

Alert when a check fails.

Searching logs

Correlate a failure with your logs.