Skip to content

Incident Lifecycle

Incidents move through configurable statuses so teams share a single source of truth from detection to closure.

Typical lifecycle

Section titled “Typical lifecycle”
New → Acknowledged → Investigating → Mitigation in Progress → Resolved → Closed

Your tenant may also use states such as Escalated, Waiting for Vendor, or Waiting for Maintenance Window, depending on ITSM settings.

Working an incident

Section titled “Working an incident”

On the incident detail page (/incidents/:id):

  • Update status via allowed transitions (enforced by tenant workflow rules)
  • Use the timeline for notes and system events
  • Manage assignees and linked assets
  • Open related changes, problems, or post-incident reviews from cross-links when permitted

SLA

Section titled “SLA”

SLA timers depend on policies under Settings → SLA Policies.

PhaseWhat is measured
First responseTime until the incident is acknowledged or actively worked
ResolutionTime until status reaches Resolved

Pause behavior: If your policy enables pause on waiting, clocks may stop while the incident is in a waiting state (e.g. Waiting for Vendor). Check the policy definition when interpreting overdue flags.

Notifications: Approaching breach and breach events are delivered when Notification Settings enable Incident SLA for the tenant and user.

Section titled “Related records”
ActionPurpose
Create ChangeControlled remediation in production
Create ProblemTrack recurring root cause
Post-incident reviewFormal lessons learned after major events
Link VulnerabilityTie to known CVEs

Permissions

Section titled “Permissions”
  • incidents.read — view
  • incidents.update — edit fields and transition where allowed
  • incidents.create — new incidents

See also

Section titled “See also”