Skip to content
1stLine Docs 1stLine Docs

Troubleshooting

This page covers common Escalation issues in 1stLine by Burava and the fastest checks to run before changing the model.

An alert stays Orphan

If an Alert Instance stays Orphan, the alert reached 1stLine but no Routing Rule claimed it.

Check:

  1. the alert appears in Alert Instances
  2. the needed fields were extracted by the Alert Schema
  3. a Routing Rule exists for that alert
  4. the rule points to the intended Escalation Chain
  5. the rule conditions are broad enough for the first test

Start broad, confirm the path works, then tighten the conditions.

The wrong Chain is being used

Usually this means the Routing Conditions are too broad or the wrong fields are being matched.

Check:

  • the rule conditions
  • whether Is Priority should be enabled for P priority comparisons
  • whether schema scope should be set
  • whether the extracted field values match what you expect
  • whether another rule is claiming the alert first

A Chain looks correct, but the path still behaves unexpectedly

Check:

  • line order
  • timeout
  • Member Order
  • any Chain Conditions
  • whether the intended Line Members were actually added

Then use Preview Escalation on the Chain or Routing Rule details page to confirm the structure.

Preview Escalation is the fastest way to verify what 1stLine thinks the path should be before you spend time debugging a live alert run.

Preview Escalation is the fastest way to verify what 1stLine thinks the path should be before you debug a live alert run.

A Schedule member is not behaving as expected

Check:

  • the Schedule Timezone
  • rotation start
  • Shift Length
  • Rotation Interval
  • whether the expected user is in Rotation Members
  • whether an Override is active for that time window

Always verify the Schedule Timeline after schedule changes.

An Override does not take effect when expected

Check:

  • the override start and end time
  • the schedule timezone
  • whether you saved the override on the intended Schedule
  • whether the override window overlaps the time you are testing

If the window is correct but the active responder still looks wrong, recheck the Schedule Timeline first before changing the rotation.

A Line Member cannot be saved with Repeat Interval

If a repeat interval is set, add a Communication Rule.

The Line Member editor requires a Communication Rule for repeat behavior.

A Schedule Line Member is missing the expected responder

Check:

  • Member Type is really set to Schedule
  • the correct Schedule was selected
  • the schedule has valid rotation members
  • the expected user is active at the test time

If you only need a temporary replacement, use an Override instead of editing the full rotation.