> 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 Filter the alert list down to what you care about, save those views, and act on alerts in bulk. 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** and click **Filters** at the right end of the row above the list. In the panel that opens, click **Add label filter** under **Labels**. {% endstep %} {% step %} ## Choose a key, an operator, and a value Pick the label key in **Select label...** (for example `app`). Keep **is equal to**, or choose **is any of**, **is not equal to** or **is not any of**. Then select or type the value (for example `database`). The **is any of** and **is not any of** operators take several values. {% endstep %} {% step %} ## Add it Click **Add filter**. The condition appears under **Labels** and above the list as `app == database`, and the list narrows to match. Add more conditions to narrow further — they all apply together. {% endstep %} {% endstepper %} The same panel holds every other filter: **Status**, **Severity**, **Priority**, **Alert sources**, **Affected services**, **Responders**, **Escalation policies** and **Date**. Each choice applies as you make it. Close the panel and everything you set is listed above the alerts, next to **Clear filter** and **Save filter**. ## Save a filter A filter you rebuild every morning should be a saved filter instead. Saved filters sit in the row above the list, after the four built-in ones: **Open**, **Pending**, **Accepted** and **All**. {% stepper %} {% step %} ## Save the current filters With your filters applied, click **Save filter** at the right end of the criteria above the list. The **+** after the last saved filter does the same: it starts a new saved filter from the current criteria. {% endstep %} {% step %} ## Name it and choose who sees it Enter a **Name**, then pick a **Visibility**: | Visibility | Who sees it | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Personal** | Only you | | **Team** | The teams you pick in **Select teams...** own it, so it follows their [resource visibility](/users-and-access-management/teams.md#resource-visibility): if all of them are public, everyone sees it; if one is private, only members of the teams you picked and admins do | | **Public** | Everyone in the account | | {% endstep %} | | {% step %} ## Save and check it Click **Save**. The filter joins the row. To check it, click **Open**, then click your filter: the list narrows again and its criteria are listed above it. {% endstep %} {% endstepper %} {% embed url="" %} Build a view, save and share it, change it, and pin it {% endembed %} ### Change a saved filter A saved filter stays highlighted while the list matches it exactly. Change any criterion and the highlight goes out. **Save filter** then offers two choices: * **Save to this search** updates the saved filter, for everyone who sees it. * **Save as new search** keeps the original and saves your changes as a new filter. ### Manage a saved filter Hover over a saved filter and click the three-dot icon that appears on it: | Action | Does | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Copy link** | Copies a link to the alert list with the filter's criteria in it. The link carries the criteria, not the saved filter: it works for people the filter is not shared with, and it does not follow later changes to the filter | | **Edit** | Renames the filter or changes its visibility. To change what it matches, adjust the filters and use **Save filter** → **Save to this search** | | **Duplicate** | Starts a new filter with the same criteria and visibility, named after the original with "Copy" added. Rename it if you like, then click **Save** | | **Pin filter** | Moves the filter ahead of your other saved filters and keeps it in the row whichever team you select in the top bar. Pins are per person: nobody else's row changes. **Unpin filter** reverses it | | **Delete** | Deletes the filter for everyone who sees it, at once and without asking for confirmation | ### Saved filters and the team filter Which saved filters appear in the row depends on the [team filter](/users-and-access-management/teams.md#the-team-filter) in the top bar. With **All teams** selected, the row shows your personal filters, public filters and the team filters visible to you. With **My teams** or a single team selected, it shows only the filters owned by those teams, plus the ones you pinned. Personal and public filters belong to no team, so they drop out. Pin a filter to keep it in reach whichever team you look at. ## 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 checkbox on the left of each row, or the checkbox in the header row to select every row on the page. The column headings then turn into the actions you can run on the selection. The header checkbox selects the page, not everything that matches your filter. The list holds 39 alerts at a time, and the alerts on later pages stay unselected even though they match. Each action shows how many of the selected alerts it can act on, for example **Accept (10/39)** when 10 of the 39 are still pending, so read that count before you click. After a bulk **Resolve** in the **Open** view, the resolved alerts drop out and the next matching ones move up into the page, so look at the list again rather than paging on. | 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 %} {% embed url="" %} What the header checkbox selects, and what the counts on the actions mean {% endembed %} --- # 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://docs.ilert.com/alerting/working-with-alerts.md?ask=&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.