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

# Incident lifecycle

Every incident on Spike moves through a defined set of stages. Understanding this flow helps you configure escalation policies, acknowledge timeouts, and alert channels to match how your team actually responds.

<figure><img src="/files/JkOVAh1SOb1ylO2qCLlG" alt="Incident lifecycle on Spike"><figcaption><p>The stages of an incident on Spike.</p></figcaption></figure>

## 1. Incident creation

An incident is created when a connected integration sends a webhook to Spike. Before creating a new incident, Spike checks whether an open incident already exists for that integration.

* If one exists, Spike logs the new event under the existing incident instead of creating a duplicate.
* If no open incident exists, Spike creates a new one and starts the escalation process.

{% hint style="info" %}
Only open incidents (triggered or acknowledged) are checked for duplicates. Resolved incidents are ignored.
{% endhint %}

## 2. Incident escalation

Once an incident is created, Spike works through the [escalation policy](/escalations/introduction-to-escalations.md) attached to that integration. Alerts go out to the first set of responders in the policy. Spike waits for the duration configured in the escalation policy. If no one acknowledges or resolves the incident in that time, Spike moves to the next level and alerts the next set of responders.

Each integration can have its own escalation policy. This lets you set different alert priorities across services.

## 3. Incident acknowledgment

When a responder acknowledges the incident, Spike pauses the escalation policy and stops escalating alerts. You can set an [acknowledge timeout](/incidents/acknowledge-timeout.md) for each integration: a time limit that moves the incident back to triggered and resumes alerting if it hasn't been resolved in time.

## 4. Incident resolution

Once the issue is fixed, mark the incident as resolved. Spike stops all alerts and resets the escalation policy. If a new incident comes in for the same integration, the process starts again from the beginning.

See [incident statuses](/incidents/incident-statuses.md) for a full reference on each status.


---

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

```
GET https://docs.spike.sh/incidents/incident-lifecycle.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.
