Active monitors — HTTP endpoint and TCP port

Unlike the heartbeat, where a cron job confirms liveness, an active monitor works the other way: Notifly periodically pings the specified URL or TCP port. This is useful when:

• the service runs on someone else’s server or you don’t have access to edit its cron;
• you need to check external dependencies — payment gateways, third-party APIs, IoT devices;
• you want to be sure not only that the server’s cron is running, but that the service actually accepts connections (port is open, TLS hasn’t expired, healthcheck responds).

Scenario 1: Website HTTP healthcheck

Create monitor:
  Type:           HTTP(S)
  Target:         https://example.com/health
  Interval:       60s
  Timeout:        10s
  Consecutive failures: 3      ← to ignore single-network jitter
  Expected status:     0      ← any 2xx
  Alert:         "Site example.com is unavailable!" priority 9
  Recovery:      "Site example.com is responding again."

On the first occurrence of 3 consecutive failed GETs you’ll get a push with the title Site example.com is unavailable! and an error detail (status=502 or dial tcp: i/o timeout). When the site responds again — a second push will say “responding again”.

Scenario 2: Database TCP port

Create monitor:
  Type:           TCP port
  Target:         db-replica.internal:5432
  Interval:       30s
  Timeout:        5s
  Consecutive failures: 2
  Alert:         "Postgres replica is not accepting connections!" priority 10
  Recovery:      "Replica is responding on 5432 again."

Notifly performs net.Dial("tcp", host:port) every 30 seconds with a 5s timeout. Useful for:

• Databases — Postgres :5432, MySQL :3306, MongoDB :27017, Redis :6379;
• mail/SMTP — :25, :465, :587;
• SSH bastion — :22 (if something listens on it — the port is open);
• custom gRPC/TCP daemons that don’t have an HTTP healthcheck.

The TCP check does not perform a protocol handshake — it only confirms that the port accepts a connection. That’s usually enough: if the process crashed, no one will be listening on the port anymore.

Scenario 3: SSL certificate on the edge

Not exactly “unreachable”, but related: set an HTTP monitor on your site with expectedStatus: 200 and an interval of 1 hour. If the certificate expires — the Go client will refuse to open the connection and an alert x509: certificate has expired will arrive. Not the prettiest way, but it works “for free” on top of a regular healthcheck.

How this differs from a heartbeat

	Heartbeat	Active monitor
Who initiates	Your cron / service	Notifly itself
Network model	Inbound (Notifly listens)	Outbound (Notifly reaches out)
When useful	To verify the cron actually ran	To verify the service is reachable
Protects against	Cron didn’t run, script hung	Process crashed, port closed, SSL expired
Requires	Access to cron file/code	Just a public URL/host:port

Often both are used together: heartbeat — to ensure the backup started, monitor — to ensure the service it backs up still responds.

Creation from MCP

> Put an active monitor on https://api.notifly.ru/health,
  check every 30 seconds, alert after 3 consecutive failures,
  with recovery message "API is working again".

See the full list of parameters.