Incidents

Incidents are opened and resolved automatically as your monitors' and VPS servers' statuses change — you don't create them directly, only read and acknowledge them.

Incident types

down	monitor	A protocol on a probe went from up to down (or failed on its very first check).
degraded	monitor	Connected, but performance crossed a degraded threshold (latency/packet loss).
ip_mismatch	monitor	Connected, but the exit IP doesn't match expected_exit_ip.
flapping	monitor	3+ status changes within an hour on the same (protocol, probe) — held as one ongoing incident instead of opening/closing repeatedly.
resource_cpu_high / resource_memory_high / resource_disk_high	vps	A VPS threshold (see Custom Probes & VPS) was breached for its configured sustained duration.
vps_offline	vps	The VPS agent stopped reporting in.

When incidents open and resolve

Incidents are tracked per (monitor, protocol, probe) — a single monitor with 3 enabled protocols checked from 5 probes tracks up to 15 independent incident lines, so one failing protocol/probe never hides another’s healthy state.

up → down opens a down incident.
down → up resolves the open down or ip_mismatch incident for that exact triple.
An IP mismatch opens an ip_mismatch incident immediately, independent of up/down.
While flapping is detected, a single incident is kept open rather than oscillating.

A maintenance window covering a monitor suppresses this entirely — while active, no incident is opened OR resolved for it, so a status flap during the window leaves no record at all. See Maintenance Windows.

If 2+ incidents open within 2 minutes on monitors sharing the same probe, they’re linked by a shared correlation id and a single incident.correlated webhook event fires instead of separate incident.created events — useful for not paging your team 5 times for one probe-side network blip.

GET/incidents

List Incidents

Auto-tracked status transitions on your monitors and VPS servers — outages, degradations, IP mismatches, flapping, and resource threshold breaches.

Query Parameters

status	string	`open` or `resolved`.
type	string	`down`, `degraded`, `ip_mismatch`, `flapping`, `resource_cpu_high`, `resource_memory_high`, `resource_disk_high`, `vps_offline`.
project_id	integer	Also narrows the `counts` summary.
monitor_id	integer	Also narrows the `counts` summary.
vps_server_id	integer	Also narrows the `counts` summary.

Notes

•Incidents are scoped per (monitor, protocol, probe) — one protocol or probe failing never masks another's healthy state on the same monitor.
•While a maintenance window covers a monitor, no incident is opened OR resolved for it at all — a status flap during the window leaves no record.
•If 3+ status changes happen within an hour on the same (protocol, probe) pair, a single ongoing `flapping` incident is used instead of opening/closing repeatedly.
•If 2+ incidents open within 2 minutes on monitors sharing the same probe, they're linked by a shared correlation and a single `incident.correlated` webhook event fires instead of separate `incident.created` events.
•List capped at 200 rows, newest first.

Example Request

curl -X GET "https://api.exitprobe.com/api/v1/incidents" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Accept: application/json"

Example Response

{
  "success": true,
  "data": {
    "incidents": [
      {
        "id": 501, "monitor_id": 42, "monitor_name": "US-East WG1", "monitor_protocol": "wireguard",
        "protocol": "wireguard", "probe_id": 7, "probe_name": "Frankfurt-1", "probe_location": "Frankfurt",
        "project_id": 3, "project_name": "Default Project",
        "vps_server_id": null, "vps_server_name": null,
        "type": "down", "status": "open", "previous_status": "up",
        "reason": "Connection timed out",
        "started_at": "2026-09-26T00:00:00Z", "resolved_at": null, "acknowledged_at": null,
        "duration_seconds": 184
      }
    ],
    "counts": { "active": 3, "down": 1, "needs_attention": 2, "recovered": 40 }
  }
}

POST/incidents/{id}/acknowledge

Acknowledge Incident

Marks an open incident as acknowledged (records `acknowledged_at`). Only open incidents can be acknowledged.

Notes

•422 "Only open incidents can be acknowledged." if the incident is already resolved.

Example Request

curl -X POST "https://api.exitprobe.com/api/v1/incidents/{id}/acknowledge" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Accept: application/json"

Example Response

{ "success": true, "message": "Incident acknowledged.", "data": { "incident": { "id": 501, "status": "open", "acknowledged_at": "2026-09-26T00:03:00Z" } } }

VMess

Escalation Policies