Notifications inform your users of any issues your platform may be experiencing via a variety of different notifiers. This article will give an overview of how notifications are handled by Hund, including when to expect notifications, and when they might be suppressed.
For more information about particular notifiers, please visit the integrations page.
For information about subscriptions, visit the subscriptions page.
There are many different notification types broadcasted by Hund. Most notifiers support all the following types, save for webhooks, which do not currently support issue notifications.
- Component Degraded: a component has taken on a degraded or outage state
- Component Restored: a component has come back up from either an outage or degraded state
- Issue Created: an issue has been created
- Issue Retrospectively Created: a retrospective issue has been created
- Informational Issue Created: an informational bulletin/announcement issue has been posted
- Issue Updated: an issue update has been created
- Issue Resolved: an issue has been resolved
- Issue Addended: an issue addendum/postmortem update has been created
- Issue Reopened: a resolved issue has been reopened
- Issue Upcoming: a scheduled issue will start soon
- Issue Started: a scheduled issue has started
- Issue Cancelled: a scheduled issue has been cancelled
- Issue Ended: a scheduled issue has ended (without being cancelled)
- Notifier Tested: a notifier was tested, thus emitting test notifications
Regardless of whether you have enabled the Email notifier, Hund will send you and your team notifications from email@example.com whenever one of the above event types occurs (excluding test notifications). For this reason, team members cannot subscribe to the Email notifier, since they would get double notifications. If this behavior is desired, you can augment your email address with extra characters using the plus sign (if your email provider supports this). For example, if your email address was
firstname.lastname@example.org, you could subscribe with
In general, when an event occurs on our platform, notifications are broadcasted immediately afterwards. However, there are certain event types where we delay its notifications, and possibly subsume them with other events that occurred around the same time. Certain events are subsumed in order to keep from sending excessive and unnecessary notifications to subscribers.
The following notifiation types are delayed and possibly subsumed (meaning the event will be suppressed in favor of another event):
- Component Degraded: delayed for at most one minute; will be subsumed if Component Restored or another Component Degraded occurred within the past 15 minutes, or if Issue Created occurred or will occur within one minute of the original event firing
- Component Restored: delayed for at most fifteen minutes; will be subsumed if Component Degraded or another Component Restored will occur within the next 15 minutes, or if Issue Resolved occurred or will occur within 3 minutes of the original event firing
Please note that subsuming events like Issue Created and Issue Resolved above are never delayed, and will therefore broadcast immediately. Moreover, the above rules apply to all notifier types.