HTTP monitors (advanced)

The “light” http type in active monitors performs only GET <url> and compares the status code with 2xx (or expectedStatus). That’s enough for a simple health-check, but doesn’t cover cases like “send POST /api/login with a JSON body and an Authorization header, then check that the response contains "status":"ok" and code 200”.

An HTTP monitor is a separate entity with its own REST API that supports:

• arbitrary method — GET, POST, PUT, PATCH, DELETE, HEAD;
• arbitrary headers (headers) — a JSON object {"Header": "Value"};
• request body (body) — for POST/PUT/PATCH;
• response filtering — by status code, range of codes, substring/regex in body, value by JSONPath, and maximum response time;
• two reaction modes — alert on a filter “match” or “mismatch”.

Everything else (interval, timeout, consecutive failures, alert/recovery texts, pauses) works the same as for regular monitors.

Monitor fields

Field	Type	Required	Description
appid	number	yes	ID of the channel to send notifications to
name	string	yes	Monitor name, 1–200 characters
method	string	yes	GET, POST, PUT, PATCH, DELETE, HEAD (case-insensitive)
url	string	yes	A valid http(s) URL
headers	string	no	JSON object of headers: {"Authorization": "Bearer ..."}
body	string	no	Request body (for POST/PUT/PATCH)
intervalSec	number	yes	Interval between checks, 30–86400 seconds
timeoutSec	number	no	Timeout for one attempt, default 10, maximum 30
filterMode	string	yes	alert_on_match or alert_on_mismatch (see below)
filters	string	yes	JSON array of filters (see Response filters)
consecutiveFails	number	no	How many consecutive failures before alert, default 1, maximum 20
alertMessage	string	yes	Notification text when triggered, 1–2000 characters
alertTitle	string	no	Notification title
alertPriority	number	no	Push priority, 0–10
recoveryTitle	string	no	Recovery message title
recoveryMessage	string	no	Text when returning to normal (if empty — no recovery is sent)

Timeout up to 30 seconds

For HTTP monitors the timeoutSec ceiling is 30 seconds (default 10). If you need longer scenarios — see content-, workflow- or browser monitors.

Response filters

filters is a JSON array of objects. Each object describes a condition that the response must satisfy. You can combine multiple checks in a single filter. Available filter fields:

Filter field	Type	What it checks
statusCode	number	Exact HTTP code (0 = don’t check)
statusCodeMin / statusCodeMax	number	Range of codes [min, max] inclusive (0,0 = don’t check)
bodyContains	string	Substring that must be contained in the body
bodyRegex	string	Regular expression (Go syntax) for the body
jsonPath	string	Path in a JSON response, e.g. $.status or data.0.id
jsonPathValue	string	Expected value at jsonPath (string comparison)
maxDurationMs	number	Maximum allowed response time in ms (0 = don’t check)

Filter mode (filterMode)

• alert_on_mismatch — describe what a normal response looks like. If the actual response does not match the filters — an alert is sent. This is a whitelist logic and the most common scenario.
• alert_on_match — describe a problematic response. If the actual response matches the filter — an alert is sent. Useful to catch specific errors.

// filterMode = "alert_on_mismatch":
// normal — code 200 and JSON {"status":"ok"}; otherwise alert.
[
  { "statusCode": 200, "jsonPath": "$.status", "jsonPathValue": "ok" }
]

// filterMode = "alert_on_match":
// alert if the word "maintenance" appears in the body OR the code is in 5xx.
[
  { "bodyContains": "maintenance" },
  { "statusCodeMin": 500, "statusCodeMax": 599 }
]

// normal — responds faster than 800 ms and code 2xx (filterMode = "alert_on_mismatch"):
[
  { "statusCodeMin": 200, "statusCodeMax": 299, "maxDurationMs": 800 }
]

States and events

An HTTP monitor uses the same statuses as regular monitors: pending (created, no checks yet), up, degraded (there are failures, but the consecutiveFails threshold has not yet been reached), down (alert sent), and paused.

Event	When	Text
Alert	After consecutiveFails consecutive filter triggers (according to filterMode), only on the first transition to down. Technical information is added to the message (last code, body preview, error)	alertMessage
Recovery	On the first successful check after down, only if recoveryMessage is set	recoveryMessage

While the monitor is down, no repeated alerts will be sent — checks continue and only record the status.

Test request

Before creating a monitor you can perform a one-time test request and inspect the response — nothing is saved. POST /http-monitor/test accepts method, url, headers, body, timeoutSec and returns statusCode, bodyPreview (first 2048 characters), headers (JSON of response headers), durationMs and error (if the request failed).

curl -X POST "$NOTIFLY_URL/http-monitor/test" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <client-token>" \
     -d '{
       "method": "POST",
       "url": "https://api.example.com/login",
       "headers": "{\"Content-Type\": \"application/json\"}",
       "body": "{\"user\":\"probe\",\"pass\":\"...\"}",
       "timeoutSec": 10
     }'
# → {"statusCode":200,"bodyPreview":"{\"status\":\"ok\"}","headers":"{...}","durationMs":134}

Creating a monitor

Via the web UI

1. Open app.notifly.ru → Monitors → HTTP.
2. Specify the name, channel, method, URL, and optionally — headers and body.
3. Configure the interval, timeout, and number of consecutive failures.
4. Describe the response filters and choose the mode (alert_on_match / alert_on_mismatch).
5. Set the alert and recovery texts.

Via the REST API

curl -X POST "$NOTIFLY_URL/http-monitor" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <client-token>" \
     -d '{
       "appid": 12345,
       "name": "API login health",
       "method": "POST",
       "url": "https://api.example.com/login",
       "headers": "{\"Content-Type\": \"application/json\"}",
       "body": "{\"user\":\"probe\",\"pass\":\"...\"}",
       "intervalSec": 60,
       "timeoutSec": 10,
       "filterMode": "alert_on_mismatch",
       "filters": "[{\"statusCode\":200,\"jsonPath\":\"$.status\",\"jsonPathValue\":\"ok\"}]",
       "consecutiveFails": 2,
       "alertMessage": "Логин-эндпоинт не отвечает как надо!",
       "alertPriority": 9,
       "recoveryMessage": "Логин снова работает."
     }'

The fields headers, body and filters are passed as strings (JSON inside JSON), so in the curl examples their contents are escaped.

Via MCP (for the AI assistant)

If a Notifly MCP server is configured (see MCP), it’s enough to describe the task in words:

Create an HTTP monitor: POST to https://api.example.com/login with a JSON body, check every minute that the code is 200 and the response has status=ok, alert after 2 consecutive failures.

REST API

Method	Path	Description
GET	/http-monitor	List user’s HTTP monitors
POST	/http-monitor	Create
POST	/http-monitor/test	One-time test request (without saving)
PUT	/http-monitor/:id	Update settings (cannot change appid)
DELETE	/http-monitor/:id	Delete
POST	/http-monitor/:id/pause	Pause checks
POST	/http-monitor/:id/resume	Resume

Create, update, delete, pause and resume require a client (or MCP) token with write permissions. POST /http-monitor/test is available without being tied to a specific monitor.

Related monitors

• Active monitors — “light” checks (HTTP-GET, TCP, DNS, TLS-expiry).
• Content monitors — track changes in page content.
• Workflow monitors — chains of HTTP steps with value extraction.
• Browser-workflow — scenarios in a real browser.