Incident management

An incident is the operational record for a service disruption or other issue that needs coordinated response. It connects the alert, responders, service, escalation state, response timeline, communications, and follow-up work.

Use this guide for work in the OpsKnight interface. For supported automation, see the Incidents API and Events API.

Before you begin

You must be signed in to view incidents.
A Responder or Admin can create and change incidents. A User has read-only access to incident response controls.
Create the affected service first. Assign an escalation policy to the service if the incident should page responders.
Configure integrations and notification providers before relying on them during a real incident.

Incident lifecycle

Status	Meaning	Escalation behavior
Open	Response is required.	The service policy can continue escalating.
Acknowledged	A responder has taken ownership.	The active escalation is completed.
Snoozed	Response is paused temporarily.	Escalation is paused until the incident is returned to Open. A timed snooze can reopen automatically.
Suppressed	The incident is intentionally muted.	Escalation is paused until the incident is unsuppressed.
Resolved	Response is complete.	Escalation is completed and resolution time is recorded.

Returning a resolved incident to Open reopens it. Status changes are recorded in the timeline and may notify configured service channels, status-page subscribers, and webhooks.

Create an incident

Open Incidents and select Create incident.
Enter a concise title and optional description.
Select the affected service.
Choose High, Medium, or Low urgency.
Optionally select priority P1–P5, an individual assignee or team, and public or private visibility.
Review any duplicate warning and submit the incident.

You can start from an incident template. Templates prefill common fields but do not bypass validation or routing.

OpsKnight uses the event deduplication key for integration-created incidents. A matching active incident is reused; a recently resolved matching incident can be reopened. Treat the integration key and deduplication key as separate values: the integration key authenticates and routes the event, while the deduplication key identifies the alert condition.

Public and private incidents

Public visibility makes the incident eligible for display through the configured status page. Private keeps it out of public incident views. Visibility alone does not publish a postmortem or override status-page privacy settings.

Find and triage incidents

The Incidents page displays 50 records per page and provides counts for Mine, Open, Resolved, Snoozed, and Suppressed.

Use the controls to:

search incident title, description, or identifier;
filter by status, priority, urgency, team, or incidents assigned to you;
sort by creation time, title, priority, urgency, or status;
select incidents for supported bulk operations.

Bulk controls can acknowledge, resolve, reassign, change status, change urgency or priority, snooze, unsnooze, suppress, or unsuppress selected incidents. Confirm the selection before applying an action: bulk changes update every selected record and can trigger downstream notifications.

Respond from the incident page

Open an incident to see its service, current owner, status, urgency, priority, SLA state, escalation state, notes, timeline, tags, watchers, custom fields, and connected response tools.

Acknowledge and assign

Select Acknowledge when you take responsibility.
Assign the incident to one active user or one team when ownership changes.
Check the escalation badge and next-step information.

An incident has either an individual assignee or a team assignment. Acknowledgement records acknowledgedAt, which is used for MTTA and acknowledgement-SLA calculations.

Set urgency and priority

Urgency is High, Medium, or Low and affects response attention and notification behavior.
Priority is an optional business-impact classification from P1 through P5.

They are separate fields. If priority-specific SLA targets are configured for the service, OpsKnight uses them; otherwise it uses the service's default acknowledgement and resolution targets. See Urgency and severity mapping.

Add response context

Add notes for decisions, observations, commands run, and handoffs.
Add or remove tags for later discovery.
Set configured custom fields.
Add watchers as follower, stakeholder, or executive participants.
Review the event timeline for recorded status, assignment, escalation, and other changes. It is operational history, not a comprehensive immutable compliance ledger.

Do not place credentials or sensitive customer data in notes, tags, custom fields, or public incident content.

Snooze or suppress

Use Snooze for a temporary pause, ideally with an end time and reason. Use Suppress when the alert should remain muted until a responder explicitly restores it. Both states pause escalation; neither resolves the underlying incident.

After returning the incident to Open, verify that an assignee or escalation path is available.

Use Jira and a Slack war room

When Jira is enabled and the service has a project mapping, the incident page can create a Jira issue, link an existing issue, unlink it, and refresh its state. See Jira integration.

When Slack ChatOps is configured, eligible incidents can have a dedicated war-room channel and video bridge. Resolving the incident can archive the channel while retaining its identifiers for history. See Slack ChatOps.

Resolve and follow up

Confirm service recovery and monitoring stability.
Select Resolve and add a useful resolution note.
Verify the status is Resolved and the resolution time is recorded.
Create or update the postmortem when learning or accountability is required.
Track remediation in action items.

A resolution note should state what changed, how recovery was verified, and any remaining risk. Resolution may notify configured service channels, status-page subscribers, and service webhooks. It also stops active escalation and can archive an associated Slack war room.

Verify the workflow before production use

Run one test incident for each critical service:

Trigger it through the same inbound path production monitoring will use.
Confirm the correct service and urgency.
Confirm the expected user, team, or schedule receives the first notification.
Let a test escalation advance once, then acknowledge it.
Add a note, assign it, and resolve it.
Confirm the timeline, notification history, and any configured status-page or webhook update.

Troubleshooting

No responder is notified

Confirm the service has an escalation policy.
Confirm every policy step has a valid active user, team member, or current on-call schedule participant.
Confirm the intended channel is enabled globally and for the target.
Check Notification History, Event Logs, and system logs for provider errors.

An integration creates duplicate incidents

Use a stable deduplication key for the same alert condition.
Confirm events use the same service integration key.
Check whether the earlier incident was resolved outside the reopen window.

Snoozed or suppressed response does not resume

Return the incident to Open, confirm its escalation state is active, and verify the service policy still has a resolvable target.

The incident does not appear publicly

Confirm the incident is public, the status page is enabled, the service is included, and the status-page privacy controls permit incident details. See Status page.