> For the complete documentation index, see [llms.txt](https://argos-ci.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://argos-ci.com/docs/learn/reliability-and-flakiness/ignored-changes.md).

# Ignored changes

Review every change your project has ignored, see how much review noise each one absorbs, and unignore the ones that went quiet.

Ignoring a change is easy to do and easy to forget. The **Ignored** tab lists every change a project currently ignores, so you can tell which ignores are still earning their keep and which have become blind spots.

### Open the Ignored tab

1. Open your project in Argos.
2. Select the **Ignored** tab.

The tab only appears when the ignore feature is enabled for the project. See [Configure what Argos ignores](/docs/learn/reliability-and-flakiness/flaky-test-detection.md#configure-what-argos-ignores).

### What each row shows

Changes are listed most recently ignored first.

* **Change** — the most recent screenshot carrying this change, with the test name and build name. Select the row to open the change on the test page.
* **Ignored** — when the change was ignored and who ignored it. Changes that [auto-ignore](/docs/learn/reliability-and-flakiness/flaky-test-detection.md#automatically-ignore-recurring-flaky-changes) muted are attributed to the Argos bot and carry an **Auto** badge.
* **Occurrences** — how many auto-approved builds have shown this exact change since it was ignored. This is the review noise the ignore has absorbed.
* **Last seen** — the last build in which this exact change appeared.

### Decide what to unignore

The two right-hand columns are what make the list worth revisiting.

A change with a high **Occurrences** count is doing its job: it would have interrupted a review that many times. A change that hasn't been seen in weeks is the opposite — the flake behind it has probably been fixed, and the ignore is now hiding any genuine regression that happens to produce the same diff.

{% hint style="info" %}
An ignore is scoped to one test and one diff fingerprint, so it never hides a different change to the same screenshot. See [How Argos recognizes the same change](/docs/learn/reliability-and-flakiness/flaky-test-detection.md#how-argos-recognizes-the-same-change).
{% endhint %}

### Unignore a change

1. Hover the row you want to unignore.
2. Select **Unignore**, then confirm.

Argos treats the change as a change again, so the next build showing it will ask for review. The confirmation offers **Undo** if you change your mind.

Unignoring requires the **review** permission on the project.

### FAQ

<details>

<summary>Why does a row show 0 occurrences?</summary>

The change hasn't reappeared in an auto-approved build since it was ignored. Either the flake stopped, or the change simply hasn't run again. Check **Last seen** to tell the two apart.

</details>

<details>

<summary>Does turning the ignore feature off clear this list?</summary>

No. Ignored changes are kept, and the list is still there when you turn the feature back on. While it's off, new builds ignore nothing.

</details>

<details>

<summary>Can I unignore everything at once?</summary>

Not from this page — changes are unignored one at a time. You can also unignore a change from the build page or the test page using the same **Ignore** button that set it.

</details>


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://argos-ci.com/docs/learn/reliability-and-flakiness/ignored-changes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.