For the complete documentation index, see llms.txt. This page is also available as Markdown.

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:

OpenInvestigatingActiveResolvedClosed

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.

Last updated