Skip to content
1stLine Docs 1stLine Docs

Incidents

Incidents in 1stLine by Burava are shared response records for situations that need more coordination than one alert action.

An Incident is connected to an Alert Instance. That Alert Instance may be the live alert that started the incident, or it may be an Alert Instance created from a manual incident schema. This connection matters because Alert Schemas control how incident data is turned into alert payloads, how lifecycle updates are mapped, and whether lifecycle changes create additional alerts.

Open Incidents to work with incidents.

When to use an Incident

Use an Incident when the team needs a shared response object, for example:

  • several people need to join the same response
  • the alert needs investigation beyond acknowledge or resolve
  • the team wants a durable history of status, priority, metric, and postmortem changes
  • incident lifecycle changes should run Incident Actions
  • incident lifecycle changes should produce alert-side updates through Incident Lifecycle Mapping
  • the team wants a Postmortem after the response

How incidents start

1stLine supports two main incident start paths:

  • Start incident from an existing Alert Instance.
  • Start incident from the Incidents page for a manual incident.

These two paths use Alert Schemas differently.

Incidents started from Alert Instances

When you start an Incident from an Alert Instance, the Incident stays connected to that source Alert Instance.

The Incident uses the Alert Schema that received the source Alert Instance:

  • the Incident detected time starts from the Alert Instance creation time
  • the Incident can copy source alert context into the Incident
  • the schema’s created Incident Lifecycle Mapping can provide the Incident title, description, priority, and labels
  • later Incident lifecycle updates use that same schema’s Incident Lifecycle Mapping

This means the schema that receives the alert is also the schema that controls incident lifecycle behavior for incidents started from that alert.

Manual incidents and incident templates

Manual incidents start from a selected enabled Alert Schema. In practice, you can create Alert Schemas that are reserved for manual incident start.

Each reserved schema can act like an incident template:

  • the schema sample payload gives 1stLine a payload shape for the generated incident alert
  • schema patterns tell 1stLine where incident fields belong
  • the manual start form can prefill title, priority, description, and labels from the schema
  • the generated Alert Instance becomes the Incident’s linked alert record

Creating multiple manual incident schemas gives you different incident templates for different use cases. For example, you might have one schema for security incidents, one for customer-impacting production incidents, and one for data pipeline incidents.

See Incident Schema for Manual Incident Creation for the setup flow.

Incident lifecycle alerts

An Incident can produce additional alert-side messages when lifecycle changes happen.

This is configured on the related Alert Schema with Incident Lifecycle Mapping. Supported lifecycle triggers are:

  • created
  • reopened
  • resolved
  • closed
  • priority_changed

For each trigger, the mapping can update fields such as title, description, status, incident link, and custom override paths. It can also control whether 1stLine should only send an alert-side notification, register a new Alert Instance, or do both.

When Register Alert is enabled for a lifecycle trigger, the generated Alert Instance is counted toward your Alert Events limit. When Send Alert is enabled, 1stLine forwards the lifecycle payload to the same receiver path used by the source alert when possible, or to the schema’s Default Forward To if no source destination exists.

Use this when your receiver should show a new or updated message for incident creation, resolution, reopening, closing, or priority changes.

Where incident lifecycle alerts are forwarded

Incident lifecycle alerts use the forwarding settings from the Alert Schema connected to the Incident.

For an Incident started from an existing Alert Instance, 1stLine uses the source Alert Instance and its schema:

  1. If the original Alert Producer request included forwardTo, lifecycle updates use that same destination.
  2. If the original request did not include forwardTo, lifecycle updates use the schema’s Default Forward To.
  3. If neither forwardTo nor Default Forward To is available, there is no receiver destination for a forwarded lifecycle update.

For a manual Incident, 1stLine first creates an Alert Instance from the selected incident schema. Lifecycle updates then follow the same rule for that generated Alert Instance and schema.

This is critical when you want Incident lifecycle messages to appear in Slack, another receiver, or another webhook destination. Set Default Forward To on incident schemas that should always send lifecycle updates even when there is no producer-supplied forwardTo.

Incident metrics

Incident metrics are stored in seconds and displayed as durations.

MTTA means mean time to acknowledge for an Incident. In 1stLine Incident metrics, it is the time from the Incident’s start point to the first Join the incident event. The start point is chosen in this order:

  1. Detected at
  2. Started at
  3. Incident creation time

If nobody has joined the Incident yet, MTTA is unavailable.

MTTD means mean time to detect. 1stLine computes it from Detected at and the earliest available start signal:

  • if Started at exists and is before or equal to Detected at, MTTD is Detected at - Started at
  • otherwise, if the Incident creation time is after Detected at, MTTD is 0
  • otherwise, MTTD is Detected at - Incident created at

MTTR means mean time to resolve. 1stLine computes it as:

Resolved at - (Detected at, or Started at, or Incident created at)

If there is no resolved timestamp, or if the resolved timestamp is earlier than the chosen start point, MTTR is unavailable.

Timestamp overrides

The Incident Metrics tab lets you edit:

  • Detected at
  • Started at
  • Resolved at
  • Timestamp override note

These timestamp fields are overrides. Use them when the real timeline is different from the automatic timestamps captured by 1stLine.

Automatic lifecycle timestamps come from status changes:

  • changing status to investigating or in_progress sets Started at when it is blank
  • changing status to resolved sets Resolved at
  • reopening a resolved Incident clears Resolved at
  • changing status to closed sets Closed at when it is blank

When you edit Detected at, Started at, or Resolved at, the metric calculations use the edited values instead of relying only on automatic lifecycle timestamps. Add a Timestamp override note so the team understands why the timeline was changed.

Incident Actions

Incident Actions are separate from schema lifecycle alerts.

Incident Actions run saved actions when incident lifecycle events happen. They can create notes or call webhooks, and they can be scoped by schema and conditions.

Use Incident Actions when another system needs to be notified by a webhook, or when you want an incident note created from a lifecycle event. Use Incident Lifecycle Mapping when the alert receiver should receive an alert-shaped lifecycle update.

Status and priority

The incident status values are:

  • open
  • investigating
  • in_progress
  • resolved
  • closed

The incident priority values are:

  • P1
  • P2
  • P3
  • P4
  • P5

Use status for response stage and priority for urgency.