Web & uptime
Monitor websites and APIs over HTTP and HTTPS.
The HTTP monitor is the workhorse — it checks that a website or API responds correctly, from multiple locations, on your schedule.
What it checks
For every request, WatchFor records the status code, response time (with a per-stage breakdown — DNS, connect, TLS, first byte, download), and the response body when you ask it to.
Common settings
| Setting | Notes |
|---|---|
| Method | GET by default; other methods supported for API checks. |
| Expected status | Treat specific codes as healthy (e.g. 200, or a range). |
| Body match | Require the response to contain (or not contain) a keyword. |
| Headers | Send custom request headers — auth tokens, host headers, etc. |
| No-cache preset | One click adds headers that bypass caches, so you test the origin. |
Alert presets
Turn these on from the monitor's Alerting tab:
- Site is down — connection failures or error status codes.
- Slow response — response time over a threshold you choose.
- Body match failed — an expected keyword is missing (or a forbidden one appeared).
Each preset can be Warning or Critical — see Alert rules.
For real-browser performance (Core Web Vitals, Lighthouse score) rather than a raw HTTP request, use the Core Web Vitals monitor.
Reading the results
The monitor view shows an uptime summary, a response-time chart (with a logarithmic option for spiky latency), and a waterfall of where the time went on each request — handy for spotting a slow TLS handshake or a sluggish origin.