Alerting Overview

AlertifyPro automatically evaluates alert rules after every check result. When a service check returns RED (failed) or YELLOW (degraded), matching alert rules fire and create alert incidents.

How it works

Scheduler runs check (every N seconds)
    ↓
Check result: GREEN / YELLOW / RED
    ↓
Alert rules evaluated for this service
    ↓  (if rule matches)
Alert incident created
    ↓
Notification channels fire (Slack, email, PagerDuty, SMS, ...)
    ↓
Alert stays open until acknowledged or resolved

---

Alert status lifecycle

Status	Meaning
firing	Alert created, not yet acknowledged
acknowledged	Team member has acknowledged the alert
resolved	Alert manually resolved or service recovered

---

Check statuses that trigger alerts

Check status	When it fires
RED	Connection refused, server error, timeout, bad response
YELLOW	Service responded but response time > 1000ms

Both RED and YELLOW results trigger matching alert rules.

---

Alert rules

Alert rules define what to alert on and how severe it is. Rules are linked to a specific service.

Create an alert rule

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

{
  "service_id": "550e8400-e29b-41d4-a716-446655440000",
  "name": "API Down",
  "severity": "critical",
  "condition": {}
}

Field	Type	Required	Description
service_id	UUID	optional	Scope to a specific service
name	string	✅	Rule display name
severity	string	✅	critical, warning, info
condition	object	optional	Condition config (extensible JSON)

List alert rules for a service

GET /api/v1/alert-rules?service_id={service_uuid}

---

Active alerts

List all active alerts

GET /api/v1/alerts
Authorization: Bearer <token>

Response:

[
  {
    "id": "alert-uuid",
    "organization_id": "org-uuid",
    "service_id": "service-uuid",
    "service_name": "Production API",
    "alert_rule_id": "rule-uuid",
    "severity": "critical",
    "title": "API Down Triggered by Check",
    "message": "Check failed with status RED",
    "status": "firing",
    "fired_at": "2026-03-02T14:23:00Z",
    "acknowledged_at": null,
    "acknowledged_by": null,
    "resolved_at": null,
    "resolved_by": null
  }
]

Get a specific alert

GET /api/v1/alerts/{id}

Acknowledge an alert

POST /api/v1/alerts/{id}/acknowledge
Authorization: Bearer <token>

Sets status to acknowledged and records the acknowledged_by user UUID.

Resolve an alert

POST /api/v1/alerts/{id}/resolve
Authorization: Bearer <token>

Sets status to resolved and records the resolved_by user UUID.

---

Notification channels

Notifications are sent via notification channels — configured separately from alert rules.

Supported channel types: slack, email, webhook, pagerduty, sms

Create a notification channel

POST /api/v1/notification-channels
Content-Type: application/json

{
  "name": "Slack #ops",
  "channel_type": "slack",
  "config": {
    "webhook_url": "https://hooks.slack.com/services/XXX/YYY/ZZZ"
  }
}

POST /api/v1/notification-channels
Content-Type: application/json

{
  "name": "PagerDuty Critical",
  "channel_type": "pagerduty",
  "config": {
    "integration_key": "your-pagerduty-routing-key"
  }
}

POST /api/v1/notification-channels
Content-Type: application/json

{
  "name": "On-call SMS",
  "channel_type": "sms",
  "config": {
    "to": "+15551234567"
  }
}

Email channel

Requires SMTP configured in environment variables (SMTP_HOST, SMTP_PORT, etc.):

{
  "name": "Engineering Email",
  "channel_type": "email",
  "config": {
    "to": "[email protected]"
  }
}

List / delete channels

GET    /api/v1/notification-channels
DELETE /api/v1/notification-channels/{id}