API Reference

Alerts Endpoint

Query firing alerts, acknowledge, resolve — integrate with your incident response tooling.

GET /api/v1/alerts

List alert instances (the fires, not the rules — see /api/v1/alerts/rules for definitions). Scope: read:alerts.

Filter params:

  • status=firing|resolved|acknowledged|all — defaults to firing.
  • severity=info|warning|critical
  • server_id=<id> — narrow to one server.
  • since=<ISO-8601> — only triggered after this time.
{
  "data": [
    {
      "id": "rh_xyz",
      "rule_id": 42,
      "rule_name": "Replication lag > 60s",
      "server_id": 4,
      "severity": "warning",
      "status": "firing",
      "metric_value": 127,
      "threshold": 60,
      "triggered_at": "2026-04-24T19:45:12Z",
      "resolved_at": null,
      "acknowledged_at": null,
      "notified": true
    }
  ]
}

POST /api/v1/alerts/:id/acknowledge

Mark an alert as acknowledged. The rule keeps evaluating, but notifications stop until status changes. Scope: write:alerts.

{ "note": "investigating — see OPS-1234" }

POST /api/v1/alerts/:id/resolve

Force-resolve. Use when the underlying condition is fixed but the rule hasn't auto-detected yet — shouldn't happen often but does. Scope: write:alerts.

GET /api/v1/alerts/rules

List rule definitions, not fires. Scope: read:alerts.

PagerDuty bidirectional sync

If your oncall acknowledges in PagerDuty, you want MonPG to reflect that — otherwise the next page about the same condition wakes someone up twice. Hook PD's outbound webhook to call MonPG's acknowledge:

curl -X POST   -H "Authorization: Bearer $MONPG_KEY"   -H "Content-Type: application/json"   -d '{"note":"acked from PagerDuty by $incident.assignee"}'   https://api.monpg.app/api/v1/alerts/$incident.body.alert_id/acknowledge