Skip to content
Docs

Alerting and notifications

On this page
  1. The vocabulary
  2. When notifications are sent
  3. Choose who is notified
  4. E-mail
  5. Mobile push notifications
  6. Other channels
  7. Avoid unnecessary alerts

Monitoring finds problems; alerting makes sure the right people hear about them. In Onagre, the link is simple: each sensor has its own list of integrations, and those integrations are notified when the sensor opens or resolves an incident.

From a failed check to a notification A failed check opens an incident at once; the integrations linked to the sensor are notified. The first successful check resolves it and notifies them again. Run by an agent, on its scheduleSensorA check failsIncidentOpened at onceAlertingLinked integrationsNotificationsSlack, e-mail…First successful check → incident resolved → recovery notification to the same integrations
A failed check opens an incident at once; the integrations linked to the sensor are notified. The first successful check resolves it and notifies them again.

The vocabulary#

Term Meaning
Sensor Checks something on a schedule.
Incident Opened by a sensor when a check fails, resolved when it succeeds again.
Integration A notification channel: a Slack channel, a webhook, a phone, an e-mail address…
Alerting The integrations linked to a sensor.
Notification The message an integration receives.

When notifications are sent#

Event Notification
An incident opens "Sensor name is down", with the time, the error and a link to the incident.
The incident is resolved "Sensor name is up", with the time and a link to the sensor (e-mails also give the downtime).
The incident is acknowledged None — the acknowledgement is recorded in the incident's activity.
The problem lasts None — Onagre does not repeat notifications.

A brand-new sensor whose first check succeeds also sends an "up" message, without any incident.

Each delivery is recorded in the incident, as Sent or Failed. A failed delivery — an expired webhook, a deleted Slack channel — is not retried: check the incident's Notifications card if someone was not warned.

Choose who is notified#

Alerting is set per sensor:

  • When you create a sensor — the Alerting section of the wizard lists your integrations; select the ones to notify. If you select none, Onagre asks you to confirm: the sensor will record incidents but warn nobody.
  • On an existing sensor — Edit, then Alerting. The Alerting card of the sensor's page shows the current list.
  • For many sensors at once — in Resources, select the sensors and click Alertings to assign integrations. This replaces their current alerting.

All the integrations of a sensor receive all its notifications: there is no routing by severity. To send critical incidents to the on-call phone and minor ones to a Slack channel only, choose the integrations sensor by sensor — the severity is shown in every notification.

Sensors created automatically with a private agent start with all your integrations.

E-mail#

Every member of your organization automatically has an e-mail integration, named after their address. A member receives e-mails for a sensor only if their e-mail integration is in that sensor's alerting. There are no per-user notification preferences: alerting is decided on the sensor.

Each plan includes a daily number of alert e-mails — see Plans.

Mobile push notifications#

The Onagre mobile app needs no alerting: once you sign in, the phone receives the incidents of every sensor of your organization, filtered by the settings chosen in the app.

Other channels#

Slack and Discord are available on every plan; Microsoft Teams, Google Chat, Webhook, Pushover and Gotify on paid plans. See Integrations.

Avoid unnecessary alerts#

  • Schedule a maintenance window before planned work: checks pause, so no incident and no notification.
  • Choose conditions and timeouts that reflect a real problem: one failed check is enough to alert.
  • Keep critical sensors on channels someone watches; use Info severity and a quiet channel for the rest.