Skip to content

Notifications Panel

The Notifications panel manages who gets notified about fleet events, and how. Open it with the Notifications item in the PathLab sidebar. The panel lists the fleet's current subscriptions with their event, recipients, scope, and delivery rules. Create Notification at the bottom opens the form. You can Edit or Delete the subscriptions you own.

A subscription answers a simple question: who is notified, about what event, in what scope, and under what rules.

Note. Each subscription is owned by the person who created it. Everyone with access to the fleet can see the fleet's subscriptions, but you can edit or delete only your own.

Create or edit a subscription

Control What it does
Event The fleet event to watch, for example a robot going offline or online, a mission completing, failing, or aborting, an operation starting or completing, a robot fault, a robot message, a detected object, or a low battery.
Robot Limit the subscription to one robot, or leave it on Any robot.
Object type For the Object Detected event only. Match a specific object type (for example Person or Vehicle) or Any type.
Minimum severity For events that carry a severity (Robot Fault, Robot Message, and Alert Created). Notify only at or above the chosen level.
Email recipients One or more email addresses. If you set neither an email nor a webhook, notifications go to your account email.
Webhook URL An endpoint that receives an HTTP POST for each event, with optional custom headers. See Webhook deliveries.
Cooldown The minimum time between notifications from this subscription, to avoid floods.
Expires An optional date and time after which the subscription stops. Blank means it never expires.

Webhook deliveries

A webhook subscription sends an HTTP POST to your endpoint for each matching event. The request includes:

  • Body: a JSON object describing the event (its type and severity, a title, the robot and fleet it relates to, and an event-specific payload).
  • Content-Type: application/json.
  • Idempotency-Key: stable across retries, so your endpoint can recognize and ignore duplicate deliveries.
  • Signature headers (X-Nexus-Signature and X-Nexus-Signature-Timestamp): let your endpoint confirm that the request is authentic and recent, rather than forged or replayed.
  • Any custom headers you configured, for example an Authorization token your endpoint requires.

Deliveries are at-least-once: if your endpoint is briefly unreachable or returns a temporary error, the delivery is retried with backoff, so you may occasionally see a duplicate. Make your receiver idempotent (dedupe on the Idempotency-Key) and return a 2xx status quickly on success. For the signing scheme and step-by-step signature verification, contact your Rover Nexus administrator.

Note. The signing key is never shown in the app. Your endpoint authenticates incoming requests using the signature headers above and any custom header you set.