These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Incident Response Platform
- Features
- Response activity
Response activity
Keep actions and status notes attached to the incident.
OverviewRecent response events×
Incident Response Platform · Response activity
New
Recent response events
Response events
| Name | Event type | Occurred at | Incident | Responder | |
|---|---|---|---|---|---|
| Event 103 | Page | 04 Oct | INC-1959 | ||
| Event 588 | Acknowledge | 19 Oct | INC-5234 | ||
| Event 266 | Escalate | 27 Oct | INC-1838 | ||
| Event 326 | Mitigate | 03 Oct | INC-8342 | ||
| Event 774 | Resolve | 18 Oct | INC-1245 |
6 of 6 records
Event 103Response events · RE-90612
PageOccurred at04 Oct
IncidentINC-1959
What you can do
Make the response traceable
A responder action and a status update serve different purposes. The action records what a person did, such as acknowledging, escalating, mitigating or resolving an incident. The update records what the team knew or communicated at a point in time. Both link back to the incident, giving the next responder a dated account instead of a loose collection of messages.
The Service Technician can add these records while working. The Service Manager can review the same sequence when coordinating the response. A useful entry names the action or update, records when it occurred and ties it to the right incident and person. The content of an update should be understandable to the next operator who did not attend the live call.
How the work is organized
- Record actions. Add a response event with the incident, responder, event type and occurrence time when a meaningful response step happens.
- Post updates. Add an incident update with its author and time when the team has a material status note.
- Review the sequence. Read events and updates alongside the incident’s opened, acknowledged and resolved times before a handoff or review.
What to agree during setup
Decide when a page, acknowledgment, escalation, mitigation and resolution each deserve an event. Agree whether the occurrence time should reflect the action itself or the time the entry was created. Give responders a short update format covering the current effect, what changed and the next action. Keep a clear distinction between an operational event and a narrative note.
A page event is a record of response work. It does not itself send a page. If the team uses an external paging system, agree how its event identifiers and delivery results will be connected. The incident’s assigned person and the on-call shift should be checked together when the scheduled responder differs from the current working owner.
Check the handoff on an actual case
A Service Technician takes a high-priority incident after another responder’s shift ends. The incoming person reviews the incident summary and service, then reads the recent response events in order. An earlier escalation event explains why a specialist was asked to help; an update explains what investigation remains. The incoming responder can add a new mitigation event and an update when a safe workaround is applied.
The manager later compares that sequence with the incident’s acknowledgment and resolution times. If an update says the service recovered before the recorded resolution time, the manager can ask why the status lagged. The records support that question without turning every note into an automatic status transition.
What your team sees
- Recent response events — Dated responder actions with incident and person beside each entry.
- Incident update history — Narrative updates linked to their incident and author.
Follow the work through
What it keeps track of
Data model- Response events
- Each record logs one action a responder took during an incident, so the team can trace exactly what happened and when.
- Incident updates
- Each record is a status note posted during an incident, used to keep everyone informed as the situation develops.
- Incidents
- Each record is a service disruption being tracked, used to see what's broken, who owns it, and how fast it's fixed.
- People
- Each record is a team member, used to know their role and whether they're available to respond or be assigned work.
Who uses it
Permissions- Service Technician
- , Service Manager
Set up Incident Response Platform your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.