Alerts and monitors

Why

The first alert most hardware teams need is simple: tell me when battery voltage drops below 11.5 V, or when motor temperature goes above 80 °C. You shouldn't need to watch a chart to catch it.

How it works

For devices streaming to Plexus, a separate alert service reads every data point as it arrives and checks it against your limits. For connections to your own database, Plexus checks new rows every 30 seconds.

An alert opens as soon as a reading crosses the limit. On streaming devices, a value hovering at the line won't flap: the alert closes only after the reading has stayed back inside the limit for 30 seconds, then waits 60 seconds before it can open again.

Using it

Go to Alerts, then Monitors, and click New Monitor. Pick Threshold, choose the source and metric, and fill in "Alert when value drops below", "Alert when value exceeds", or both. Pick a severity. Add an email integration under Alerts, then Integrations, to receive the alert by email.

The alert shows the source, the metric, the reading and the limit it crossed, for example battery_voltage below threshold on rover-02. Acknowledge it with A, or resolve it with R.

Limits

Limits are fixed numbers. Plexus doesn't learn a baseline for you. Monitors are part of paid plans.

How it works

Plexus checks for new data every 30 seconds. For a device, it reads the data Plexus stores for you. For a connection, it queries your own database, looking for rows newer than the last one it saw.

A new monitor starts from the newest existing row and doesn't alert on it. So turning on a monitor never floods you with history. Rows that arrive during a quiet window still count as seen, so they don't fire later.

Using it

Go to Alerts, then Monitors, and click New Monitor. Pick Event, choose the source and the metric or table to watch, and set a severity. On a connection, you can pick which column marks a new row, such as created_at or an id.

The alert tells you what arrived, for example "New event: fault_code = 12", and how many rows came in since the last check. Send it to Slack, email or a webhook like any other monitor.

Limits

Checks run every 30 seconds, so an event can take up to that long to alert. Monitors are part of paid plans.

Slack

Go to Alerts, then Integrations, and add Slack. Slack asks which channel to post to, and that channel becomes an integration. Messages are color-coded: red when an alert opens, blue when acknowledged, green when resolved. Each shows the source, metric, value, threshold and severity, any context columns the monitor includes, and a View in Plexus button.

On each monitor, pick which integrations it posts to, and send a test from the chip before you rely on it. If a post fails, Plexus retries after 1, 5 and 30 minutes. Email and webhooks work the same way.

Stream stopped monitors

Pick Stream stopped when you create a monitor, choose the device, and set how long it may be silent: 5 minutes by default. Plexus checks every 30 seconds. When the device has been silent longer than that, you get an alert: "No data from pod-7 for 6m". It resolves when data comes back.

Limits

Each Slack integration posts to one channel. Add another integration for another channel. Alerts and integrations are part of paid plans.

What's new

• Row filters. On a connection, add conditions like status = failed or temp_c > 80, using =, ≠, >, ≥, < or ≤. Only matching rows fire.
• One alert per row. Off: one alert per scan, such as "New runs row — unit=rover-02 (+2 more)". On: a separate alert for each matching row, up to 10 per scan. Anything beyond that goes into one summary alert so a backfill can't flood your channels.
• Context in the message. Pick up to 5 columns to include, like the unit or the operator. They show as fields in Slack and email.
• Cursor column. Choose which column marks a new row, such as created_at or an id. Avoid updated_at, because every edit would fire again.

Silence

Open any alert and click Silence. Choose 15 minutes, 1 hour, 8 hours, 24 hours or 7 days, or set a custom time. The menu says what it does: it stops all future alerts from this monitor, and the alert you're looking at stays open. Silence can't run longer than 7 days, so a monitor doesn't get forgotten.

How it works

Event monitors poll every 30 seconds. On devices, Plexus reads its own store; on connections, it queries your database. A new monitor starts from the newest existing row, so it never fires on your history.

How it works

• One list at Alerts, then Monitors, with columns for Type, Source, Metric, Condition, Status, Notify and Created. Filter by Threshold, Event or Stream stopped.
• One monitor is one row. A threshold and an event monitor on the same metric are two rows, each with its own severity, silence and routing.
• Deleting a device removes its monitors too.

Using it

Click New Monitor. The dialog has two steps.

What to watch: pick Threshold (alert when values cross fixed limits), Event (alert on every new data point or row) or Stream stopped (alert when data stops). Choose the source and metric, set the condition, and pick a severity: Info, Warning or Critical.

Where it goes: pick the integrations that get a message, and optionally an on-call ladder. Each integration chip has its own test send. A summary line spells out what happens, for example "Posts to #ops · Calls nobody". Leave integrations empty and the line names every integration that receives alerts by default.

Limits

Severity labels and colors the alert. It does not decide who is called; the monitor's ladder does. Monitors are part of paid plans.