Detect & alert

Get told the moment something looks wrong. Define a rule, and when it fires you get a tracked event you can acknowledge and resolve — and a notification wherever you want it.

Rules that watch your data

An AlertRule evaluates a sensor against a condition. It can check a single value or an aggregate over a time window (average, min, max, or count), using comparisons like greater-than, equals, is-true, or contains. Each rule has a severity (INFO, WARNING, or CRITICAL) and a cooldown so it doesn't fire repeatedly for the same condition.

Fired alerts are tracked events

When a rule fires, the platform records an Event with an EventLifecycle that operators work through: ACTIVE → ACKNOWLEDGED → RESOLVED. The Event log is generic — alert firings are one kind of event among others — so everything that happens to your fleet lands in one timeline.

Notifications go where you work

A NotificationChannel is a delivery target. Two channel types are built in — email and webhook — and a rule can fan out to one or more of them. You can send a test message before relying on a channel.

In the app

Work fired alerts under Alerts (/{slug}/alerts) — acknowledge, resolve, and see which notifications went out. Manage delivery channels under Alerting (/{slug}/alerting).

In the API

• GET|POST|PUT|DELETE /api/v1/alert-rules — define rules; POST …/{id}/enable and /disable
• GET /api/v1/alerts — fired alerts; POST …/{id}/acknowledge and …/{id}/resolve
• GET /api/v1/alerts/{id}/notifications — what was delivered for an alert
• GET|POST|PUT|DELETE /api/v1/notification-channels — manage channels; POST …/test to try one
• GET|POST /api/v1/events — the generic event timeline