> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Synthetic monitoring

> HTTP, SSL, DNS, TCP and multi-step checks run from probe locations — including the prerequisite that blocks a fresh install.

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.

<Danger>
  **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.
</Danger>

## Check types

Five types, each with a real executor.

| Type          | What it does                                                                                         |
| :------------ | :--------------------------------------------------------------------------------------------------- |
| **HTTP**      | Request a URL and assert on the response. `http` and `https` schemes only.                           |
| **SSL**       | Inspect a TLS certificate, typically for expiry.                                                     |
| **DNS**       | Resolve a name and assert on the records returned. Supports `A`, `AAAA`, `CNAME`, `MX`, `NS`, `TXT`. |
| **TCP**       | Confirm a port accepts connections.                                                                  |
| **Multistep** | A sequence of HTTP requests, for flows that need more than one call.                                 |

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**.

<Tabs>
  <Tab title="Assertion types">
    * `status_code`
    * `response_time`
    * `header`
    * `body_json`
    * `body_text`
  </Tab>

  <Tab title="Operators">
    | Operator              | Meaning                       |
    | :-------------------- | :---------------------------- |
    | `eq`, `ne`            | Equal, not equal              |
    | `lt`, `gt`            | Less than, greater than       |
    | `contains`, `matches` | Substring, regular expression |
    | `exists`              | The field is present          |
    | `in`, `notIn`         | Membership in a set           |
  </Tab>
</Tabs>

A typical HTTP check asserts a `status_code` of `eq 200` and a `response_time` of
`lt` some millisecond budget.

<Tip>
  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.
</Tip>

## 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

<Warning>
  Synthetic alerts are dispatched by the synthetics scheduler, **not** by the
  main alert evaluation loop. This is the practical difference from
  [ordinary alert rules](/guides/alerts/overview): 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.
</Warning>

## Next

<CardGroup cols={2}>
  <Card title="Alerting" icon="bell" href="/guides/alerts/overview">
    Alert when a check fails.
  </Card>

  <Card title="Searching logs" icon="magnifying-glass" href="/guides/logs/search">
    Correlate a failure with your logs.
  </Card>
</CardGroup>