Monitoring Overview

AlertifyPro monitors services — HTTP endpoints, databases, mail servers, raw TCP ports, DNS, and more. Each service is checked on a configurable schedule from the scheduler and results are stored as check logs.

Check statuses

Status	Meaning
🟢 GREEN	Check passed within normal response time
🟡 YELLOW	Check passed but response time exceeded 1000ms (degraded)
🔴 RED	Check failed — connection refused, timeout, wrong response

How checking works

The AlertifyPro scheduler polls active services every 10 seconds and dispatches checks concurrently. Each check:

1. Opens a connection to the service endpoint
2. Performs the protocol-specific probe
3. Records the result (status + response time ms + HTTP status code where applicable)
4. Evaluates configured alert rules against the result

The check_interval_seconds field on each service controls how often it's actually checked (default: 60 seconds, minimum: 10 seconds from the scheduler poll rate).

---

Supported check types

check_type	What it checks	Endpoint format
HTTP / HTTPS	GET the URL, check response	https://api.example.com/health
TCP / TELNET	TCP port reachable?	host:port
PING / ICMP	ICMP ping	hostname or IP
DNS	Hostname resolves?	hostname
WEBSOCKET / WS	WebSocket upgrade succeeds?	wss://ws.example.com/feed
SMTP	SMTP server responds with 220 greeting	smtp.example.com:587
IMAP	IMAP server responds with * OK	mail.example.com:993
FTP	FTP server responds with 220 greeting	ftp.example.com:21
SSH	SSH server responds with SSH banner	host.example.com:22
REDIS	Redis responds to PING with +PONG	redis.example.com:6379
MYSQL / MARIADB	TCP port reachable	db.example.com:3306
MONGODB / MONGO	TCP port reachable	mongo.example.com:27017
POSTGRES / POSTGRESQL	TCP port reachable	db.example.com:5432
GRPC	TCP port reachable	grpc.example.com:50051

YELLOW threshold

A check returns YELLOW (degraded) if:

• TCP checks: connection succeeds but takes > 1000ms
• Redis check: ping succeeds but takes > 500ms
• HTTP checks: response received but takes > 1000ms

---

Creating services (monitoring endpoints)

POST /api/v1/services
Authorization: Bearer <token>
Content-Type: application/json

{
  "name": "Production Database",
  "endpoint": "db.yourapp.com:5432",
  "check_type": "POSTGRES",
  "check_interval_seconds": 120,
  "timeout_seconds": 10,
  "environment": "production"
}

See the Services API → for the full reference.

---

Service configuration reference

Field	Default	Notes
check_interval_seconds	60	How often to run a check
timeout_seconds	10	Max time allowed before RED
environment	—	Label: production, staging, etc.
tags	[]	JSON array of string tags

---

Specialized monitor types

• HTTP / HTTPS → — Status codes, TLS, response time
• TCP / UDP → — Raw port checks, protocol banners
• DNS → — DNS resolution checks
• SSL Certificates → — TLS expiry monitoring
• Heartbeat → — Cron job and background worker monitoring
• Multi-Step → — Chained workflow checks

---

Scheduler details

The scheduler is a separate binary (cmd/scheduler) that:

• Polls the database every 10 seconds for services due for a check
• Runs checks concurrently (controlled by CONCURRENCY env var, default: 100)
• Writes check results back to PostgreSQL
• Evaluates alert rules and creates alert incidents as needed