Incidents
An incident represents a problem that needs attention — a server going down, an alert from a monitoring tool, or anything your team pages people about. Every incident belongs to a service, and moves through a set of states as people respond to it.
States
| State | Meaning |
|---|---|
| Triggered | Just created. Oppex is notifying whoever the escalation policy targets. |
| Acknowledged | Someone has taken it and escalation has stopped. |
| Snoozed | Temporarily hidden from view — see Snooze. |
| Assigned | Handed to a specific person. |
| Paused | Escalation is on hold. |
| Resolved | Closed. The problem is fixed. |
For the actions that move an incident between these states, see Handling Incidents — acknowledging, resolving, snoozing, muting, escalating, and reassigning are all covered there.
Muting silences an incident's notifications without changing its status — it shows up as an event on the incident's timeline, not as a state in this table.
How an incident is created
- From an integration. A connected monitoring tool (New Relic, Site24x7, GroundCover, Amazon CloudWatch, Grafana, Slack, or a generic webhook) sends an alert, and Oppex creates the incident automatically.
- Via the API. Your own systems can post to Oppex's incident API using a service's integration key.
- Manually. Click Create Incident on the Incidents page. It goes through the exact same path as an API-created incident, just attributed to you instead of an integration.
Every incident is routed to a service, and that service's escalation-by-severity mapping decides who's notified.
Repeated alerts
Oppex doesn't just deduplicate identical alerts — it can group related alerts together under one incident using rules you configure. See Grouping strategy and Routing Incidents.