Alerts & notifications

Choose what to watch, where to notify, and how to handle an incident.

Example: CPU above 90% for five minutes

1. Open the project's Monitoring → Alert rules and create a CPU utilization rule.
2. Select the VMs to watch, or all VMs. All VMs also includes future VMs in this project.
3. Set above 90%, sustained for five minutes, and choose Warning or Critical.
4. Select destinations, or leave them empty for in-app incidents only.
5. Preview coverage and values. Optional 1-hour, 6-hour or 24-hour history estimates use a bounded sample of up to 50 VMs; gaps are not healthy periods.
6. Save and check application/evaluation status. Pending or Error does not mean the rule is actively watching the VMs.

Other templates include memory, filesystems, VM availability and missing telemetry, with additional guest templates when the relevant measurements exist. Select exact observed mount/service/device dimensions where requested. Initial defaults are 20 rules, five destinations and 10,000 evaluated instances; the project's displayed limits are authoritative.

What “open” means

Label	Meaning
Open	The alert triggered and recovery has not been confirmed. It can remain open when fresh measurements are unavailable.
Acknowledged	Someone recorded that they have seen it. The underlying incident is still open.
Snoozed	Notifications are temporarily suppressed. Evaluation continues.
Recovered	Fresh eligible measurements confirmed the condition cleared.
Retired	The rule/resource context changed, such as a rule being paused, edited or deleted. This is not a claim of recovery.

The recorded value in an incident is a retained observation, not a live chart reading. Open its details for context and the VM's charts for current measurements. History can include open incidents; use its state filter when looking only for recovered or retired ones. No configured rules means nothing is being watched, not that the project is healthy.

Set up notifications

Open Monitoring → Notifications and add a destination:

• Email: select a current project member. The recipient must verify the address through the verification flow and retain access.
• Slack or Discord: create an incoming webhook in the intended channel and paste its URL into the destination form.
• Microsoft Teams: use the supported Workflows webhook endpoint, not a retired connector URL. Use the provider-specific instructions offered for the environment.
• Signed webhook: select or create a project webhook subscription. Your receiver must verify signatures and deduplicate deliveries.

Chat URLs are credentials: they are write-only and must not be pasted into tickets or logs. To change a chat endpoint, create a replacement destination, update the affected rules and disable the old destination.

Test before relying on delivery

1. Use Send test once. This sends a real external message.
2. Wait for the retained test result. Accepted/queued is not yet sent; Sent means the provider or endpoint accepted it, not that a person read it.
3. Check the intended inbox/channel/receiver. Correct configuration or recipient eligibility before testing again.

Delivery is at least once; retries can produce duplicates. Timeouts do not prove the receiver got nothing. Pausing a destination stops future sends without removing incident history. Acknowledgement does not fix the condition; snooze is the explicit temporary notification control.

Troubleshooting

• No incident: check rule application, sustained duration, VM selection, source coverage and maintenance/intentional-stop suppression.
• Open but the VM looks healthy: check whether fresh eligible recovery measurements have arrived; compare timestamps, not just the recorded incident value.
• No notification: check destination enablement, verification, channel availability, snooze and delivery/test status.
• Save conflict: reload the latest version before editing. After an uncertain result, recover the original request before submitting a new mutation.

See API examples and webhook verification.