> ## 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 page > What one incident cost, what Stealth found around it, and what to check next. Each incident has its own page. It gathers in one place what the team would otherwise piece together from several screens: how much the incident cost, what the numbers did, whether it follows the market, the possible causes with their evidence and what to check next. Open it by clicking the type of an incident in [Incidents](https://docs.usestealth.dev/en/screens/incidents.md) or in the client page, or from the link in an alert email about a single incident. If the incident belongs to another organization you are a member of, the dashboard switches to it. ## What you see The title is the type of the incident. Under it are the scope (the ad unit, or the whole client), the client and the network, with the severity and the status. At the top right: * **Mark as seen**, on an open incident, as in [Incidents](https://docs.usestealth.dev/en/screens/incidents.md#mark-as-seen). * **Copy summary for support** copies a plain text summary to paste in a ticket or a chat. It has the scope, the start, the estimated loss, the reading, the possible causes and the link. * **Open in Ad Manager** opens the ad unit, or the network when the incident covers the whole client. ### Key numbers | Card | What it shows | | - | - | | **Started** | The start of the first hour with the drop, in the organization's time zone. | | **Duration** | The time from the start until the incident was resolved, or until now while it is open. | | **Estimated loss** | Expected revenue minus real revenue during the incident, after discounting what the whole portfolio lost in the same hours. It carries the **Estimated** badge. | | **Projected per Day** | The loss per day if the drop continues at the current rate. Shown while the incident is open. | ### What Happened A chart of what the ad unit or the client delivered (**Observed**) against what was normal for the same hour in the previous weeks (**Expected**). It starts 24 hours before the incident and goes on until 24 hours after it was resolved, or until now. Daily types compare each day with the same weekday of previous weeks. The metric follows the type: requests per hour for the traffic types, fill rate per hour for the fill types, revenue per day for the two revenue types. A line marks the start of the incident, and a marker shows each change made in Google Ad Manager (GAM) in that period. The **Expected** line does not discount the market, but the estimated loss does, so the gap in the chart can be larger than the loss. When there is not enough history, the chart says so instead of drawing a line. ### Market or Client Tells whether the drop follows the market or belongs to this client. For revenue types, a table compares each demand source with what was expected and shows how much of its fall is the market and how much is this client's own. For the other types, one sentence states the rule that opened the incident, such as that the rest of the client kept its traffic, so the drop is specific to the ad unit. When there is not enough demand history, the card says so. ### Possible Causes A short list, up to 5 causes, ranked by how likely they are. Each one shows its evidence: for a change in GAM, the fields before and after, who made it and when, with **View change** and **Open in Ad Manager**. The types are: * **GAM change**: a change to one of the incident's own ad units in the 24 hours before it started, or in its first hour. * **Demand source**: the source whose own revenue fell the most, for revenue types. * **Traffic**: requests stopped arriving, which usually points to the site. Possible causes are estimates, not proof: the card carries the **Estimated** badge. Only changes to the incident's own ad units count. Stealth does not know which ad units a line item or an order reaches, so those are never ranked here. When nothing is found, the card lists what was checked and says nothing was found. More than 5 causes show a note with how many are hidden. ### Other signals in the network A collapsed block under the possible causes, with a count such as **3 other signals in the network**. It lists, newest first and up to 10, the changes made on the same network that are not on the incident's ad units, with **View in Activity** to see them all. While the incident is open, it also lists the line items of the network flagged as not delivering, ending soon below goal, behind pace or missing creatives. These cover the whole network, not only this ad unit, and are never possible causes. ### Next Steps A short checklist, up to 5 lines, for the type of the incident, plus one line for the main possible cause, such as reviewing a change and who made it. The last line asks the team to record the verdict. ### Verdict Where the team records what really caused the incident, to compare with Stealth's reading. Any member of the organization can set it or change it. | Field | What it holds | | - | - | | **Cause** | **Market**, **GAM configuration**, **Client site**, **Stealth bug** or **False alarm**. | | **Which possible cause** | Optional. One of the possible causes shown, **None of these** or **Not specified**. | | **Note** | Optional, up to 500 characters. | Choose **Save verdict**. The page then shows who recorded it and when. **Clear verdict** removes it. The verdict also appears in [Incidents](https://docs.usestealth.dev/en/screens/incidents.md) and in the client page, next to the reading. Each change to a verdict is recorded in the **Stealth** tab of [Activity](https://docs.usestealth.dev/en/screens/activity.md). ### Older types Incidents of types from earlier versions of the detection, such as **Revenue zeroed**, show only the header, the key numbers and the verdict. ## FAQ > [accordion] Is a possible cause the real cause? > > No. It is a coincidence in time, found in data Stealth already reads. Use it as the first place to look, and record the verdict once you know. > [accordion] Why is a change on the network not listed as a possible cause? > > Stealth does not know which ad units a line item, an order or another network change reaches. To keep the list trustworthy, only changes to the incident's own ad units are ranked. The rest is under **Other signals in the network**. > [accordion] Why are there no line items on a resolved incident? > > Line item signals describe the network now, not when the incident happened, so they appear only while the incident is open. > [accordion] Does Stealth change anything in Google Ad Manager? > > No. Stealth only reads. The links open Google Ad Manager so you can check and fix things yourself. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.