Skip to content
1stLine Docs 1stLine Docs

Alert Instances

Alert Instances are the working alert records in 1stLine by Burava.

An Alert Event is one incoming payload. An Alert Instance is the alert record that 1stLine creates or updates from those events.

If repeated Alert Events produce the same fingerprint, 1stLine updates the same Alert Instance and increases Recurrences instead of creating a separate unrelated alert every time.

What Alert Instances are for

Open Alert Instances to investigate what happened to real alerts after ingestion.

Use Alert Instances to answer operational questions:

  • Did the Alert Schema extract the right fields?
  • Did repeated Alert Events group under the expected fingerprint?
  • Did Routing Rules send the alert into the expected Chain?
  • Did Escalation contact the expected responders?
  • Did a responder acknowledge, resolve, escalate further, start an Incident, join an Incident, or escalate to AI?
  • Did generated receiver links point back to the correct alert action?

What the details page helps you verify

Use the details page when you need to answer questions such as:

  • Did 1stLine create a new Alert Instance or update an existing one?
  • Did repeated Alert Events group under the same fingerprint?
  • Did the alert move through the expected escalation path?
  • Which responder or escalation step handled it?
  • Did the alert get acknowledged, resolved, or escalated further?

If you are building or adjusting a schema, this page is often the fastest way to confirm the real result after a live test alert.

Alert metrics

Alert Instance metrics are stored in seconds and displayed as durations.

MTTA means mean time to acknowledge for an Alert Instance. 1stLine sets it the first time the alert is acknowledged:

First acknowledged at - Alert Instance created at

Unacknowledging and acknowledging again does not reset MTTA. The metric keeps the first acknowledgement timing.

MTTD means mean time to detect. Alert Instance responses can include mttd_seconds when the backend has that value available, and the timeline displays it when present. Most current alert flows persist MTTA and MTTR for Alert Instances; MTTD is more commonly used on Incidents where 1stLine has Incident lifecycle timestamps.

MTTR means mean time to resolve for an Alert Instance. 1stLine sets it when the alert is resolved:

Resolved at - Alert Instance created at

If the alert has not been acknowledged or resolved yet, the matching metric is unavailable.

Alert timeline and escalation trail

The details page includes a timeline card that shows the alert history.

It can display:

  • lifecycle metrics such as MTTA, MTTD when available, and MTTR
  • the alert timeline history
  • the escalation trail, including which Lines were entered and how the escalation progressed

Use this view after live testing. Test Pattern Extraction validates extraction, but the Alert Instance timeline shows what happened after routing, forwarding, escalation, and responder actions.

Alert actions

For each Alert Instance, 1stLine can support these actions depending on your receiver and communication path:

  • Acknowledge
  • Unacknowledge
  • Resolve
  • Start incident
  • Join incident
  • Escalate to
  • Escalate Further
  • Escalate to AI

These actions can be available from:

  • the 1stLine UI
  • receiver messages where 1stLine injects action links
  • supported communication flows such as calls

Proceeding with an alert action from a receiver message means clicking a link injected into the payload by 1stLine.

When you click that link, 1stLine opens a new browser tab to register the action.

If you are not signed in to 1stLine in that browser session, 1stLine asks you to sign in, or if Allow Guest Acknowledgement is enabled for the schema, you can proceed as a guest.

When an Alert Instance is escalated to AI, the details page can show AI assignment or AI assignments.

Open those links to review the AI Response, matched rules, suggested actions, failures, and assignment status. See Review AI Escalation Assignments.

Guest Acknowledgement

Guest Acknowledgement allows a responder to acknowledge alerts without signing in to a Burava account.

This is useful when:

  • you acknowledge from a new device or browser session
  • the responder does not have a Burava account
  • you want acknowledgement to stay lightweight for external responders

This feature is disabled by default.

To enable it:

  1. Open Alert Schemas.
  2. Open your schema.
  3. Open Acknowledgement.
  4. Turn on Allow Guest Acknowledgement.
  5. Confirm the section change.

When Guest Acknowledgement is enabled, 1stLine creates a device session token so later alert actions from the same device or browser session can continue to use the guest flow.

When to use this page during setup

Use Alert Instances repeatedly while configuring 1stLine:

  • after creating or changing an Alert Schema
  • after changing Fingerprint Fields
  • after updating Routing Rules
  • after sending a real test alert
  • while checking whether an alert became Orphan or reached the expected Chain

If the alert content looks wrong here, go back to Alert Schemas. If the content is right but the alert reached the wrong responders, go to Routing Rules or Escalation.