Alert fields

Alerts are the backbone of any effective IT operations team, providing crucial information about events. They serve as a centralized hub that captures important details from the moment an event is triggered until its resolution. As alerts progress through their lifecycle, they accumulate a wealth of historical information.

In Jira Service Management, alerts are not static entities but dynamic entities that evolve with every interaction and update. They are comprised of two types of fields: informational fields, where users input specific details, and state fields, which are automatically updated by Jira Service Management. This combination allows for a holistic view of the alert, capturing both user-provided insights and system-generated updates.

In the following sections, we will explore the different types of fields within an alert and how they contribute to the overall understanding and management of events.

Informational fields

1. Message: This mandatory field serves as a concise description of the Alert. It has a maximum limit of 130 characters. The message value can be updated later if needed.

2. Responders: This field captures the names of the individuals who have been added as responders to the alert, ensuring they are notified about the alert.

3. Alias: An optional field, the alias allows users to assign a user-defined identifier to the alert. It is limited to a maximum of 512 characters. If not specified, Jira Service Management will automatically assign a unique value during alert creation.

4. Entity: This field is commonly used to specify the domain or context to which the alert is related. It could be the name of a server or application. The entity field has a limit of 512 characters.

5. Actions: Alerts can have both default actions provided by Jira Service Management and custom actions defined by users. Read more about alert actions. Custom actions are additional actions that users can execute on the alert. Each action has a limit of 50 characters, and a maximum of 10 custom actions can be defined for a single alert.

6. Description: This field allows for a more detailed, long-form description of the Alert. The description field can contain up to 15,000 characters. Similar to the Summary field, the description value can be updated later if necessary.

7. Extra properties: This field enables users to include additional key-value pairs of their choice, providing further customization and context to the alert. While there is no limit on the number of key-value pairs, the total length of the values should not exceed 8,000 characters.

State fields

1. Status: The status field reflects the current state of the alert. It is initially set as "Open" or "Unacknowledged" when the alert is created, and Jira Service Management keeps updating this field as the status or acknowledged state of the alert changes.

2. Responder states: This field displays the last known state of the responder users associated with the alert. It captures updates such as receiving notifications or executing actions. Jira Service Management continually updates these states to reflect the most recent information.

3. Notes: The notes field records any additional information or comments added by users via the "Add note" action. Jira Service Management updates this field whenever new notes are added.

4. Activity log: Jira Service Management maintains an activity log that chronologically captures all user and system activities related to an alert. This log provides a comprehensive record of actions such as alert creation, user interactions, notifications, and deduplication events. The alert activity log also tracks the status of SMS and voice notifications sent to alert responders. This ensures that responders are well informed about each stage of the alert's lifecycle. Admins can also check the activity log for a more detailed examination. You can also track which automation actions are executed on the alert as well.

   Overall the activity log offers valuable insights into the timeline and progression of the alert