Incident Note Template

Good For

• support handoff
• post-incident review
• change notes
• repeat troubleshooting

How to Use It

1. Symptom: What broke, who saw it, and when it started.
2. Scope: Affected users, systems, sites, services, and networks.
3. Checks: Commands, logs, dashboards, and observations with timestamps.
4. Action: What changed, who approved it, and what risk it carried.
5. Validation: How you proved the issue was fixed or contained.
6. Follow-up: Any cleanup, monitoring, documentation, or prevention work.

Execution Modes

• local

Inputs and Outputs

Inputs

• symptom
• scope
• timeline
• checks
• actions
• validation

Outputs

• operator-notes
• template
• log-file

Command Starter

Example pattern only. Adjust for your environment before running.

## Incident Note
**Start time:**  
**Reported by:**  
**Primary symptom:**  
**Business impact:**  

### Scope
- Users affected:
- Systems affected:
- Sites or network segments affected:

### Checks performed
| Time | Check | Result | Evidence link or note |
|---|---|---|---|
| | | | |

### Actions taken
| Time | Action | Approval or risk note |
|---|---|---|
| | | |

### Validation
- What proved recovery or containment:
- What remains unverified:

### Follow-up
| Task | Owner | Due date |
|---|---|---|
| | | |

Validation

• Another operator can understand the timeline without asking for context.
• The note separates observations from guesses.
• Follow-up tasks are specific and assigned.

Reporting

• Copy the template directly into an incident ticket, chat handoff, or post-incident worksheet.
• Keep evidence links and timestamps close to the check/action rows so another operator can reconstruct the timeline.
• Promote repeated use into an incident operations notes and handoff template pack.

Safety Notes

• Separate observations from assumptions.
• Avoid including secrets or sensitive customer data in reusable templates.