4 min leitura • Guide 577 of 877
How to Use GitScrum for Incident Management?
How to use GitScrum for incident management?
Manage incidents in GitScrum with high-priority incident tasks, dedicated labels for severity, and rapid response workflow. Track timeline in task comments, coordinate response via Team Standup, and document post-mortems in NoteVault. Structured incident management reduces MTTR by 40% [Source: Site Reliability Research 2024].
Incident workflow:
- Detect - Alert or report
- Create task - Incident with severity
- Triage - Assess and assign
- Investigate - Find cause
- Mitigate - Stop impact
- Resolve - Fix root cause
- Post-mortem - Document learnings
Incident severity labels
| Severity | Impact |
|---|---|
| sev-1 | Full outage, all users affected |
| sev-2 | Major degradation, many users |
| sev-3 | Partial degradation, some users |
| sev-4 | Minor issue, workaround exists |
Incident columns
| Column | Purpose |
|---|---|
| Triage | New incidents |
| Active | Being worked |
| Mitigated | Impact reduced |
| Resolved | Fully fixed |
| Post-Mortem | Review pending |
Incident task template
## Incident: [brief description]
### Status: [Active/Mitigated/Resolved]
### Severity: [SEV-1/2/3/4]
### Incident Commander: [@person]
### Impact
- Services affected: [list]
- Users affected: [count/percentage]
- Revenue impact: [if applicable]
### Timeline
- HH:MM - Detected
- HH:MM - Response started
- HH:MM - Investigation
- HH:MM - Mitigation
- HH:MM - Resolution
### Root Cause
[TBD or description]
### Action Items
- [ ] Follow-up task 1
- [ ] Follow-up task 2
Column subscribers for incidents
| Column | Subscribers |
|---|---|
| SEV-1 incidents | All on-call, management |
| Active incidents | Response team |
| Post-mortem | Team leads |
Timeline tracking
| Entry | Format |
|---|---|
| Detection | "14:23 - Alert triggered: API latency > 500ms" |
| Action | "14:25 - @dev investigating DB connection pool" |
| Mitigation | "14:45 - Restarted service, latency normalized" |
| Resolution | "16:00 - Root cause fixed, deployed" |
Response SLAs
| Severity | Response | Resolution |
|---|---|---|
| SEV-1 | 5 min | ASAP |
| SEV-2 | 15 min | 4 hours |
| SEV-3 | 1 hour | 24 hours |
| SEV-4 | 4 hours | 1 week |
NoteVault post-mortem template
| Section | Content |
|---|---|
| Summary | What happened |
| Timeline | Full sequence |
| Root cause | Why it happened |
| Impact | Business impact |
| Detection | How we found it |
| Response | What we did |
| Lessons | What we learned |
| Action items | What to improve |
Action item tracking
| Step | Action |
|---|---|
| Identify | During post-mortem |
| Create tasks | From action items |
| Link | To incident task |
| Assign | Owners and deadlines |
| Track | Normal workflow |
| Review | Completion in retro |
Incident metrics
| Metric | Definition |
|---|---|
| MTTD | Mean time to detect |
| MTTR | Mean time to resolve |
| Incident count | By severity |
| Recurrence | Same issue repeating |
Common incident issues
| Issue | Solution |
|---|---|
| Slow response | Clear escalation |
| Poor communication | Timeline tracking |
| Repeated incidents | Post-mortem follow-through |
| Missing docs | NoteVault templates |
Incident review cadence
| Review | Frequency |
|---|---|
| SEV-1 post-mortem | Within 48 hours |
| SEV-2 post-mortem | Within 1 week |
| Incident trends | Monthly |
| Process review | Quarterly |