Multi-step Monitoring
Monitor complete user flows — login, checkout, form submission — by chaining HTTP requests and extracting values between steps.
What is multi-step monitoring?
Standard HTTP monitoring checks a single URL. Multi-step monitoring lets you chain multiple HTTP requests in sequence — simulating a real user flow like:
- Login → navigate to dashboard → verify content
- Add product to cart → proceed to checkout → verify total
- Submit a contact form → verify success message
- Call an auth endpoint → use the returned token in the next request
If any step fails (wrong status code, missing body content, failed JSON assertion), the entire check is marked as down and an alert is sent.
Step configuration
| Field | Description |
|---|---|
| Name | Label for this step (shown in error messages) |
| URL | Full URL to request. Can include extracted variables: {{token}} |
| Method | GET, POST, PUT, PATCH, DELETE |
| Body | Request body for POST/PUT. Can include variables: {"token":"{{token}}"} |
| Assert status | Expected HTTP status code (e.g. 200, 201, 302). Leave empty to accept any 2xx. |
| Assert body contains | Text that must appear in the response body |
| Assert JSON | Dot-notation path = expected value. E.g. status = ok |
| Extract variable | Variable name to store an extracted value (used in later steps) |
| Extract path | JSON path to extract from response. E.g. data.token |
Variable extraction
Steps can extract values from responses and pass them to subsequent steps using the{{variableName}} syntax.
Example — authenticated API flow
Step 1 — Login
| Field | Value |
|---|---|
| URL | https://api.example.com/auth/login |
| Method | POST |
| Body | {"email":"test@example.com","password":"secret"} |
| Assert status | 200 |
| Extract variable | token |
| Extract path | data.access_token |
Step 2 — Fetch protected resource
| Field | Value |
|---|---|
| URL | https://api.example.com/profile |
| Method | GET |
| Body | |
| Assert status | 200 |
| Assert JSON | user.active = true |
{{token}} extracted in Step 1 is automatically available in the URL and body fields of all subsequent steps.Step ordering
Steps run in order from top to bottom. Use the ↑ and ↓ buttons in the panel to reorder steps. The step order is saved immediately when you click Save Steps.
Assertions
Status code assertion
Enter the expected HTTP status code. If the response status doesn't match, the step fails. Leave empty to accept any response (including errors — useful for intermediate steps).
Body contains assertion
A plain text string that must appear anywhere in the response body. Case-sensitive. Use this to verify page content, error messages, or success indicators.
JSON assertion
Checks a specific field in a JSON response. Format: path.to.field = expected
| Assertion | Passes when response contains |
|---|---|
| status = ok | {"status":"ok"} |
| user.active = true | {"user":{"active":true}} |
| data.count = 5 | {"data":{"count":5}} |
Response time anomaly alerts
Multi-step checks support slowness anomaly detection. Enable it in site settings → Slowness anomaly alert. Set a multiplier (e.g. 2×) — if the total check time exceeds 2× the recent baseline average, an alert is sent.
The baseline is calculated from the last 20 check results. A 1-hour cooldown prevents alert flooding.