Routing rules already knew what fired. Now they know who's actually on call before they page anyone.

We shipped HelixQL-based routing rules in January, and the very next request from nearly every customer who adopted them was some version of "can this also know who's on call right now, so it doesn't page someone on vacation." Fair. It shipped this quarter.

Schedules as a queryable object

Helix now ingests on-call schedules from PagerDuty and Opsgenie (or a native schedule if you'd rather manage it here) as a queryable object, so routing rules can reference the current on-call person or escalation tier directly instead of a static team name:

route "payments-critical" {
  when: alert.severity == "critical" and team == "payments"
  to: oncall("payments-primary")
  escalate_after: 5m to oncall("payments-secondary")
}

Escalation that actually escalates

The escalation clause was the harder engineering problem: it needs to track acknowledgment state, re-check the schedule (because on-call can rotate mid-incident on a long one), and avoid double-paging if the primary acknowledges a second before the escalation timer fires. We built this on the same event log that powers our audit trail, so every escalation decision is inspectable after the fact.

What this fixed in practice

Before this, teams maintained the on-call schedule in PagerDuty and a separate, manually-updated team roster in their alert routing config — and the two drifted, typically after a hiring change or a rotation swap nobody remembered to propagate. One customer found their routing config was pointing at someone who'd left the team four months earlier.

The edge case that took the longest to get right

Long-running incidents that cross a shift handoff were the hardest part of this to build well: an alert that fires at 11:58pm and escalates at 12:03am needs to reliably re-resolve who's on call across that rotation boundary without double-paging both the outgoing and incoming engineer. We settled on re-evaluating the schedule at the moment an escalation actually fires rather than caching who was on call when the alert first triggered, which matches what on-call engineers told us they'd expect intuitively even though it complicated the implementation.

  • Routing rules reference live on-call schedules, not static team rosters
  • Escalation with acknowledgment tracking and mid-incident rotation awareness
  • Native schedule support, or sync from PagerDuty/Opsgenie
  • Full escalation decision audit trail per incident