> For the complete documentation index, see [llms.txt](https://docs.controltheory.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.controltheory.com/controltheory-documentation/dstl8-docs/incidents.md).

# Incidents

An incident is the unit Dstl8 uses to group everything it knows about a single problem in your system over a window of time. It is the container that holds the overall status, severity, time span, and a synthesized summary of what happened.

Most incidents and their events are created automatically by Möbius, the Dstl8 agent, as it analyzes your telemetry. You can also create an incident manually, which triggers Möbius to investigate it.

Each incident is made up of one or more events. An event is a single entry on the incident's timeline, scoped to one specific object such as a service, deployment, pod, or host. The relationship is one to many: an incident has many events, and every event belongs to exactly one incident.

### Incident (the parent)

The incident holds the aggregate view of the problem.

| Field                            | Description                                          |
| -------------------------------- | ---------------------------------------------------- |
| Title                            | Short description of the problem                     |
| Status                           | Workflow state in the incident lifecycle (see below) |
| Impact                           | Overall severity, for example major or critical      |
| Start / End time                 | The full window the incident spans                   |
| Summary / Description / Evidence | The rolled-up narrative of what happened             |

#### Incident lifecycle

An incident moves through a fixed set of workflow states:

`Open` → `Investigating` → `Active` → `Resolved` → `Closed`

This is a workflow state. It is not the same thing as an event's state, described below.

### Event (the child)

An event is one datapoint on the incident's timeline. Each event is anchored to a specific object and carries its own values, independent of the incident's aggregate.

| Field                     | Description                                              |
| ------------------------- | -------------------------------------------------------- |
| Object type / Object name | What the event is about (service, deployment, pod, host) |
| Impact                    | Per-event severity                                       |
| State                     | `open` or `resolved`, independent of the incident        |
| Start / End time          | The event's own, usually narrower, window                |
| Occurrences               | How many times the event fired                           |

### How incidents and events relate

* An incident says "something is wrong in this window, here is the overall status and story."
* Events are the individual symptoms on that incident's timeline. There is one event per object or symptom, and each event resolves independently.
* Because they are tracked separately, an event can be resolved while the incident is still moving through its lifecycle toward `Closed`.

A useful way to read it: incident status is a workflow state (`Open` through `Closed`), while an event's state is just `open` or `resolved`. They are different fields tracking different things.

### Creating an incident manually

While Möbius creates most incidents on its own, you can open one manually from the Incidents page. Creating an incident this way triggers Möbius to investigate it.

The form takes:

* **Workspace**: the workspace the incident belongs to.
* **Title**: a short description of the problem.
* **Summary**: a one-line summary.
* **Description** (optional): more detail.
* **Impact**: severity, defaulting to None.
* **Status**: starting lifecycle state, defaulting to Investigating.
* **Start Time**: when the incident began, defaulting to now.
* **End Time** (optional): leave empty for an ongoing incident.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.controltheory.com/controltheory-documentation/dstl8-docs/incidents.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.