Skip to main content

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.

This covers the HTTP monitor in full, since it’s the supported type. Most of it (regions, interval, sensitivity, 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.
OptionDefaultNotes
MethodGETGET, HEAD, POST, PUT, PATCH, DELETE, or OPTIONS
Accepted status200A list, so you can accept several codes (for example 200 and 204)
HeadersnoneSent with the request, for auth tokens or content negotiation
BodynoneFor methods that take one
Follow redirectsonFollows up to a few hops
Timeout10 sThe check fails if the response doesn’t arrive in time
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.

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