Incident response

Incident Management

Learn how MonoDuty creates, acknowledges, escalates, and resolves incidents, with lifecycle states, audit history, notes, and API examples.

Incident management

An incident belongs to a workspace and an owning team. It may be created by an authorized user or by a configured trigger connected to a Webhook, Heartbeat, Monitor, or service.

Creation records an action and queues the durable operational workflow. Notification timing is not guaranteed: queue state, configuration, external providers, and network conditions all affect delivery.

Incident lifecycle

The supported states are OPEN, ACKNOWLEDGED, INVESTIGATING, RESOLVED, and CLOSED. State changes are validated; invalid transitions return HTTP 422.

FromAllowed next states
OPENACKNOWLEDGED, INVESTIGATING, RESOLVED
ACKNOWLEDGEDINVESTIGATING, RESOLVED
INVESTIGATINGRESOLVED
RESOLVEDCLOSED, OPEN
CLOSEDOPEN

A configured escalation execution stops after acknowledgement or resolution. This does not guarantee that a provider accepted, delivered, or presented every earlier notification.

Manage incidents

Authorized users can list team-visible incidents, create a manual incident, update its title, description or severity, manage sources and assignees, add actions, and perform allowed state transitions through the dashboard. The browser uses its Secure, HttpOnly session cookie and CSRF protection; it does not expose a reusable bearer credential to page JavaScript.

For automation, a Billing Owner or Account Admin on an eligible plan can create a short-lived READ_ONLY or READ_WRITE customer API token from Settings → API tokens. Only the explicit /api/v1/organizations/{organization} allowlist accepts that bearer token. Use the incident-specific /acknowledge, /investigate, /resolve, /close, or /reopen route for a state change. Workspace and team authorization is revalidated on every operation.