Synthetic monitoring

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.

Check types

Five types, each with a real executor:

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

Assertion types:

• status_code
• response_time
• header
• body_json
• body_text

Operators:

• 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

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.