With Hybrid Manager (HM), you can customize the types of notifications you want to receive. The two types of notification channels are:
User notifications — You can receive notifications via email, HM inbox, or both. These notifications are for all users who have enabled them and if their role allows it.
System notifications — You can receive notifications via email (mail group), webhook, Pager Duty, or any combination. These notifications are triggered once per event. System notifications are driven by activity log events, including cluster lifecycle changes (create, update, delete), security and index recommendations, automation task activity, and other platform events.
The user's role in HM determines the extent of their access to notification preferences. The notifications are categorized into the following preference sections:
- Account — For user notification channels.
- Global — For user and system notification channels.
- Projects — For user and system notification channels.
The notifications under the Account preference section are:
- New project role assigned to you
- Project role unassigned from you
- The personal access key is about to expire
The notifications under the Global preference section are:
- New project created
- The machine access key is about to expire
Note
This section is visible only to the organization owner.
The notifications under the Projects preference section are:
- Active cluster paused
- Paused cluster reactivated
- Failed cluster maintenance upgrade
- User invited to project
- Failed third-party monitoring integration
Configuring notifications
Project owners/editors and organization owners/admins can enable/disable notifications for the events visible to them. They can receive notifications in the HM inbox, by email, or both.
Notification settings made by a user apply only to that user. If an email notification is enabled, the email is sent to the email address associated with the user's login.
For org-level and project-level notifications, HM determines who receives each notification by cross-referencing the event's target audience with each user's role and their enabled notification preferences. Both conditions must be met: the user's role must qualify them to receive that notification type, and they must have it enabled in their preferences. Account-level notifications are always delivered only to the individual user they concern.
System notification channels can be configured at the global level by the organization owner or at the project level by the project owner. By default, each organization's project inherits the global-level system notifications channel. However, you can enable/disable or reconfigure the system notifications channel at the project level to override the default settings.
Notification settings follow a scope hierarchy: global settings apply across all projects, and project-level settings override them. Configure at the lowest scope that fits your needs — global for organization-wide defaults, project-level for project-specific routing.
Configure notifications at the global level
Only the organization owner can set the global-level notifications.
Webhook
In the HM console, from your profile menu, select Settings.
Select the Notifications tab.
Select the edit icon next to Webhook and provide the details:
- Host — The full endpoint URL of the webhook, including the scheme. Begin the URL with
https://(recommended) orhttp://. HM rejects a URL that omits the scheme. - Method — HTTP method for the request: POST or PUT.
- HTTP Headers (optional) — Custom HTTP headers to include in the request, as key-value pairs.
- Authentication — Select an authentication type and provide credentials:
- Basic Auth — Enter an optional username and password.
- Bearer Token — Provide a bearer token.
- Host — The full endpoint URL of the webhook, including the scheme. Begin the URL with
Select Save.
Webhook endpoint restrictions
To protect against server-side request forgery (SSRF), HM validates the webhook Host when you save the channel and again each time it delivers a notification, rejecting any endpoint that resolves to an internal or reserved address. The blocked addresses fall into two categories:
- Always blocked — can't be overridden. Loopback addresses (such as
127.0.0.1orlocalhost) and link-local addresses, including the cloud metadata endpoint169.254.169.254. These remain blocked even if an administrator adds them to the allowlist described below. - Blocked by default — can be allowed. Private network ranges (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16) and IPv6 unique local addresses. An administrator can permit specific ranges for legitimate in-cluster receivers, as described in Allowing an internal webhook or SMTP receiver.
If the Host resolves to a blocked address, the save fails with a validation error. Use a publicly reachable endpoint. HM also doesn't follow HTTP redirects returned by the endpoint, so the endpoint must accept the request directly.
Allowing an internal webhook or SMTP receiver
By default, HM blocks webhook and SMTP (email) endpoints that resolve to private or in-cluster addresses. If you operate a legitimate receiver within the cluster or on a private network, a Kubernetes administrator can allow specific IP ranges via the WEBHOOK_ALLOWED_INTERNAL_CIDRS environment variable on the notification service. Despite its name, this single allowlist applies to both webhook hosts and the SMTP host used for email notifications. This is a deployment-level, administrator-only action, intentionally kept separate from setting the webhook or email host in the console.
The allowlist relaxes only the private ranges. Loopback and link-local addresses — including the cloud metadata endpoint 169.254.169.254 — remain blocked and can't be re-enabled via this variable.
The value is a comma-separated list of CIDR ranges. Use the narrowest range that covers your receiver (for example, a single /32) rather than a broad range, which would also re-expose other in-cluster services.
To set it, update the environment variable on the upm-notification-system deployment (container apiservice) in the upm-notification-system namespace:
kubectl -n upm-notification-system set env deployment/upm-notification-system \ WEBHOOK_ALLOWED_INTERNAL_CIDRS="192.168.10.25/32,10.20.0.0/24"
The variable is read only at startup, so the change takes effect after the pods restart. kubectl set env rolls the deployment automatically. If you edit the deployment manifest directly instead, trigger a restart:
kubectl -n upm-notification-system rollout restart deployment/upm-notification-systemPersist the change in your deployment configuration so it isn't reverted on the next upgrade. Leaving the variable empty or unset keeps the secure default of blocking all private and internal targets.
Pager Duty
Before configuring the Pager Duty notification channel:
- You need access to a Pager Duty account with elevated privileges.
- A Pager Duty service must be created and configured with Events API v2 integration.
- In your Pager Duty account, navigate to the desired service and access its Integrations settings.
- Add an Events API v2 integration and configure it according to your requirements.
- Copy the integration key (routing key) provided by Pager Duty for the newly created integration.
Then you can configure the channel:
- In the HM console, from your profile menu, select Settings.
- Select the Notifications tab.
- Select the edit icon next to Pager Duty and set the Routing Key.
- Select Save.
In the HM console, from your profile menu, select Settings.
Select the Notifications tab.
Select the edit icon next to Email and enter the details:
- Email To — Optionally, a group email address for system notifications. HM sends every system notification for this scope to this address — not just events relevant to the person who configured the channel. Use a shared inbox or distribution list, not a personal email address.
- Email From — The email address that sends the notification.
- Host — URL of the email service.
- Port — Port of the email service.
- Username — Username of the email service.
- Password — Password of the email service.
Note
If Email To is set, HM delivers notifications to that address in addition to any eligible individual users — not instead of them. If Email To is left blank, only eligible individual users receive email notifications at their HM account email address.
Select Save.
SMTP host restrictions
The same SSRF protection applies to the email Host (your SMTP server). HM validates it when you save the channel and rejects a host that resolves to an internal or reserved address, using the same rules as webhooks. To use an SMTP server on a private network, an administrator allows its IP range through the same allowlist described in Allowing an internal webhook or SMTP receiver.
Configure notifications at project level
Project-level notification settings can override global settings. Each project can have a unique configuration.
- In the HM console, select the Projects tab.
- Select any project.
- Go to the Project Overview page.
- In the left navigation, select Settings.
- Select Notifications.
- Specify settings as described in Webhook, Pager Duty, or Email.
Viewing notifications in the HM console
Users in the following roles can view the notifications:
- Organization owners can view the global notifications.
- Project owners/editors can view the project notifications.
- All users can view their account notifications.
Each notification indicates the level and project the user belongs to with multiple roles assigned in HM.
Select the bell icon at the top of the HM console to view notifications. You can read a notification, mark it as unread, or archive it.
Some notifications — particularly task-related ones — include a direct link to the affected resource. Selecting the link takes you to the relevant page, provided you have the required access permissions.
When you have unread broadcast notifications — platform-wide announcements such as maintenance windows — a persistent banner appears at the top of the console. If there are multiple unread broadcasts, banners stack. Select Mark as read on a banner to dismiss it.
Managing notification preferences
- In the HM console, from your profile menu, select My Account.
- Select the Notifications tab. Notifications are grouped by account, organizations, and projects available to you.
- Scroll to the Account, Global, or Project section to view the events you want to manage.
- Select the right arrow next to the entity to expand the list of events.
- For each notification, you can:
- Use the toggle next to the event name to opt in or out of receiving notifications for that event.
- When the event toggle is enabled, select the check box for each channel (email, in-app, webhook, Pager Duty) to control which channels deliver that notification.