> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/alerting/working-with-alerts.md).

# Working with alerts

The **Alerts** page is where triage happens. On a busy account it lists far more than any one person needs, so most of the work is narrowing it — by label, by source, by status — and then acting on what is left.

## Filter alerts by labels

Labels come from the events your tools send. Filtering on them narrows the list to a service, an environment, or a cluster.

{% stepper %}
{% step %}

## Open the label filter

Go to **Alerts**, then click **Filter** under the **Labels** header.
{% endstep %}

{% step %}

## Choose a key, an operator, and a value

In **Add label filter**, pick the label key (for example `app`), choose an operator such as `is equal to`, then select or type the value (for example `database`).
{% endstep %}

{% step %}

## Add it

Click **Add filter**. Repeat to narrow further — multiple label filters apply together.
{% endstep %}
{% endstepper %}

## Save a view

A filter you rebuild every morning should be a saved view instead.

{% stepper %}
{% step %}

## Save the current filters

With your filters applied, click the **+** icon in the **Saved filters** bar.
{% endstep %}

{% step %}

## Name it and choose who sees it

Enter a name, then pick a visibility:

| Visibility    | Who sees it                     |
| ------------- | ------------------------------- |
| **Personal**  | Only you                        |
| **Team**      | Members of the teams you select |
| **Public**    | Everyone in the account         |
| {% endstep %} |                                 |

{% step %}

## Save

Click **Save**. The view appears as its own tab in the **Saved filters** bar.
{% endstep %}
{% endstepper %}

### Managing a saved view

Click the three-dot icon on a saved filter tab:

| Action         | Does                                                 |
| -------------- | ---------------------------------------------------- |
| **Edit**       | Change the name or visibility                        |
| **Copy link**  | Share a direct link to this filtered view            |
| **Duplicate**  | Copy it as a starting point for another view         |
| **Pin filter** | Make it the view you land on when opening **Alerts** |
| **Delete**     | Remove it permanently                                |

## Act on alerts in bulk

During a noisy period, handling alerts one at a time is the bottleneck. Select several and act on them together.

Tick the checkboxes on the left of each row — or the checkbox in the header row to select everything in the current filtered view — and a bulk action bar appears above the list.

| Action            | Does                                                                                                       |
| ----------------- | ---------------------------------------------------------------------------------------------------------- |
| **Accept**        | Take ownership. This **stops escalation** on every selected alert.                                         |
| **Reroute**       | Move the selected alerts to a different escalation policy                                                  |
| **Resolve**       | Close them, if the underlying problem is fixed                                                             |
| **Link incident** | Attach them to an existing [incident](/incidents-and-status-pages/incidents.md)                            |
| **Merge**         | Combine them into one parent alert — see [Merging alerts](/alerting/working-with-alerts/merging-alerts.md) |

{% hint style="warning" %}
An alert that is already a parent — one that has other alerts merged into it — cannot be merged into another alert.
{% endhint %}

{% hint style="info" %}
Bulk **Accept** halts escalation on everything you selected. If you are clearing a backlog rather than taking ownership, **Resolve** is usually what you want.
{% endhint %}


---

# 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, and the optional `goal` query parameter:

```
GET https://docs.ilert.com/alerting/working-with-alerts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.