Communicating with your audience about service issues can be difficult; a status page should make this process easy for your team. The Issues section of your Hund status page dashboard helps you communicate about ongoing or scheduled issues.
Creating an Issue
Title
The title of an issue should describe a component's incident in a few words. Leave the scope of the incident out of the title, as your status page provides this information already (i.e. prefer "DDoS Mitigation" over "Website DDoS Mitigation").
Labels
Both issues and issue updates have labels. Labels can be thought of as the status of an issue since they convey your progress in resolving them. Examples include "Investigating", "Assessed", "Monitoring", and "Resolved".
Special labels like "Maintenance" change the way your status page denotes the state of components affected by the issue. For example, applying the "Maintenance" label to an issue will let your users know explicitly that the concerned components are currently under maintenance, rather than experiencing an ordinary issue.
Another special label of note is the "Information" label. When this label is applied to an issue, the issue is automatically considered resolved and has no duration nor state override. It can be used to post bulletins or announcements to given components.
Body
The goal of an issue's body is to minimize incoming support inquiries by providing detailed information. You may want to include helpful details such as the scope of affected users, or estimated time to resolve the incident.
Note: Issues support Markdown!
State Override
Sometimes you may wish to override a component's state while an issue is open. An override is useful, for example, when a payment processor goes down but your service is still functional. Keep in mind that state overrides affect your component's percent uptime as normal status changes from a watchdog would.
Semantic Override
An optional Semantic which overrides the Semantic of the affected Components. This override will be visible on the status page until the Issue is updated. This field may be used in conjunction with "State Override," in which case it will set the underlying state of the selected Semantic.
Priority
Issues can also be created with a priority to control how subscribers are notified about the issue. By default, the priority is "normal," which does not affect the way issue notifications behave. However, when set to "high," all subscribers and notifiers are alerted when something happens to the issue, regardless of their preferences. On the other hand, when set to "low," all notifications concerning the issue will be suppressed.
Open Graph Image
An image which will be displayed alongside this issue when shared on social media websites. If you use the Twitter notifier, then this image will also be attached to any tweets posted concerning the issue.
Creating a Retrospective Issue
When a since passed incident occurs, you may want to still inform your users about the incident after the fact. To do this, you can create a retrospective issue that is backdated to when the issue began and ended. Naturally, this feature can also be used to annotate statuses generated by watchdogs in order to let your users know more about the causes and extent of outages and degraded service reported by watchdogs.
For more information about status annotation and covering, please visit the timeline page.
Scheduling an Issue
Issues can start and end at specified times for planned service outages (e.g. server maintenance) or other announcements that don't affect availability.
If you would like your users to be notified about upcoming scheduled issues, you can choose to have them notified relative to the starting time.
For more information about scheduled issues, visit the scheduled issues page.
Updating an Issue
Issue updates provide your audience with information about issue progress (e.g. resolution, investigation, postmortems). Update issues by viewing an individual issue in the dashboard.
Once an issue update uses the "Resolved" label, the issue is considered resolved.
Reopening an Issue
A resolved issue can be reopened at any time by creating an issue update with a label other than "Resolved" or "Postmortem."
Issue Templates
To aid in the speedy creation of issues, we support issue templates for all components. For some components, such as those using the PagerDuty watchdog, issues can be automatically created when the watchdog detects a status change.
We also expose variables (e.g. PagerDuty incidents, component/group names, etc.) in order to help make a single issue template general enough to be used for as many similar components as possible. Your status page's dashboard provides further documentation on setup.