# Incidents / Tasks Overview

> Source: https://docs.lorel.ai/en/guides/incidents-and-tasks/

This page explains how incidents are created from trigger rules, handled, and aggregated, and how tasks are created and generated on a schedule. It also covers the status, activity, search, and statistics features that both screens share.

## Overview

Lorel.ai handles incident response, from first response to resolution, and day-to-day operational work on two screens: "Incidents" and "Tasks."

- **Incidents**
  - Use this screen to manage and track the response to each incident, from first response to resolution, across organizations and projects, in one place.
  - Incidents are created automatically when a trigger rule (a detection rule, a compound rule, or a metric rule) fires, through an enabled incident policy. You can't create an incident manually.
  - Use the screen to move each phase of incident response forward: review cause analysis reports from AI agents and detection events, assign someone, advance the response status, and share updates with project members in comments.
  - On the [Overview] tab, you can check statistics such as the trend of incidents and the time to resolution.
- **Tasks**
  - Use this screen to plan, carry out, and track permanent fixes after an incident, periodic system checks, and day-to-day routine operational work.
  - You can create tasks manually one by one, generate recurring tasks automatically with a repeat setting, and also run linked Runbooks automatically. It is the working screen for carrying operational work through to completion: assigning people, managing due dates, updating progress status, and recording the work log in comments.

Incidents and tasks share the same foundation for status changes, assigning people, comments and mentions, and a chronological activity trail of what users, AI agents, and the system do. This page refers to incidents and tasks together as **tickets**.

## What you can do

The following table lists the features and operations that users and the system can perform when managing incidents and tasks.

| Target | Feature or operation | Description | Required role |
|---|---|---|---|
| Incident | Automatic creation when a trigger rule fires | Creates an incident automatically, through an enabled incident policy, based on the result of a trigger rule's detection. You can't create one manually. If an unresolved incident exists, Lorel.ai doesn't create a new one and adds the detection record to the existing incident. | Automatic (system) |
| Incident | Adding detection records to an unresolved incident | If an unresolved incident already exists for the same policy and the same rule (and the same identifier labels, if you specified them), Lorel.ai adds and aggregates the detection record (the occurrence history) in the same ticket, which prevents duplicate tickets. | Automatic (system) |
| Incident | Filtering incidents (Advanced) | Combine data source, rule, and policy conditions to filter incidents. | All project members |
| Incident | Statistics overview ([Overview] tab) | Check the total count, average MTTR (mean time to resolution), resolution rate, daily trend, and a ranking of responders over 7, 30, or 90 days. | All project members |
| Incident | Filter counts in Advanced | Check in advance how incidents are distributed for each filter condition along the three axes of data source, rule, and policy. | All project members |
| Task | Create a task manually | Create a task manually by specifying the title, description, severity, due date, assignee, repeat, and Runbook. | Project Administrator / Editor |
| Task | Automatic generation of recurring tasks | From a parent task that has a repeat setting, new child tasks are generated automatically on a schedule, following the cycle you set (daily, weekly, monthly, or yearly). | Automatic (system) |
| Task | Task-specific filter | Filter by whether a task has a repeat setting ([Recurring] or [One-off]). | All project members |
| Common | Status transitions | Move a ticket through its statuses with actions such as start, resolve, and reopen. For incidents, the [Escalated] status is also available. | Project Administrator / Editor / Worker (escalation: Project Administrator / Editor) |
| Common | Add comments and mentions | Post comments in Markdown. Use @ to mention a person and send a notification, and use I# or T# to link to another incident or task. | Project Administrator / Editor / Worker |
| Common | Update fields | Update only the fields you want to change, such as the assignee, title, and severity. | Project Administrator / Editor |
| Common | Delete | Delete a ticket you no longer need. Deletion is permanent. | Project Administrator / Editor |
| Common | View the operation history (activity) | Check the operation log in chronological order, with users, AI agents, and the system shown separately. You can also filter with the [All], [Comments], [AI], [Runbook], and [System] tabs. | All project members |
| Common | List, search, filter, and sort incidents and tasks | The list is paginated and supports free-text partial-match search, filtering by severity, status, and assignee, and sorting. | All project members |
| Common | List across projects | If you don't specify a project, the list shows the tickets from all the projects that you belong to (you can also filter by organization). | All project members |

## Automatic incident creation and aggregation

Lorel.ai creates incidents automatically when a trigger rule fires. You can't create an incident manually on the screen.

### How automatic creation works

- **What triggers creation.** An incident is created when a single detection rule fires, when the conditions of a compound rule are met, or when the conditions of a metric rule are met.
- **Working with policies.** An incident is created through an enabled incident policy. If a detection condition that is linked to a disabled policy fires, Lorel.ai doesn't create an incident.
- **Initial status.** Every incident is created with the status [Open].
- **Initial values.**
  - The title is set to the name of the incident policy that it came from (you can change it after creation).
  - The description is empty when the incident is created. You can't currently edit it on the screen.
  - The severity is set to the initial severity that is set in the policy.
  - The assignee is set to the initial assignee that is specified in the policy. If the specified assignee isn't a project member when the incident is created, the incident is [Unassigned], and the reason is recorded in the operation history.

### Aggregating alerts and adding to an incident (behavior on recurrence)

When the same alert occurs repeatedly in a short time, Lorel.ai aggregates them automatically to prevent duplicate tickets.

- **Aggregating into an unresolved incident.** If an unresolved incident ([Open], [In Progress], or [Escalated]) already exists for the same policy and the same rule (and the combination of identifier labels that you specify in the "How incidents are split" setting of the incident policy), Lorel.ai doesn't create a new incident. It adds the event that fired to the "Detection Records" list on the existing incident. For details, see [Rules Overview](/en/guides/rules/).
- **Relationship with resolved incidents.** If the corresponding past incident is [Resolved], Lorel.ai doesn't add to it and creates a new incident (you can't add a new detection record to a resolved incident).
- **Independence between projects.** Even with the same policy or detection condition, incidents are never aggregated into an incident in another project. Each project creates its own incidents independently.
- **AI agents and Runbooks when a record is added.** When a detection record is added to an existing incident, the cause analysis by an AI agent and the automatic execution of Runbooks don't run again. AI agent executions that are triggered by a status change that you specify in the policy (creation, resolution, or reopening; escalation can't currently be selected on the screen) run separately. Runbooks set as the policy default run automatically only when an incident is created.

## Creating tasks and generating them on a schedule

A task is a ticket for managing corrective work after an incident, periodic checks, routine operational work, and the like. You can create tasks manually, and Lorel.ai also supports generating them on a schedule with a repeat setting.

### Creating a task manually

Select [Add Task] on the "Tasks" screen and set the following fields to create a task. The task is created in the project of a Tasks screen that you opened for a specific project, and otherwise in the project selected in the sidebar (not the project you pick in the list filter). If neither is set, [Add Task] isn't shown.

- **Title (required).** Enter a name that briefly describes the work. You can't leave it empty.
- **Description (optional).** Enter the work procedure and background information as text (line breaks are kept, but Markdown syntax isn't formatted and appears as plain characters).
- **Severity (optional).** Select from [Critical], [High], [Medium], and [Low]. If you leave it as [Not set], it is set to [Low].
- **Due date (optional).** Specify the target date for completing the work. On the screen, you can specify only a date; you can't specify a time.
- **Assignee (optional).** You can specify an assignee from the project members. In the create dialog, you are selected as the assignee by default. If you clear the selection, the task is [Unassigned].
- **Repeat (optional).** To carry out the work periodically, specify the repeat cycle. If you don't specify one, it is [Does not repeat].
- **Runbook link (optional).** You can link a related Runbook (an execution procedure).

#### Linking a Runbook to a task

- **Existence check.** When you link a Runbook to a task, the Runbook must exist in the same project. You can't link a Runbook from another project or a Runbook that has already been deleted.
- **Linking a draft Runbook.** Currently, the selection list on the screen shows only Runbooks that are Active.
- **Removing a link.** You can remove a Runbook link at any time. After you remove it, the Runbook no longer runs automatically from the recurring task.

### Generating recurring tasks automatically (scheduled generation)

From a task that has a repeat setting, child tasks are generated automatically according to the cycle you set. Generation targets a parent task only while it is [Open]. If you set it to [In Progress] or [Resolved], generation stops.

- **How often the generation process runs.** The generation process runs every 5 minutes, and it targets the open parent tasks whose next generation time (the time when the next child task is scheduled to be generated) has passed.
- **Available cycles.** Select from [Does not repeat] (the default), [Daily], [Weekly], [Monthly], and [Yearly]. If you select anything other than [Does not repeat], you must specify a due date.
- **Automatic calculation of the next generation time.** A task that has a repeat setting gets its next generation time set automatically. If you change the due date or the repeat setting, the next generation time is recalculated from the change. The first child task is generated one cycle after the due date, not on the due date itself. Lorel.ai also corrects the next generation time automatically so that it is always in the future. So even if you specify a past date and time as the due date, the next generation time doesn't stay in the past.
- **Fields that are carried over from the parent task.** The following information is carried over to the child task automatically. The repeat setting of a child task is always generated as [Does not repeat].
  - Title
  - Description
  - Severity
  - Assignee
  - Runbook link
- **Setting the child's due date and updating the parent task.** The due date of the child task is set to the parent task's next generation time. After the child task is generated, the parent task's next generation time is advanced by one cycle, based on the time that the generation process ran. Even if generation was delayed, Lorel.ai doesn't generate the child tasks for the missed period all at once.
- **Automatic adjustment to the last day of the month.** For a monthly or yearly repeat, if the target day doesn't exist, it is adjusted automatically to the last day of that month (for example, for a monthly repeat based on January 31, February is the 28th, or the 29th in a leap year). From then on, the schedule advances one cycle at a time from the time the generation process ran, so it doesn't return to the original date (such as the 31st).
- **Re-checking the assignee.** When a child task is generated, Lorel.ai checks again that the assignee is a member of the target project. If the assignee is no longer a project member, the child task's assignee is [Unassigned], and the reason is recorded in the operation history.
- **Automatic Runbook execution and the existence check.** If a Runbook is linked to the parent task, that Runbook starts automatically when the child task is generated. However, it runs only when the Runbook is Active. If it is a Draft, for example, it doesn't run. Lorel.ai also checks that the Runbook exists when the child task is generated, and if the Runbook has been deleted or replaced with a Runbook from another project, it doesn't carry over the Runbook and doesn't run it. A Runbook that is linked to a one-off task doesn't run automatically.

## Operations and management common to tickets

Incidents and tasks share common operation and management rules.

### Status transitions

- **Types of status.** [Open], [In Progress], and [Resolved]. For incidents, [Escalated] is also available.
- **Transition rules.**
  - Start is the transition from [Open] to [In Progress] (the button is [Start]).
  - Resolve is the transition from [In Progress] to [Resolved].
  - Reopen is the transition from [Resolved] to [Open].
  - Only for incidents, [Escalate] moves an incident from [Open] or [In Progress] to [Escalated]. You must choose one user as the recipient, and that user becomes the assignee. From [Escalated], you can return to [In Progress] with [Resume]. You can resolve an incident only from [In Progress].
  - You can't run transitions other than the defined ones.
- **Restriction when reopening an incident.** When you reopen an incident, you can't reopen it if an unresolved incident for the same detection condition already exists. In the error, Lorel.ai shows a link that uses the title of the conflicting incident.
- **Operations on resolved tickets.** You can still do the following on a resolved ticket (the only thing you can't do is add a detection record to a resolved incident):
  - Post a comment
  - Update the title
  - Update the description (currently, on the screen, only for tasks)
  - Change the severity
  - Change the assignee

### Posting comments

- **Length.** You can enter 1 to 10,000 characters (you can't post an empty comment).
- **Markdown support.** Formatting such as bold, italic, inline code, code blocks, bulleted lists, quotes, and tables is supported. The editing modes are a rich text editor and a Markdown text editor. In the Markdown text editor, you can check the display in a preview before you post. However, if a comment contains an @ mention or an I# / T# citation, the whole comment is shown as plain text and Markdown syntax isn't formatted. Only the mentions and citation links are shown as chips.
- **Shortcodes.**
  - **Mentions with @.** When you type @, a list of project members appears. Lorel.ai sends a mention notification to the user you select. The notification body includes the first 200 characters of the comment. If you mention the same user more than once in the same comment, that user gets one notification. If you mention yourself, you also get a notification.
  - **Citations with I# or T#.** When you type I# or T#, candidates appear and are narrowed as you keep typing. When you select a candidate, you can insert a link to that ticket.

### Specifying an assignee

- When you specify or change an assignee, the target user must be a member of that project (this applies both when you create and when you update).
- You can change the assignee to [Unassigned] at any time.

### Updating content

- You can't leave the severity empty.
- You can leave an incident's title empty, but you can't leave a task's title empty.
- You can't leave a task's repeat setting empty.
- You can clear the description and the assignee, and for tasks the due date and the Runbook link, by leaving them empty (currently, on the screen, you can edit a description only for tasks).
- For a task whose repeat setting isn't [Does not repeat], you can't clear the due date, unless you change the repeat setting to [Does not repeat] in the same update.

### Deleting

- A ticket and its operation history are deleted permanently. You can't restore them after deletion.
- When a ticket is deleted, Lorel.ai notifies its assignee, unless the assignee is the person who deleted it. If there is no assignee, nobody is notified. Whether you receive the notification follows your notification settings.

## Operation history (activity)

Every operation that is performed on a ticket is recorded in order of occurrence as a timeline. Records are only appended, and they are never rewritten later.

### How to view the operation history

- **Timeline on the detail screen.** When you open the detail screen of an incident or a task, the series of operations linked to that ticket appears in a timeline.
- **Difference from the audit log.** The operation history records the work and status changes that are performed on each ticket. It differs in recorded scope and viewing permissions from the audit log, which is the trail of important operations related to security and governance across the whole organization.

### Recorded operations and targets

Each record is tagged with one of "Human," "AI Agent," or "System" as the type of actor that performed the operation. Behavior that doesn't involve a user operation, such as the automatic creation of an incident or the automatic generation of a recurring task, is recorded as done by "System."

| Recorded operation | Incident | Task | Main content recorded |
|---|---|---|---|
| Creation (ticket creation) | Yes | Yes | For an incident: the name and type of the detection rule that fired, the provider and type, the firing condition, a summary of the measured value, and the reason the initial assignee is unassigned. For a task: the actor, and the reason the assignee is unassigned when it was generated on a schedule |
| Adding a detection record | Yes | — | The name and type of the detection rule that fired, the provider and type, the firing condition (target attribute, operator, threshold, and actual value), a summary of the measured value, details of the repeated detection, and the content of the telemetry event (while a metric rule keeps detecting, a record that is added within a set time of the previous detection is added to the detection records but isn't recorded in the activity; that time is normally 5 minutes; when the interval at which the metric's data actually arrives (the collection interval, as measured by Lorel.ai) is longer than 2.5 minutes, it is twice that interval, up to 2 hours; until a measured value is available, which takes two data points, it is 5 minutes) |
| Status change | Yes | Yes | The status before and after, and the person who operated |
| Assignee change | Yes | Yes | The assignee before and after (recorded only when the value actually changes) |
| Title change | Yes | Yes | The title before and after (recorded only when the value actually changes) |
| Severity change | Yes | Yes | The severity before and after (recorded only when the value actually changes) |
| Adding a comment | Yes | Yes | The poster, the body, and the mention and citation links |
| Runbook execution | Yes | Yes | The name of the Runbook that ran, and the completed status (recorded once, when the execution completes; failed or cancelled executions aren't recorded) |
| AI agent execution status | Yes | — | The execution status (running, completed, failed, skipped, approval expired, or rejected), whether a retry is possible, the error (when it failed), the reason for skipping (when it was skipped), and the person who approved or rejected |
| Due date change | — | Yes | The due date before and after (recorded only when the value actually changes) |
| Repeat setting change | — | Yes | The repeat cycle before and after (recorded only when the value actually changes) |
| Runbook link change | — | Yes | Whether a Runbook was linked, unlinked, or changed (the screen doesn't show the Runbook name; recorded only when the value actually changes) |

- **Rule for recording changes.** Changes to the title, severity, and assignee, and changes to a task's due date, repeat setting, and Runbook link, are recorded only when the value actually changes. If you update with the same content without changing the value, the operation history doesn't grow.
- **Exceptions.** A change to the description isn't recorded in the operation history. Also, when you delete a ticket, the ticket itself is gone, so no history remains.
- **Recording of AI agent executions.** While an execution waits for approval, the screen shows that the action is awaiting approval, but that state isn't recorded in the history. Also, only production runs that were started from an incident are recorded, and test runs aren't recorded.

### Filtering with tabs

On the detail screens of incidents and tasks, you can filter the operation history with the [All], [Comments], [AI], [Runbook], and [System] tabs.

- [Comments] shows comments written by people.
- [AI] shows comments and executions by AI agents.
- [Runbook] shows Runbook executions.
- [System] shows everything else, including status and assignee changes made by people.

## Listing, searching, and filtering

On the "Incidents" and "Tasks" screens, you can search a large number of tickets for the one you want, and manage them efficiently while you filter and sort.

### The scope of the list and how it is displayed

- **Specifying a project and showing across projects.** If you don't specify a project, the list shows the tickets from all the projects that you belong to. If you specify a project, only that project is targeted.
- **When you don't belong to any project.** If you don't belong to any project, the list is empty (0 items).
- **The initial display.** The initial display shows your own tickets, excluding resolved ones. On the "Incidents" screen, Lorel.ai remembers your previous filter conditions and sort order (except the search text and the Advanced selections). It doesn't remember them on the "Tasks" screen. The remembered settings are stored in your browser and aren't synced between devices.

### The columns of the list

The list table shows the following information. You can sort by some columns by selecting the column header.

| Column | Incident | Task | What it shows |
|---|---|---|---|
| Severity | Yes | Yes | Shows a severity icon (Critical, High, Medium, or Low). Sorting is supported. |
| Status | Yes | Yes | Shows the current response status as a badge. Sorting is supported. Incidents: [Open], [In Progress], [Escalated], [Resolved]. Tasks: [Open], [In Progress], [Resolved]. |
| Title | Yes | Yes | Shows the title of the ticket. For incidents, an icon that shows the type of detection rule appears. Sorting is supported. |
| Organization | Yes | Yes | Shows the name of the organization it belongs to. It appears only on lists that aren't scoped to a project, so you can identify the organization when the list shows tickets across projects. |
| Project | Yes | Yes | Shows the name of the project it belongs to. It appears only on lists that aren't scoped to a project. |
| Assignee | Yes | Yes | Shows the name of the person currently assigned. It is blank if unassigned. |
| Due date | — | Yes | Shows the due date of the task. |
| Last updated | Yes | Yes | Shows the time since the last update (for example, 3 days ago). Sorting is supported. |

### Filters and quick filters at the top of the screen

The top of the list screen has filters that help you find the tickets you want quickly.

#### Status badges (quick filters)

Select a badge to show only the tickets that have that status. You can select multiple statuses at the same time, and [All] clears the selection. Each badge shows the matching count in real time.

- For incidents, the badges are [All], [Open], [In Progress], [Escalated], and [Resolved].
- For tasks, the badges are [All], [Open], [In Progress], and [Resolved].

[Mine only] shows only the tickets that are assigned to the user who is logged in.

#### The filter bar

- **Search.** Search for tickets with free text.
- **Project.** Filter by specifying an organization and a project. If you don't specify one, the list shows the tickets from all the projects that you belong to. If you specify a project, it shows only that project's tickets.
- **Severity.** Filter by [All], [Critical], [High], [Medium], or [Low].
- **Assignee.** Filter by specifying an assignee. You can specify a particular assignee, or select [Unassigned].
- **Repeat (Tasks screen only).** Filter by whether the task has a repeat setting ([All], [Recurring], or [One-off]).
- **Advanced (Incidents screen only).** When you select it, a detailed filter panel opens directly below. Combine the following conditions to filter.
  - **Data Source.** Filter by the provider, and the Source type under it.
  - **Rule.** Filter by a trigger rule (a detection rule, a compound rule, or a metric rule).
  - **Policy.** Filter by an incident policy.
  - You can select multiple items for each of Data Source, Rule, and Policy with the check boxes. Each column has a search box at the top, and each item shows the matching count in real time.

#### Free-text search

- You can enter a search string of 2 to 255 characters.
- The search is a case-insensitive partial match.
- `%` and `_` aren't treated as wildcards. They are treated as part of the search string as they are.
- For incidents, the search covers the title, the description, and the names of the detection rules and compound rules that fired (the names of metric rules aren't searched).
- For tasks, the search covers the title and the description.

### Sorting

- You sort by selecting a column header. You can sort by severity, status, last updated, and title. For each, you can switch between ascending and descending order.
- The default sort on the screen is last updated, newest first (descending), for both incidents and tasks.
- Severity (ascending) is Critical, High, Medium, Low.
- Status (ascending) is Open, In Progress, Escalated (incidents only), Resolved.
- When you sort tasks by severity in ascending order, the open tasks are gathered at the top, and each group is shown in severity order.
- When you sort by title, incidents that have no title always appear at the end of the list, in both ascending and descending order.

## Incident statistics overview ([Overview] tab)

On the [Overview] tab of the "Incidents" screen, you can visualize and analyze the trend of incidents, the speed of response, the distribution of severity, and the team's response results at a glance.

### Conditions for retrieving the data

- **Period.** Select from three options: [7 Days], [30 Days] (the default), and [90 Days] (you can't specify a custom period). For organizations on the Starter plan, only 7 days can be selected on the screen.
- **Aggregation window boundaries.** The aggregation window covers exactly the selected number of days back from the current time; it isn't rounded to calendar-day boundaries. The start time is included in the count, and the current moment is not. The exception is the Daily Trend and the mini graphs, which aggregate by date (one bucket per date; the first and last dates may be partial).
- **Target projects and aggregation across projects.** The screen aggregates across all the projects that you belong to. If you don't belong to any project, every item is 0.
- **Population.** In principle, it is the incidents that were created within the period (only the average resolution time targets incidents whose current status is resolved, and the resolved count in the daily trend is based on the day of resolution).
- **Limits on filter conditions.** You can't specify filter conditions for the statistics overview. You can't filter by severity, status, assignee, data source, and so on (this differs from the list and Advanced).

### Key metrics

| Metric | Definition (population and how it is calculated) | When there is no value |
|---|---|---|
| Total Incidents | The number of incidents that were created within the period | 0 |
| Avg MTTR (mean time to resolution) | For the incidents created within the period whose current status is resolved and that have a recorded resolution time, the average of the resolution time minus the creation time | No value |
| Resolution Rate | The resolved count divided by the total count | No value |
| Open Backlog | The total of the incidents created within the period whose current status is [Open], [In Progress], or [Escalated] (the breakdown is shown alongside) | 0 |

- **Comparison with the previous period (rate of change).** For Total Incidents and Avg MTTR, the screen shows the rate of change from the value in the immediately preceding period of the same length. The Resolution Rate card shows the change in the resolved count compared with the previous period (if the previous period is 0 or has no value, the rate of change isn't shown).
- **How reopening is calculated.** When you reopen an incident, its resolution time is cleared and it is temporarily removed from the Avg MTTR aggregation. When it is resolved again, it is recalculated as the time from the original creation time to the last resolution time.

### Charts and analysis sections

These are the detailed analysis charts and rankings at the bottom of the screen.

| Section or chart | Viewpoint or unit of aggregation | Values included | Order and display |
|---|---|---|---|
| "Daily Trend" (Created / Resolved) | By day (based on creation date and on resolution date) | The number created (new) and the number resolved | Ascending by date (aggregated by date). Days with no incidents still appear, with a value of 0. |
| "Severity Distribution" | Severity (Critical, High, Medium, Low) | The number of incidents for each severity, and the share of the total (composition ratio) | Fixed order: Critical, High, Medium, Low. A severity with 0 isn't shown. |
| "Avg MTTR by Severity" | Severity (Critical, High, Medium, Low) | The average time to resolution (MTTR) for each severity | Fixed order: Critical, High, Medium, Low. A severity that has 0 incidents isn't shown. A severity that has no resolved incidents is shown as "—." |
| "Top Responders" | The current assignee | The "Resolved" count, the average MTTR, and the assignee's name (the email address if no name is set) | In descending order of resolved count (ties are ordered by shorter average MTTR). Up to 10. |
| "By Org / Project" | Organization and project | The total count, the "Open" count, the average MTTR, and the organization name | In descending order of total incidents. |

- **Daily Trend and the metric cards.** The Daily Trend chart shows two series, created and resolved. The mini graphs on the metric cards show a simple day-by-day trend.
- **Hiding items that are 0.** In "Severity Distribution," "Avg MTTR by Severity," and "By Org / Project," rows and items that have a count of 0 aren't shown. "Top Responders" shows a person even with 0 resolved if there are incidents assigned to them.
- **Rules for counting "Top Responders."**
  - The responder is the current assignee, not the user who performed the resolve operation. If you reassign the incident after it is resolved, the result is counted for the new assignee.
  - Incidents that are unassigned are excluded from the ranking.
- **Common rule for calculating MTTR.** In every section, the average MTTR is calculated only from incidents whose current status is [Resolved].

## Filter counts in Advanced

This feature counts the incidents for each filter candidate in advance, so that before you select a condition, you can check how many incidents match each condition. Each item has three parts: the value used for filtering, the label shown on the screen, and the count.

### Axes and structure of the aggregation

| Axis | Unit of an item | Whether there is a hierarchy (breakdown) |
|---|---|---|
| Data Source | The service that provides the Source (AWS, DATADOG, and so on; shown in uppercase) | Yes (a breakdown by Source type that belongs to that provider) |
| Rule | The trigger rule that fired the incident (a detection rule, a compound rule, or a metric rule) | No |
| Policy | The policy that created the incident | No |

### Display rules and how the aggregation behaves

- **Linking with the filter conditions of the list.** The counts reflect the same filter conditions that are specified at the top of the incident list (such as status, severity, assignee, and project). The free-text search covers the title and the description.
- **Listing by count and the limit.** The three axes and the breakdown under a provider are all fixed in descending order of count (users can't change the order). There is no limit to the number of candidates shown, and every matching item is shown. Items that have a count of 0 aren't shown on the screen.
- **Counts with the axis's own filter removed.** The count for each axis is counted with that axis's own filter removed. This lets you compare in advance how many incidents there would be if you switched to another candidate, even while you are filtering by some condition. For the provider axis, both the provider filter and the Source type filter are removed for the count.
- **How the breakdown under a provider is displayed.** The unit of filtering for the breakdown is the Source type, but the label shows the display name of the Source. If you registered multiple Sources of the same type with different display names, the breakdown is counted and shown for each display name (whichever you select, the filter applies by type).
- **Totals and duplicates on the provider axis.** The count of each item excludes duplicate incidents, but a provider's count is calculated as the total of its breakdown. If one incident spans multiple Sources of the same provider (for example, with a compound rule), it is counted more than once, so the total of an axis can be larger than the total number of target incidents.
- **Showing the identifier of a deleted item.** Even if a detection rule or an incident policy has already been deleted and its name can't be resolved, its count isn't dropped from the aggregation. The identifier (ID) appears instead of the name.
- **Counts for past incidents don't change.** The aggregation targets the combination of Sources that was recorded when the incident was created. Even if you change the Source settings after that, the counts for incidents that were created in the past don't move to another item. However, the display name and the type label show the current settings, and deleted Sources don't appear in the breakdown.

## Retention

- Incidents and tasks are not deleted automatically when a retention period elapses. They are deleted only when a user deletes them, when the project they belong to is deleted, or when the organization's contract ends and its data is removed.
- There is no plan limit on the number of incidents and tasks that you can keep. However, the amount of data that you store counts toward usage-based storage billing.
- If you delete a project, the incidents and tasks that belong to the project are permanently deleted by the system after a grace period (currently 3 days). During the grace period you still can't view or operate on them, because you can't access the project itself. A deleted project can't be restored.

For details, see [Data Handling](/en/specifications/data-handling/).

## Roles and permissions

The following table lists the project roles that can perform each operation in incident and task management.

| Operation | Required role |
|---|---|
| View the list, details, operation history, statistics overview, and filter counts in Advanced | All project members |
| Change the status (start, resolve, reopen) and post comments | Project Administrator / Editor / Worker |
| Escalate (incidents only) | Project Administrator / Editor |
| Update, delete, and create tasks | Project Administrator / Editor |

Note: Depending on your contract's payment status, some operations can be restricted. When a payment is late, you can't create new tasks, change a task's repeat setting, or change a task's Runbook link. Deleting, commenting, and changing the status remain available. For an organization whose contract has ended and that is in the data export period, no write operation is possible, including comments and status changes. For details, see [Restrictions When Payment Is Delayed](/en/specifications/billing-payment-delay/).

For details, see [Roles and Permissions](/en/getting-started/roles-and-permissions/).

## Limitations

- **You can't create incidents manually.** Incidents are created only by being generated automatically, starting from a trigger rule (a detection rule, a compound rule, or a metric rule) firing. There is no way to create one manually.
- **You can't add to a resolved incident.** You can't add a new detection record to a resolved incident (when the problem recurs, a new incident is created separately).
- **Restriction on reopening due to a conflict.** If an unresolved incident for the same combination of detections already exists, you can't reopen the incident, and an error occurs.
- **Deleting can't be undone.** Deleting a ticket is permanent and can't be undone. No history of the delete operation remains.
- **Child tasks are fixed as one-off.** You can't give a repeat setting to a child task that was generated automatically from a recurring task (it is always treated as [Does not repeat]).
- **Generation isn't caught up in bulk after a backlog.** The automatic generation of recurring tasks doesn't generate the past occurrences all at once, even if generation was delayed.
- **Limits on filtering in the statistics overview.** You can't specify filter conditions (such as severity or assignee) for the incident statistics overview.
- **The period of the statistics overview is fixed.** The period of the incident statistics overview is one of 7, 30, or 90 days, and you can't specify an arbitrary period (a custom period).
- **Changes to the description aren't kept in the history.** A change to the description isn't recorded in the operation history (activity).

## Related features

- [Rules Overview](/en/guides/rules/) (the detection rules, metric rules, and compound rules that trigger automatic incident creation, and the incident policies where you set the initial severity, the initial assignee, and the agent that runs automatically)
- [AI Agents Overview](/en/guides/ai-agents/) (agents that analyze the cause of a created incident and take the first response automatically)
- [Runbooks Overview](/en/guides/runbooks/) (procedures that run manually or automatically from tasks and incidents)
- [Integration Overview](/en/guides/integration/) (the Sources that detect incidents)
- [Roles and Permissions](/en/getting-started/roles-and-permissions/) (details of the Project Administrator, Editor, Worker, and Viewer roles that you need to operate tickets)