STUB DOCUMENT: This page is intentionally minimal and will be expanded with deeper technical details in a future update.
- technical (default): operational or hardware events (e.g. robot stuck, calibration needed).
- business: business-process events (e.g. order delayed, SLA threshold exceeded).
Examples:
- A robot needs calibration.
- A robot got stuck and needs remote takeover.
- A sensor reading is out of expected range.
- An order has exceeded its SLA deadline.
Model
Every alert belongs to a workspace and must be attached to at least one of: twin, environment, or workflow.
| Field | Type | Notes |
|---|
name | string | Human-readable title |
description | text | Optional details |
alert_type | string | Machine-readable code (e.g. calibration_needed, robot_stuck) |
severity | enum | info, warning, error, critical (default: warning) |
status | enum | active, acknowledged, resolved, silenced (default: active) |
source_type | enum | edge, simulation, cloud, workflow (default: edge) |
category | enum | technical, business (default: technical) |
Lifecycle
- Active: new alert, requires attention.
- Acknowledged: an operator has seen it but the issue is not yet fixed.
- Resolved: the root cause has been addressed (by edge device or operator).
- Silenced: suppressed workspace-wide without resolving the root cause.
MQTT
Edge devices create and resolve alerts via MQTT. Topic pattern:
cyberwave/twin/{twin_uuid}/alert
