Alerts & Notifications
EmberNet watches the health of your fleet and storage and raises an alert the moment something needs attention: a device stops responding, a site goes dark, or a storage volume loses redundancy. Alerts appear in the dashboard in real time and can be sent onward by email or webhook.
What EmberNet alerts on
The platform evaluates these conditions continuously, out of the box. There is nothing to configure to get baseline coverage.
Device and site health
| Alert | Fires when | Severity |
|---|---|---|
| Device offline | A registered device stops responding to its health check | Critical |
| Device degraded | A device has been offline longer than the degraded threshold (default 10 minutes) | Warning |
| Site down | Enough devices at a facility or building are offline at once to indicate a site-wide problem | Critical |
| Device recovered | A previously-offline device comes back | Info |
A device that recovers automatically resolves its own offline alert, so you don't have to clear it by hand.
Storage health (Cinder)
| Alert | Fires when | Severity |
|---|---|---|
| Volume degraded | A volume is serving data but running with fewer healthy replicas than configured, so another failure would risk data loss | Warning |
| Volume faulted | A volume has no usable replicas and cannot serve data | Critical |
| Capacity guardrail | A disk has no schedulable space left, so Cinder can't place new or rebuilt replicas | Warning |
These clear automatically once the volume returns to healthy or capacity is freed. See Storage for the underlying model.
Severity levels
| Severity | Meaning | Typical response |
|---|---|---|
| Info | Informational: a recovery or state change, no action needed | Review |
| Warning | A real problem that isn't yet service-affecting | Investigate this shift |
| Critical | Service-affecting or one failure away from it | Act now |
Alert lifecycle
| State | Description |
|---|---|
| Active | The condition is currently true and the alert is raised |
| Acknowledged | Someone has taken ownership; the alert stays active until the condition clears |
| Resolved | The condition has cleared, automatically for health and storage alerts, or manually |
To prevent a flapping condition from paging repeatedly, each alert has a cooldown (default 15 minutes) before it will re-notify.
Notification channels
Alerts always appear in the dashboard. You can additionally route them to:
Email
Delivered over your configured SMTP server. Recipients are resolved automatically to the affected tenant's admins and managers, and you can add a fixed recipient list. Configure SMTP under Admin → Settings.
Webhook
An HTTP POST to a URL you provide, carrying the alert as JSON, for wiring EmberNet into an existing incident tool or chat system. Failed deliveries are retried.
EmberNet dispatches to the dashboard, email, and webhook. SMS and third-party on-call integrations are not built in today; use a webhook into your incident platform to bridge to them.
Managing alerts
Acknowledge
Acknowledging an alert records who took it and when, so the rest of the team knows it's being handled. It does not resolve the alert; the alert clears on its own when the condition ends, or when someone resolves it.
Resolve
Health and storage alerts resolve themselves when the underlying condition clears. An operator with the right permission can also resolve an alert manually, which is useful for a condition that has genuinely ended but hasn't been re-observed yet.
Alert history
Every alert is retained with its full timeline: when it fired, who acknowledged it, and when it resolved. Open the Alerts view and switch to History to review past incidents.
Next steps
- Storage: the storage conditions behind Cinder alerts
- Configuration Reference: SMTP and alert settings
- API Reference: read and manage alerts programmatically