Concepts

As discussed in Events, events are central to the operation of Horizon. Almost everything that happens in the system is the result of, or the cause of, one or more events. Each notification is triggered by exactly one event. A good understanding of events is therefore essential to a working knowledge of notifications.

Every event has a unique string identifier (UEI), a string that uniquely identifies the event’s type. UEIs are typically formatted in the style of a URI, but the only requirement is that they start with the string uei.. Most notifications are triggered by an exact UEI match (although they may also be triggered with partial UEI matches using regular expression syntax).

User accounts control access to the web UI, but also store contact information (e-mail addresses, phone numbers, and so on) for the people they represent. A user may receive notifications either individually or as part of a group or on-call role. Each user has several technology-specific contact fields, which must be filled for the user to receive notifications by the associated method.

To learn more about user accounts and how to manage them, see User Maintenance.

In large systems with many users, it might be helpful to organize them into groups. Groups may receive notifications; this is often a more convenient way to operate than configuring notifications to send to individuals. Within a group, a set of users can be assigned to on-call roles. This lets you build more complex notification workflows.

To learn more about groups and how to manage them, see Groups.

On-call roles are an overlay on top of groups. They are designed to let Horizon target the appropriate users according to calendar configurations. A common use case is to have system engineers in on-call rotations with a defined schedule.

On-call roles let you assign a predefined duty schedule to an existing group. The group must have users associated with it.

For each on-call role, a user is designated as a supervisor. They are responsible for the group of people assigned to the on-call role.

See On-Call Roles for more information.

Any user and group may have an associated duty schedule. The duty schedule defines the user or group’s weekly availability for receiving notifications.

If a notification should be delivered to an individual user, but they are not on duty at the time that it’s generated, the notification will not be delivered.

If a notification targets a user via a group, the logic is slightly different: if the group is on duty at the time the notification is generated, all users who are also on duty will be notified. If the group is on duty when the notification is generated, but no member users are on duty, the notification will be queued and sent to the next user who comes on duty. If the group is off duty when the notification is generated, the notification will not be delivered.

For more information on duty schedules, see Create user duty schedule.

A destination path is a named, reusable set of rules for sending notifications. Each destination path has a defined initial step and zero or more escalation steps. Every step in a destination path has an associated delay, which defaults to zero seconds. The initial step’s delay is called the initial delay, while an escalation step’s delay is simply called its delay. If an alarm is cleared or acknowledged within the delay time, the notification will not be sent.

Each step has one or more targets. A target may be a user, a group, an on-call role, or a one-off email address.

When a step targets one or more groups, you may specify a delay for each group. The default delay is zero seconds; this means that all group members are notified at the same time. If you set a longer delay, group members will be notified in alphabetical order, based on their usernames.

For example, defining a five minute delay will mean that when a notification is generated, the first member of the group is notified immediately. Subsequent members are then notified in five-minute increments, from the top of the list of group members to the bottom.

Within a step, each target is associated with one or more notification commands. If multiple commands are selected, they will run at the same time.

Each step also has an auto-notify switch which you may set to off, on, or auto. This switch specifies the logic used when deciding whether to send a notice for an automatically acknowledged notification to a target that was not on duty when the notification was generated. If the switch is off, notices will never be sent to the target. If the switch is on, notices will always be sent to the target. If the switch is set to auto, the system deploys heuristics aimed at "doing the right thing."