HTTP checks
The default check type. WatchDeck issues a request to your URL with undici, captures the response, and feeds it to the evaluators.
What you can configure
From the General section of the add-endpoint form:
| Field | Notes |
|---|---|
| URL | Full http:// or https:// URL. |
| Method | GET (default) · POST · PUT · PATCH · DELETE · HEAD. |
| Custom headers | Key/value rows. Use this for auth — see the callout below. |
| Expected status codes | One or more codes. Anything else fails the status evaluator. Default [200]. |
From the Monitoring section:
| Field | Notes |
|---|---|
| Check interval | 60s minimum. Preset chips: 1, 5, 10, 30, 60 minutes. |
| Timeout | Aborts the request. Default 10s. |
| Latency threshold | Above this, the run is degraded. Default 5s. |
| SSL warning window | HTTPS only. Default 14 days. See SSL & certificates. |
| Failure threshold | Consecutive down runs needed before an incident opens. Default 3. |
| Recovery threshold | Consecutive healthy runs to close an incident. Default 2. |
Auth via headers
There are no first-class fields for basic auth, bearer tokens, query parameters, or a request body. Set them through custom headers instead:
Authorization: Bearer eyJhbGciOiJ...Authorization: Basic base64(user:pass)The default User-Agent is WatchDeck/1.0 — override it by adding a User-Agent row in the headers list.
Custom headers are stored in the database in plain text. Treat anything you paste here the same way you would a CI environment variable — rotate them when collaborators leave.
What’s not configurable
These intentionally aren’t surfaced in the UI yet:
- Request body. GET-equivalents only;
POST/PUT/PATCHwith a body isn’t supported in the cloud check engine. - Query string builder. Append
?foo=barto the URL directly. - Redirect toggle. WatchDeck follows up to 5 redirects by default. The cap is hardcoded.
- Per-request cookies. Send them via a
Cookieheader.
What counts as healthy
A run is healthy when all of these hold:
- The response status is in
expectedStatusCodes. - Total response time is at or below
latencyThreshold. - Every configured assertion passes.
If the status isn’t in the expected list, the run is down with reason like "HTTP 502 — expected 200". If the response is too slow, it’s degraded. Assertions can downgrade a healthy run to degraded or down depending on each rule’s severity.
What’s next
- Add assertions so you catch silent body/header regressions, not just outages.
- Configure the SSL warning window for HTTPS endpoints.
- Wire notification channels so failures reach you.
- Troubleshooting — common gotchas when an HTTP check misbehaves.