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.
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.
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.
- 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.
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.
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. |
When policies overlap
Each recommendation is handled by one alerting policy only. If several turned-on policies match it:
- A cloud-account policy beats an organisation policy.
- 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 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.