Alerts
The on-call surface — incidents that flow firing → acknowledged → resolved, and the alert rules that raise them.
Alerts is proxifai’s on-call surface. It lives at /alerts with two tabs: Incidents and Rules.
Incidents
An incident represents something that needs attention. Incidents have a severity and move through a simple lifecycle:
firing → acknowledged → resolved
From the Incidents tab you can filter by status (Firing / Acknowledged / Resolved / All), acknowledge an incident to signal you’re on it, and resolve it when it’s handled. Incidents are attributed to a service (service_id), so with a service in scope the list narrows to that service’s incidents.
# authenticated incident surface (mounted when on-call is enabled)
GET /api/v1/oncall/incidents
POST /api/v1/oncall/incidents/{id}/ack
POST /api/v1/oncall/incidents/{id}/resolveAlert rules
The Rules tab is where you define what raises an incident. Rules were previously grouped under Insights; they now live with the incidents they create, under Alerts.
Where incidents come from
Incidents are raised by both internal rules and external signals. proxifai ingests alerts through public webhooks (outside the authenticated API because the senders are external systems):
- Alertmanager — Prometheus/Mimir-based alerting forwards firing/resolved alerts.
- Twilio — inbound voice/SMS callbacks for escalation.
- Common observability vendors (Datadog, Sentry, PagerDuty) via the integrations catalog.
Incoming alerts are attributed to the right service by matching their labels, so an alert from your metrics stack lands on the same service you see everywhere else in the app.
On-call notifications also appear in the Inbox with inline acknowledge/resolve actions, so you can triage without opening the Alerts page.