> For the complete documentation index, see [llms.txt](https://docs.decube.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decube.io/data-quality-v2/cases/case-details.md).
# Case details
When a monitor run fails, Decube raises an incident and files it under a case. The case details page is where you work that case: what failed and how often, the evidence Decube captured at the moment of failure, who owns it, and where the alerts were sent. Open it from the **Cases** tab, from the Cases tab of a monitor, or from the link in an alert.
{% embed url="" %}
### Incidents and cases
An **incident** is a single failed run. A **case** groups the incidents raised by one monitor configuration, so a problem that recurs across many runs stays as one thing to triage.
* A case opens with its first incident and starts at **Open**.
* Every later failure from that monitor joins the open case and raises its incident count.
* Closing a case ends the grouping. The next failure opens a fresh case, so a problem that returns after you closed it is visible as a new occurrence rather than reviving an old one.
A closed case stops grouping, and the monitor keeps running. Closing a case is a statement about the investigation, and it leaves the monitor's schedule untouched.
### Working through the incidents
The **Incidents** tab lists every incident in the case down the left, most recent first. Selecting one loads its graph and its evidence.
#### The metric graph
The graph plots what the monitor measured over time, with the selected incident's run marked on it. The chart selector switches between the graphs available for this monitor type, the bound line draws the limit the run was judged against, and hatched bands cover runs that errored or were skipped. It behaves the same way as the chart on the [monitor details page](https://decube-org.atlassian.net/wiki/spaces/PRD/pages/379813901), so you can read a single failure in the context of the monitor's normal range.
#### Evidence
Evidence is what Decube captured when it evaluated the run. The cards hold the measurements themselves, and the sentence underneath states in plain terms what the run found and what the monitor required.
Which cards appear depends on the monitor type. **Scheduled at** and **Metric collected at** always come first, and the rest describe what that type of monitor measures.
| Card | What it tells you |
| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Scheduled at** | The time the run was scheduled for. |
| **Metric collected at** | The time Decube actually took the measurement. A small gap after the scheduled time is normal. |
| **Failing rows** | How many rows broke the rule. |
| **Total rows scanned** | How many rows the run looked at, which is the base the failure percentage is calculated from. |
| **Failure percentage** | Failing rows as a share of rows scanned. |
| **Tolerance** | How many failing rows the monitor allows before the run fails, as a count or a percentage. A monitor that allows none reads **Any failing row**. |
| **Min value observed** and **Max value observed** | The extremes found in the column during the run, which show you how far outside the expected range the data went. |
| **Required range** | The range each value had to fall within, for example **18 to 65** or **20 and below**. |
| **Scan window start** and **Scan window end** | The slice of data the run covered, on monitors that scan incrementally. |
| **Scanned windows** | Reads **Full table scan** where the monitor measured the whole table instead of a slice. |
| **Data age** | On Freshness monitors, how old the data was at the moment of the check. |
| **Last write observed** | On Freshness monitors, when the table was last written to. |
| **Max age allowed** | On Freshness monitors, the age the data had to stay under. |
| **Rows added**, **Current row count**, **Previous row count**, **Growth rate** | On Volume monitors, how the row count moved between the previous measurement and this one. |
Every time on a card is written in UTC, so evidence reads the same for everyone looking at the case.
The evidence describes that one run and stays fixed. Later runs add their own incidents with their own evidence, which is what lets you scroll the incident list and see whether a problem is steady, growing, or clearing up.
### Alerts destinations
The **Alerts Destinations** panel shows where the alerts for this case went, with a tab per channel for Email, Slack, Webhook, and Teams. Destinations come from the alert rules that matched the incident.
Each row carries a delivery status. **Delivered** means the channel accepted the message. **Failed** comes with the reason, such as a Slack channel that no longer exists or a webhook that timed out, so you can tell a routing mistake apart from an outage at the destination. Fix the destination on the **Alerts** page, where the rule that produced it lives.
### Case details panel
The right-hand panel opens on **Case details**.
* **Case status**, either Open or Closed.
* **First seen** and **Last seen**, the timestamps of the earliest and latest incidents in the case.
* **Assignee**, which you can set or change with **Edit**.
* **Other cases from this monitor**, each with the period it covered and how long it stayed open. Use it to see whether this failure is a repeat.
* **Audit history**, a running record of what people did to the case: opened, assigned, muted with its duration, unmuted, and closed, each with who did it and when. Actions taken through a bulk update on the Cases listing are marked as such.
The **Monitor properties** subtab holds the configuration of the monitor version that generated this case, including its description, data quality dimension, and custom attributes, along with an entry point to the monitor details page.
### Lineage tab
Lineage draws the standard lineage graph around the asset the monitor runs on, so you can see what feeds it and what depends on it before you decide how far the problem reaches. The tab appears where the monitor is associated with a single asset and that asset is a table or a column.
### Case actions
The **Case actions** menu holds everything you can do to the case itself.
| Action | What it does |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Assign** | Sets the owner of the case. Assignment is recorded in the audit history. |
| **Mute** | Stops alerts for this case for 1 day, 1 week, or 1 month. The monitor keeps running and incidents keep joining the case, so the record stays complete while your channels stay quiet. |
| **Unmute** | Resumes alerts before the mute expires. |
| **Close** | Marks the investigation finished. The next failure from this monitor opens a new case. |
The **Monitor actions** menu sits beside it and acts on the monitor that raised the case, so you can adjust or pause the monitor without leaving the investigation.
## Frequently Asked Questions
1. What is the difference between an incident and a case?
An incident is one failed run. A case is the container that groups every incident raised by the same monitor configuration while it stays open. You triage the case, and the incidents inside it tell you how the problem has behaved over time.
2. What happens when I close a case?
The case moves to Closed and stops collecting incidents. The monitor carries on running to its schedule, and the next failure opens a new case.
3. Does muting a case stop the monitor?
Muting stops alerts for the case. Runs continue, and any failures still join the case as incidents, so you see the full history when the mute expires.
4. Why is there a new case for a problem I already closed?
Closing a case ends its grouping window. A failure after that point starts a fresh case, which keeps each round of the problem separately timed and separately owned. **Other cases from this monitor** in the side panel links them together.
5. An alert shows as Failed. What should I do?
Read the reason on the row. A missing Slack channel or an unreachable webhook points at the destination configured on the alert rule, so correct it on the Alerts page. A timeout points at the receiving system, and the next incident delivers normally once it recovers.
6. Why are the evidence times in UTC?
Evidence records what Decube measured and when, and a single timezone keeps that record unambiguous for teams spread across regions.
