# During Incident

When systems fail, the **speed and quality of your communication** matter as much as the fix itself. Customers will forgive downtime more easily than silence. This section outlines how to communicate clearly, consistently, and credibly throughout an active incident.

***

## Know who and how to notify

If you followed our previous chapter [Preparation](/old-2-incident-communication-handbook/preparation.md), you should have the following in place:

1. List of Stakeholders documented and how they should be contacted.
2. PR-approved messaging templates, organized by severity.
3. Communication channels in place.

{% hint style="warning" %}
To view the full list, please follow our [Preparation](/old-2-incident-communication-handbook/preparation.md) chapter if you haven't already.
{% endhint %}

## Communicate during the incident lifecycle 

### **Acknowledge**

When something breaks or customers report an issue, acknowledge the incident quickly (≤ 10–20 min depending on severity). There is no need to wait until the issue has been identified; you can report it as "under investigation".

If the incident is still "under investigation", you may opt to communicate it only via your status page instead of sending notifications (SMS, email, Slack) at this point.

Ensure that you share what’s known: impact, affected services, start time (if known), and commit to the next update.

### **Update regularly**

* Provide facts only (scope, impact, current actions).
* Communicate clearly when progress is made in the incident lifecycle (e.g., identified → monitoring).
* Update regularly based on severity.
  * Even if there is no progress since the previous update, a simple "Our team continues to investigate" goes a long way.
* Adjust audience if scope changes (e.g., regional → global impact).

{% hint style="info" %}
Make sure to honor the cadence you define under [Preparation](/old-2-incident-communication-handbook/preparation.md#define-update-cadence).
{% endhint %}

### **Resolve**

When the issue is resolved, communicate this clearly and concisely. Provide the impact window, including start and end times, and outline any next steps, such as ongoing monitoring or an upcoming root cause analysis. Direct customers to support if they continue to experience issues.


---

# Agent Instructions: 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:

```
GET https://docs.statuspal.io/old-2-incident-communication-handbook/during-incident.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.