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.example.com: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. If you need to be sure the service itself answers, pick a protocol check: postgres, mysql, redis, smtp, imap, pop3, ssh or dns — see monitor types.

Checks run from the Notifly cloud, so the target must be reachable from the internet: private, loopback and link-local addresses can’t be monitored. For internal services, use a heartbeat from inside the network.

Scenario 3: SSL certificate on the edge

Certificates have a dedicated monitor type, “SSL certificate is not expiring” (kind: "ssl"): it validates the trust chain and host name and warns you in advance — 14 days before expiry by default (configurable, 1–365):

Create monitor:
  Type:           SSL certificate
  Target:         example.com          ← or example.com:8443
  Interval:       1h
  Warn:           21 days before
  Alert:         "The example.com certificate expires soon!" priority 8

A plain HTTP monitor will also fail on an expired certificate (x509: certificate has expired), but only once it’s already too late; the SSL monitor warns you ahead of time.

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.