Pager / On-Call Integration

Versus talks to the paging platforms operations teams already carry: PagerDuty, Opsgenie, Splunk On-Call (VictorOps), xMatters and OnPage. One vendor-neutral client covers all of them, so a workflow written against versus.integrations.pager() works unchanged when the team moves platforms.

Two things flow through it:

• Outbound paging — trigger, acknowledge and resolve incidents from a workflow step, the Observe alerting engine, or a Desk automation rule.
• The on-call roster — who is on call right now for a group, schedule or escalation policy, with escalation order and contact details, so a workflow can address the right human (or an agent can tell you who to call).

---

Adding a source

Integrations → Pager / On-Call → Add Pager Source. Credentials are encrypted at rest and never returned by the API; editing a source lets you leave a secret blank to keep it.

Test sends and immediately resolves a harmless test incident on vendors that page (PagerDuty, Splunk On-Call, xMatters), or reads the account on Opsgenie.

---

Who is on call

Every source except OnPage has an On-call button on its card. It shows one block per group / schedule / escalation policy with the current shift window and the members in escalation order — primary, secondary, then further escalation levels with their delay — plus e-mail and phone where the vendor exposes them. The filter box narrows by group name.

The badge on the panel says Live when the vendor answered, or Sample roster on a seeded demo source (below). A real source that cannot be reached shows the vendor's error instead of guessing.

---

Using it in workflows

pager = versus.integrations.pager()            # first enabled source, or pager('Prod PagerDuty')

# page
key = pager.critical('BIG-IP bigip2 sync failed after upgrade',
                     body=versus.get_input('detail'), component='bigip2', group='ADC')
# … later
pager.resolve(key)

# who should hear about it
primary = pager.who_is_on_call('ADC')          # {name, email, phone, group, policy, level, until}
if primary:
    versus.integrations.slack().message(f"Paging {primary['name']} ({primary['phone']}) for the ADC group")

# the full roster
for g in pager.on_call():
    names = ', '.join(f"{m['name']} ({m['level']})" for m in g['members'])
    versus.log(f"{g['group']} [{g['policy']}] until {g['end']}: {names}")

on_call(group=None) returns a list of groups, each with group, policy, start, end, url and members (position, level, delay_min, name, email, phone, role). on_call_report() adds provenance (origin of live, sample or error). The Generate with AI button in the Workflow Builder knows these methods.

In the Diagnostics AutoPilot the same lookup is the who_is_on_call tool, so an agent that has diagnosed a fault can finish with the name and number of the person who owns it.

---

Demo source and seeded roster

manage.py seed_xmatters_oncall (also run by the full seed_demo) creates an xMatters (Demo) source whose stored metadata carries a representative on-call roster — Network Operations, ADC / Load Balancing, Firewall & Security, Site Reliability and Change Advisory groups, each with primary / secondary / escalation members, shift windows and contact details — and a few recent events. The On-call panel, pager.on_call(), pager.get_incidents() and the AutoPilot tool serve that data until REST credentials are added to the source, and label it as sample data when they do. The roster itself lives on the source row (metadata.on_call), so it is real seeded data you can inspect through the API.

Real customer sources never fall back to the sample roster.

Related

• SLOs and On-Call — routing Observe alerts to these sources
• Cisco ISE Integration — identity context for the incidents you page about
• Workflow Builder