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

# Creating monitors

> Set up an HTTP monitor: request options, response assertions, regions, intervals, testing, and pausing.

This covers the HTTP monitor in full, since it has the most options. Most of it (regions, interval, consensus, pausing) applies to every type.

## Request options

Tallwatch sends a request and judges the response. The defaults handle a plain health check; adjust them when your endpoint needs more.

| Option           | Default | Notes                                                                 |
| ---------------- | ------- | --------------------------------------------------------------------- |
| Method           | `GET`   | `GET`, `HEAD`, `POST`, `PUT`, `PATCH`, `DELETE`, or `OPTIONS`         |
| Accepted status  | `200`   | A list, so you can accept several codes (for example `200` and `204`) |
| Headers          | none    | Sent with the request, for auth tokens or content negotiation         |
| Body             | none    | For methods that take one                                             |
| Follow redirects | on      | Follows up to a few hops                                              |
| Timeout          | 10 s    | The check fails if the response doesn't arrive in time                |

<Tip>
  Point monitors at a dedicated health endpoint that touches your real dependencies (database, cache, downstream APIs) rather than a static page. A `200` from a page that doesn't exercise anything tells you the web server is up and nothing else.
</Tip>

### Origin URL

If your service sits behind a CDN, you can set an origin URL alongside the public one. When the public URL fails but the origin succeeds, Tallwatch classifies the failure as `edge_only`, so you can tell a CDN problem apart from an outage of your own service.

## Assertions

Beyond the status code, you can assert on the response. Each assertion runs after the status check, and the first one that fails reports the failure.

* **Response time** under a millisecond budget
* **Body contains** or **body does not contain** a string (case-sensitive optional)
* **Body matches** a regular expression
* **JSON path** equals a value or matches a regex
* **Header** equals a value or matches a regex

A body or JSON assertion is the supported way to do a keyword check today, since it runs on the real HTTP path.

## Regions and interval

Choose the regions the monitor checks from. Three or more is a good baseline, since an incident only opens when more than one region agrees. The regions you pick are the ones that vote.

The interval ranges from 30 seconds to a day. The probers run on a roughly 60-second cadence, so intervals below 60s don't check any faster in practice. Common choices are 60s for important endpoints and 300s for lower-stakes ones.

## Test before you save

Click **Test** on the form to run the check once from the backend and see the real result: status, latency, and which assertion failed if any. Fix the configuration before you save, rather than waiting for the first scheduled check. (Heartbeat monitors are passive and have no test action.)

## Pausing

A monitor is `active` or `paused`. Pause one to stop checks and silence alerts while keeping its history, for example during a long planned migration. For a bounded, scheduled silence across one or many monitors, use a [maintenance window](/monitors/maintenance-windows) instead, which suppresses incidents without pausing the checks themselves.

## Editing and deleting

Edit any setting from the monitor's edit screen; changes apply on the next check. Deleting a monitor is a soft delete, so its incidents and history stay intact for the record.