Incident Management
Restore normal service as quickly as possible
KaliaOps offers complete incident management with a 6-status ITIL workflow. SLA is automatically calculated based on priority, with response and resolution times tracked in real-time. Link impacted CMDB items, escalate with one click (hierarchical or functional), and maintain full traceability of all actions.
Overview
An incident is an unplanned service interruption or quality degradation.
Incident management goal
ITIL defines the goal as: Restore normal service as quickly as possible while minimizing user impact.
Difference with other processes
- Incident: Something is broken → restore service
- Problem: Find root cause → prevent recurrence
- Change: Planned modification → manage risks
Incident examples
- Application inaccessible
- Network performance degraded
- Server crashed
- User unable to log in
- Critical data unavailable
Creating an incident
Access the Incidents module
Menu ITSM → Incidents.
Click "New incident"
Open the creation form.
Describe the incident
Fill in:
- Title: Clear and concise summary
- Description: Symptoms, context, observations
- Category: Hardware, Software, Network, Access, Other
Set priority
Select priority based on urgency and impact:
- Critical: Major business impact, no workaround
- High: Significant impact, limited workaround
- Medium: Moderate impact, workaround available
- Low: Minor impact, no urgency
Add affected items (optional)
Link impacted CMDB items:
- Affected assets
- Impacted applications
- Affected users/clients
Submit
The incident is created with "New" status. SLA clocks start.
Workflow and statuses
Available statuses
| Status | Description |
|---|---|
| New | Incident submitted, awaiting handling |
| Assigned | Assigned to a technician or team |
| In Progress | Currently being worked on |
| Pending | Waiting for information or third party |
| Resolved | Solution applied, awaiting confirmation |
| Closed | Incident completed and validated |
Standard workflow
NEW → ASSIGNED → IN_PROGRESS → RESOLVED → CLOSED
↓
PENDING (waiting) → IN_PROGRESSAutomatic transitions
- NEW → ASSIGNED: When a technician takes ownership
- RESOLVED → CLOSED: After user validation or timeout
Priority and SLA calculation
Automatic SLA
At incident creation, KaliaOps calculates due times based on priority:
| Priority | Response time | Resolution time |
|---|---|---|
| Critical | 1 hour | 4 hours |
| High | 4 hours | 8 hours |
| Medium | 8 hours | 24 hours |
| Low | 24 hours | 72 hours |
SLA clock
- Response due: Time by which a technician must take ownership
- Resolution due: Time by which the incident must be resolved
SLA indicators
- Green: Within SLA
- Orange: Approaching SLA (warning)
- Red: SLA breached
Business hours
SLA can be configured to count only business hours (see SLA configuration).
Severity and impact
Severity
Technical severity of the incident:
| Severity | Description |
|---|---|
| Critical | Total failure, no workaround |
| Major | Severe degradation, limited workaround |
| Moderate | Partial degradation, workaround available |
| Minor | Minor issue, full workaround |
Impact (ITIL 4 model)
Impact on business and users:
| Impact | Scope |
|---|---|
| Enterprise | Entire organization affected |
| Multi-client | Multiple clients or departments |
| Single client | One client or department |
| Single user | Individual user affected |
Priority matrix
Priority is determined by combining severity and impact:
- Critical severity + Enterprise impact = Critical priority
- Moderate severity + Single user impact = Low priority
Linking CMDB items
Link impacted CMDB items for better tracking and analysis.
Linkable entities
- Assets: Servers, network equipment, workstations
- Applications: Impacted business applications
- Employees: Affected users
- Clients: External clients impacted
Creating a link
- Open the incident
- Go to "Affected Items" section
- Click "Link asset/application"
- Search and select the item
Automatic links
Some links are created automatically:
- Assets from the reporter's equipment
- Applications mentioned in the description
Benefits
- Impact analysis: Know exactly what's affected
- Statistics: Assets with most incidents
- Problem detection: Recurring incidents on same item
Assignment and handling
Assignment
An incident can be assigned to:
- A technician: Specific individual
- A team: Group handles dispatch
Taking ownership
- Open an unassigned incident
- Click "Take ownership"
- Status changes to "Assigned"
- Response SLA is met
Reassignment
If the incident needs another person:
- Click "Reassign"
- Select new assignee or team
- Add a note explaining the transfer
Internal/external comments
- External: Visible to the reporter
- Internal: Visible only to IT team
Escalation
Escalation ensures incidents get proper attention when needed.
Escalation types
- Hierarchical: Escalate to management for priority/resources
- Functional: Escalate to specialized team for expertise
Hierarchical escalation
Use cases:
- Incident exceeding SLA
- Need additional resources
- Critical business impact requiring management attention
Functional escalation
Use cases:
- Need specialized expertise (DBA, security, etc.)
- Cross-team issue
- Requires access to specific systems
One-click escalation
- Open the incident
- Click "Escalate"
- Select escalation type
- Add notes
- Submit
Notification is sent to escalation target.
Resolution and closure codes
Resolving an incident
- Apply the solution
- Click "Resolve"
- Enter resolution notes
- Select closure code
- Status changes to "Resolved"
Closure codes
| Code | Description |
|---|---|
| Fixed | Problem corrected |
| Workaround | Temporary solution applied |
| User educated | User training/guidance provided |
| Cannot reproduce | Issue not reproducible |
| No fix needed | Issue resolved itself |
| Duplicate | Duplicate of another incident |
Confirmation and closure
- Reporter receives notification of resolution
- Reporter can confirm or reopen
- After confirmation or timeout, status moves to "Closed"
History and audit
Complete history
Every incident maintains a full timeline:
- Creation: Who, when, original details
- Status changes: Each transition logged
- Assignments: Who handled it, when
- Comments: All communications
- Escalations: Type, target, reason
- Resolution: Notes, closure code
Recorded information
For each action:
- User who performed it
- Timestamp
- Before/after values (for changes)
- IP address
Accessing history
- Open the incident detail page
- Click "History" tab
- View the event timeline
Use cases
- Post-incident review
- Audit and compliance
- Performance analysis
- Training material
- Complete ITIL workflow with 6 statuses
- Automatic SLA based on priority (response + resolution)
- ITIL 4 impact model (Service Consumer)
- Automatic linking with impacted CMDB items
- One-click escalation (hierarchical or functional)
- Full traceability of every action