> For the complete documentation index, see [llms.txt](https://support.incidentlake.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.incidentlake.com/incidents/work-an-incident.md).

# Work an incident

How to update status, tasks, reports, and response times while an incident is open.

The incident page is where the team keeps a single, current picture of the response.

## Keep the header current

At the top of the page you can:

* Rename the incident
* Change **status** (resolve, reopen, mark stalled, and so on)
* Set **severity** and **category**
* Assign or change the **Incident Commander** — Incident Lake keeps a history of who held the role

## Summary, timeline, and postmortem

These three sections are the narrative of the incident.

* **Summary** — what is going on, in language a stakeholder can read
* **Timeline** — what happened, in order
* **Postmortem** — what you learned after the incident

You can write them yourself or ask Incident Lake to draft an update from the conversation and notes already attached to the incident. Review every draft before you treat it as published.

{% hint style="warning" %}
A draft is not finished work. Read it, correct anything that is wrong, then save.
{% endhint %}

## Tasks

Use **Tasks** for the work that still has to happen — investigate, communicate, mitigate, follow up.

* Add tasks by hand, or start from a workflow template
* Assign an owner and a due date
* Update progress from the incident page, and from Slack when your account is linked

Completing a task may ask for a short completion note. That note becomes part of the incident history.

## Response times

Response times answer “how long did each stage take?” Typical marks include when the issue **occurred**, was **detected**, when response **started**, when a **temporary** fix landed, and when a **permanent** fix landed.

You can enter times yourself or ask Incident Lake to detect them from the summary, timeline, postmortem, notes, and linked Slack or Teams messages. When sources disagree, you choose which source should win.

These times feed [Incident Analytics](/everyday-tools/analytics.md) (time to temporary response, time to permanent response, and similar measures).

## Other sections you will use

| Section                          | Use it for                                                            |
| -------------------------------- | --------------------------------------------------------------------- |
| **Affected configuration items** | Link the services or systems from your CMDB                           |
| **Action items**                 | Follow-up work after the immediate response                           |
| **Similar incidents**            | Past cases that look like this one                                    |
| **Notes**                        | Working notes and images that are not yet part of the published story |
| **Communication**                | Status-page drafts and stakeholder messages                           |
| **Related resources**            | Tickets, documents, and other records from connected tools            |
| **Notifications**                | Who was notified and what was sent                                    |
| **Evidence**                     | Supporting material you want on the record                            |

## Access and relationships

Some organizations restrict who can see an incident with access tags (shown as **RBAC tags** in organization settings). Administrators manage those tags on the organization.

You can also **link** or **merge** related incidents when two records describe the same event. Merged incidents drop out of analytics.

## When you are done

1. Confirm tasks that belong to the live response are done or moved to follow-up
2. Set status to **Resolved** (or **False Positive** / **Cancelled** when that is accurate)
3. Finish the postmortem
4. If a knowledge draft appears from the published report, review it in **Knowledge** so the next similar incident starts with that lesson


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://support.incidentlake.com/incidents/work-an-incident.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.