Alerts, notifications & webhooks

NexoVirt evaluates alert rules every minute (alerts:evaluate) against the metrics, inventory and events it already collects, so alerting adds no load on Proxmox, and sends notifications when a rule fires. Configure it under Settings → Alert rules, which has three tabs: Alert rules, Webhooks and General.

Alert types

Type	Fires when	Settings used
High CPU / High memory / High disk	The average usage of a guest or node over the duration is at or above the threshold.	Threshold (%), duration
Guest down	A running guest stopped without a panel action (a stop or shutdown you started in the panel does not count).
Node unreachable	A node has sent no metrics for longer than the duration.	Duration
Node down	Both the agent heartbeat and the inventory of a connection are stale. Drives the failover banner and page. Hosts in maintenance never count.
Agent unhealthy	A connection’s agent is missing, stale or outdated.
Plan traffic	A plan guest has used more than its monthly traffic limit.
Plan expiry	A plan guest expires within the threshold.	Threshold (days)
Backup failed	A backup task for a guest failed (one alert per task).
Backup stale	A guest’s newest successful backup is older than the threshold. Guests that were never backed up are not flagged.	Threshold (hours)
Failover conflict	A failed-over guest’s original copy was found running again on its returned host. NexoVirt stops it and raises this critical alert.	Raised directly, not by a rule

Every type except Failover conflict resolves on its own once the condition clears. A failover conflict stays open until you resolve it.

Rules

Each rule has a Name, Type, Severity (info, warning, critical), a threshold and Duration (minutes) where the type uses them, an optional Cooldown override (minutes), its Notification channels (Inbox, Email, Webhook) and an Enabled switch.

New installs come with a global rule for every type, for example High CPU at 90 % for 10 minutes, Plan expiry 3 days ahead and Backup stale after 48 hours, all sent to inbox and email. The host-down rule (listed as “Node down”) also goes to webhooks.

Scopes

Under Scope (optional: leave blank for global) a rule can target a Node / cluster (connection ID), a Node (connection ID and node name) or a Guest (connection ID, guest type and VMID). For each condition the most specific enabled rule wins, so you can keep a global default and override it for one node or guest, for example a higher CPU threshold for a build server.

Cooldown and re-notification

While an alert stays active, it is re-sent after the cooldown: the rule’s override, or the Default cooldown (minutes) on the General tab (30 by default).

General settings

• Enable alerting: when off, alerts:evaluate does nothing.
• Email recipients: comma-separated addresses for the email channel. When empty, every admin with an email address receives alerts.
• Default cooldown (minutes).
• Send test alert: sends a test alert through inbox, email and webhook and reports the result per channel.

Escalation (Business plan and above)

The Escalation section re-sends alerts that stay unacknowledged: Escalate after (minutes), a Minimum severity, and separate Escalation channels and Escalation recipients.

Delivery channels

Inbox

Alerts in the sidebar lists active, acknowledged and resolved alerts with Ack and Resolve actions, filters for status, severity and type, and refreshes every 10 seconds. A red badge on the menu entry shows the active count.

Email

Sent through the mail outbox to the configured recipients. Edit the Alert fired and Alert resolved templates under Settings → Email → Templates, group Alerts.

Webhook

Any number of endpoints, each with its own provider and severity/type filters.

Webhook endpoints

On the Webhooks tab, New webhook endpoint opens a form with:

• Webhook URL: the full https URL that receives the POST.
• Provider: Auto-detect (from URL), Generic JSON, Discord or Google Chat. Auto-detect picks Discord for discord.com/api/webhooks/... URLs, Google Chat for chat.googleapis.com and Generic JSON for anything else.
• Severity filter and Alert type filter: leave all unchecked to receive everything.
• Enabled.

The payload depends on the provider:

• Generic JSON: { "event": "fired" | "resolved" | "escalated", "alert": { ... } } with the full alert record.
• Discord: a rich embed colored by severity.
• Google Chat: a card message.

The Live payload preview next to the form shows the exact JSON that will be sent for a sample alert, and updates as you change the provider or the filters. Nothing is sent while you edit. A failing endpoint never blocks delivery to the others.

Note

These are alert webhooks. For webhooks on lifecycle events (guest created, plan suspended and so on), see Event webhooks.

Muting a guest

On a guest’s detail page, switch off Alerts for this guest to exclude it from all alerts. Node and host alerts are unaffected. Guests in the middle of a migration are skipped automatically.

Next steps

• Plans & quotas for the traffic and expiry conditions.
• The node agent for agent health.
• Backups (PBS) for the backup alerts.
• Failover for host-down handling.