> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usestealth.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Incident lifecycle

> How an incident opens, gets worse and is resolved, and which events each step sends.

An incident follows one drop from the moment Stealth detects it until the numbers are back to normal. Each step sends an event, and the [alert rules](https://docs.usestealth.dev/en/alerts/overview.md) decide who hears about it.

## How it works

### Events

| Event | Name in the dashboard | When |
| - | - | - |
| `opened` | **New drop** | A rule fires and no incident of the same kind is open for the same ad unit or client. |
| `escalated` | **Drop got worse** | The severity of an open incident goes up. |
| `resolved` | **Back to normal** | The incident is resolved. |

There is at most one open incident per kind for each ad unit or client. While it is open, new hours of the same drop update it instead of opening another one, and the estimated loss keeps adding up.

When an incident starts below the organization's **Minimum severity** (or a webhook's) and later gets worse and crosses it, it is delivered as **New drop**, because it is the first time anyone hears of it.

### Resolved, hourly kinds

An hourly incident is resolved in one of two ways:

* **Back to normal**: 2 evaluated hours in a row at **80% of normal or more**, beyond the market.
* **Quiet**: 24 evaluated hours in a row without the drop, even if the numbers did not fully recover.

An hour that is neither a drop nor healthy restarts the count of healthy hours. Hours that could not be evaluated, for example while Google Ad Manager data was missing, do not count, so an outage on the data side never resolves an incident by itself.

### Resolved, daily kinds

A daily incident is resolved at the next daily evaluation in which its rule no longer fires.

### After resolution

If the same drop happens again later, Stealth opens a new incident with a new identifier.

### Monitoring turned off

When you turn off a network or client that has open incidents, those incidents keep being followed until they are resolved. Their updates reach the in-app notifications and webhooks, but no email.

## What you see

* **Status** on the [Incidents](https://docs.usestealth.dev/en/screens/incidents.md) page: **Open**, **Seen** (someone chose **Mark as seen**) or **Resolved**.
* **Estimated loss**: the total of the incident so far. In a **Back to normal** email or webhook, the loss per hour is the average over the whole incident.
* **Started**: the first hour of the drop, not the hour Stealth detected it.

## FAQ

> [accordion] Does marking an incident as seen stop its alerts?
>
> No. **Seen** tells the team someone is looking at it. Detection and alerts go on until the incident is resolved.

> [accordion] Why did an incident resolve while revenue is still low?
>
> Either 2 hours were back to 80% of normal, or 24 evaluated hours passed without the drop rule firing. A level that is low but stable can stop being a drop by the rule's definition. Check the [Panel](https://docs.usestealth.dev/en/screens/panel.md) and the client page to compare with the market.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.