Sazabi and Splunk On-Call: page your VictorOps rotation from Sazabi issues

Last verified on Nov 8, 2026.

Splunk On-Call, formerly VictorOps, holds the rotations and escalation policies a lot of teams still page from. Sazabi is AI-native observability and security. When one of its issues should reach a person on that rotation, this integration sends it over a plain REST endpoint and cleans up after itself when the issue closes.

What Sazabi does with Splunk On-Call

Splunk On-Call is a shared notification channel. You enable the REST endpoint integration in Splunk On-Call, copy its endpoint URL and your API ID, and paste both into Sazabi. The URL looks like https://alert.victorops.com/integrations/generic/..., and Sazabi rejects anything that is not HTTPS on a VictorOps or Splunk On-Call domain.

Then a delivery rule on the project's notification settings sends an event type, such as Issue triggered, to the Splunk On-Call destination. Like every Sazabi rule it can add component, owning-team or severity conditions. Sazabi triggers a Splunk On-Call incident as the issue opens and resolves it as the issue closes, mapping issue severity to the Splunk On-Call message type.

That mapping matters because message types are how Splunk On-Call decides whether to page. According to its incident fields glossary, CRITICAL opens an incident and sets off an escalation policy, WARNING may open one depending on your alert configuration, and INFO only adds a timeline entry. ACKNOWLEDGEMENT moves an incident to acknowledged and stops paging. RECOVERY or OK resolves it.

Questions it answers

• Does a medium-severity Sazabi issue page anyone, or only land in the timeline?
• Which incidents in Splunk On-Call came from Sazabi, and are any still open after the issue resolved?
• Which delivery rule sends this component's issues to the on-call rotation?
• Why was an endpoint URL rejected when connecting?
• What should the incident look like in Splunk On-Call after a test issue?

A worked example: verify the loop with a test issue

You connect the integration and want proof before trusting it at 3 a.m. The Sazabi docs give a simple check, and the Splunk On-Call field names tell you what to look for.

Step 1  Delivery rule: Issue triggered (severity: high, critical) -> Splunk On-Call
Step 2  Trigger a test issue that matches the rule
        -> an incident appears in Splunk On-Call within a minute
        -> its message type reflects the issue's severity
Step 3  Resolve the Sazabi issue
        -> the same incident resolves (the RECOVERY behavior in Splunk On-Call's terms)

On Splunk On-Call's side, the incident's identity is its entity_id. The REST endpoint documentation says that field must stay the same across trigger, acknowledge and resolve, and that a random string is used when none is sent. Only message_type is required, and the endpoint accepts an HTTPS POST in JSON from any source.

Sazabi's docs have you enter only the endpoint URL and API ID, so you never set these fields yourself. They are useful when something looks wrong. An incident that opened as a timeline entry rather than a page points to the message type. An incident that never resolved points to a condition or rule that excluded the closing event. The Sazabi docs say to confirm the rule names both the event type and the Splunk On-Call destination, and that no condition excludes the issue.

How it fits with other integrations

Splunk On-Call is one of several places an issue can go to wake someone. PagerDuty, Rootly and incident.io cover the same job on other platforms. For discussion in a channel, add Slack or Microsoft Teams. The integrations index lists everything Sazabi connects to, and pricing covers plans.