# Alerting policies

> Tell your team about new recommendations in Slack, Microsoft Teams, Google Chat, or a webhook, or open a Jira ticket for them automatically, filtered by category, severity, resource type, and cloud account.

Source: https://zop.dev/docs/zopnight/policies/alerting

---

An **alerting policy** watches for new recommendations and tells the right people about them. When a new recommendation matches the policy's conditions, it either **sends a message** to your channels (Slack, Microsoft Teams, Google Chat, or a webhook) or **opens a Jira ticket**. Alerting policies only tell people. They never change a resource or fix a recommendation.

![Alerting policies list with search, Category and Action filters, and a policy row showing its description, category, Org scope, an Open a ticket action, and an on/off switch](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20261020/b2d553c9-47d2-41e8-a06d-898a14cdea0f-policiesalerting.png)

*Governance → Policies → Alerting: each policy with its category, scope, action, and on/off switch.*

## Before you start

- **Permission to manage policies.** The built-in **Editor** and **Admin** roles have it. **Viewer** can only look. See [Scopes](https://zop.dev/docs/zopnight/concepts/scopes).
- **To send messages:** at least one channel set up under **Settings → Notifications**.
- **To open tickets:** Jira connected under **Settings → Integrations**. Until it is, a ticket policy can't be saved. See [Jira](https://zop.dev/docs/zopnight/integrations/jira).

## When a policy fires

A policy acts on a recommendation **once, when it first appears**, not on every refresh.

- A recommendation that is already open, applied, or dismissed doesn't trigger it again.
- If a recommendation was resolved and the problem comes back later, it counts as new: a message policy sends again. A ticket policy doesn't open a second ticket; the existing Jira ticket is moved back to **To Do** with a comment saying the recommendation is active again. A new ticket opens only if the old one was deleted in Jira.
- **Messages are only for new recommendations.** Creating a message policy sends nothing about recommendations that are already open.
- **Tickets also cover what's already open.** When you create a ticket policy in the app, ZopNight straight away opens tickets for the open recommendations it matches, then keeps opening them for new ones. It never opens two tickets for the same recommendation. Editing a policy or turning it back on doesn't do this again.

**Warning**

A ticket policy with no conditions matches **every** open recommendation, so it can open a lot of tickets at once. Before you save, the form shows roughly how many ("about N tickets on the first run"). Check that number first.

## Create an alerting policy

**Open the Alerting policies**

  Go to **Governance → Policies**, click the **Alerting** card, then click **+ New policy**.

**Name it**

  Give it a **Name** (required, up to 120 characters) and, if you like, a **Description**.

**Choose the scope**

  **Organisation** (the default) covers every cloud account. **Cloud account** limits the policy to one account. You can't change the scope later, even though the box still looks editable when you edit. To move a policy, create a new one and delete the old one.

**Set the conditions**

  Every condition is optional. The ones you set must all match:

  - **Category**: one kind of recommendation, such as Idle, Rightsizing, Orphan, Schedule, Security, Compliance, Governance, Reliability, Discount, or Performance. The form explains the category you pick. Leave it on **any** to match all.
  - **Severity**: any of critical, high, medium, and low.
  - **Resource types**: one or more resource types from your account or organisation.

  With no conditions, the policy matches every recommendation in its scope, and the form warns you.

**Choose the action**

  - **Notify only** (the default): pick one or more **Channels**.
  - **Open a ticket**: choose a **Jira project** and **Issue type**, or leave them on **Use the connection default**. Once you pick a project you can also pick a **Default assignee**; without one, tickets are unassigned.

  As you go, the form shows how many open recommendations match right now.

**Validate, then create**

  Click **Validate**. Once it passes, **Create policy** turns on. If you change anything afterwards, validate again.

## What people receive

| Action | What arrives |
|---|---|
| **Notify only** | A message with the recommendation, the resource name and type, the cloud, the severity, and the estimated monthly saving (if there is one). |
| **Open a ticket** | A Jira issue whose title starts with `[ZopNight]` and names the recommendation, the resource, and the monthly saving. It also shows where the resource is (cloud, region, account), the category, the cost now and after, and a link back to ZopNight. The ticket's status stays in sync with the recommendation. See [Jira](https://zop.dev/docs/zopnight/integrations/jira). |

## When policies overlap

Each recommendation is handled by **one** alerting policy only. If several turned-on policies match it:

1. A **cloud-account** policy beats an **organisation** policy.
2. If both have the same scope, the **oldest** policy wins.

Only policies whose conditions match the recommendation take part. The others do nothing for that recommendation, so two policies can't both act on it: you can't get a message from one and a ticket from another. A cloud-account policy replaces an organisation policy only for the recommendations both of them match. For example, an account policy for **Idle** doesn't stop the organisation policy from acting on **Security** recommendations in that account.

## Manage policies

The list shows each policy's name, description, category, scope (Org or Account), action, and an **On** switch. You can search by name and filter by category and action. Search and filters only look at the page you're on, so if you have many policies, set the list to 50 or 100 per page first.

- **Turn a policy off** with its switch. It stops firing; tickets it already opened stay open.
- **Edit** by clicking the row (if you're allowed to edit policies). You can change everything except the scope.
- **Delete** with the bin icon. This can't be undone.

## From the API or an AI assistant

Developers can manage alerting policies through the ZopNight API, where they're called `recommendation` policies. The API can also match on cloud provider, environment, a specific rule, and monthly saving, which the form doesn't show. If you edit such a policy in the form, extra conditions that must all match are kept, and its **Category** column may show a dash. Conditions combined with *any* or *not* are replaced as soon as you set Category, Severity, or Resource types in the form.

From an AI assistant, use the [MCP server](https://zop.dev/docs/zopnight/integrations/mcp) tools `list_alerting_policies`, `create_alerting_policy`, `update_alerting_policy`, and `delete_policy`. Creating a ticket policy this way doesn't open tickets for recommendations that are already open; ask the assistant to run `apply_recommendation_policy` for that.