6 Notifications
Codex edited this page 2026-05-27 08:16:14 -07:00

Notifications

Dashboard Status

Notifications are optional. The dashboard can send webhook alerts when integrations enter warning or offline states.

Admin Fields

  • Webhook URL
  • Secondary webhook URL
  • Destination type (generic/discord/ntfy)
  • Destination 1 name
  • Destination 1 type (generic/discord/ntfy)
  • Destination 1 URL
  • Destination 2 name
  • Destination 2 type (generic/discord/ntfy)
  • Destination 2 URL
  • Destination 3 name
  • Destination 3 type (generic/discord/ntfy)
  • Destination 3 URL
  • Alert on warnings (true/false)
  • Alert on offline checks (true/false)
  • Backup max age hours
  • Backup alert destination
  • Proxmox CPU warning percent
  • Proxmox CPU alert destination
  • Proxmox memory warning percent
  • Proxmox memory alert destination
Webhook URL: https://example.com/webhook
Secondary webhook URL:
Destination type (generic/discord/ntfy): generic
Destination 1 name: Discord
Destination 1 type (generic/discord/ntfy): discord
Destination 1 URL: https://discord.com/api/webhooks/...
Alert on warnings: true
Alert on offline checks: true
Backup max age hours: 72
Backup alert destination: destination-1
Proxmox CPU warning percent: 85
Proxmox CPU alert destination:
Proxmox memory warning percent: 90
Proxmox memory alert destination:

Leave all webhook URL fields blank to disable outbound notifications.

What Sends Alerts

The dashboard watches integration and check statuses during refreshes. It can alert on:

  • Warning states when Alert on warnings is true.
  • Offline states when Alert on offline checks is true.
  • Proxmox guests whose latest discovered backup is older than Backup max age hours.
  • Proxmox cluster or node CPU above Proxmox CPU warning percent.
  • Proxmox cluster or node memory above Proxmox memory warning percent.

Alerts are intended for state changes and notable problems, not for every refresh.

Alert Rules

The Notifications card shows an Alert rules table for threshold-based rules. Each rule has an enable toggle and threshold field:

  • Proxmox backup age: hours since latest discovered guest backup.
  • Proxmox CPU: CPU usage percent for cluster and node checks.
  • Proxmox memory: memory usage percent for cluster and node checks.

Blank or 0 thresholds disable a rule. Each rule can also target a specific destination. Leave the destination blank to send that rule to every configured destination.

Destination IDs are:

  • primary for the legacy primary webhook.
  • secondary for the legacy secondary webhook.
  • destination-1, destination-2, and destination-3 for the named destination slots.

The table writes to the same settings fields listed above, so older environment variables remain compatible.

Destination Types

  • generic sends a JSON payload with the alert object.
  • discord sends a simple Discord-compatible content payload.
  • ntfy sends a JSON payload with title, message, and status tag.

The legacy primary and secondary webhook fields use the default destination type. The numbered destinations can each have their own name, type, and URL.

Test Send And History

The dashboard admin Notifications card includes Send test notification. It sends a test alert to every configured destination and records recent delivery attempts.

Delivery history shows:

  • Destination name.
  • Destination type.
  • Delivery success or failure.
  • HTTP status when available.
  • Response time.
  • Error message when delivery fails.

Delivery history is saved in the dashboard database at /data/dashboard.db. On upgrade, an existing notification-history.json file is imported automatically. The dashboard keeps the latest 50 delivery attempts so history survives container restarts while staying small.

Security Notes

  • Treat webhook URLs as secrets.
  • Do not paste webhook URLs into screenshots or issue reports.
  • Rotate the webhook URL if it is exposed.

Troubleshooting

  • No alerts: confirm at least one destination URL is saved and the relevant alert toggle is true.
  • Test succeeds but no production alerts: confirm the alert state actually changed; repeated unchanged states are suppressed.
  • Rule sends to the wrong place: check the rule destination selector or clear it to send to all configured destinations.
  • Repeated alerts: confirm the receiving service is not retrying failed deliveries.
  • Delivery failure: use delivery history, check dashboard logs, and confirm the dashboard container can reach the webhook host.