Use when working with Victorops — splunk On-Call (VictorOps) incident management covering incident timeline visualization, routing key configuration, escalation policies, on-call scheduling, team management, and alert rules. Use when managing VictorOps routing keys, reviewing incident timelines, configuring escalation workflows, or analyzing on-call rotations.
Manage Splunk On-Call incident timelines, routing keys, escalation policies, and on-call schedules.
All API calls use X-VO-Api-Id and X-VO-Api-Key headers — injected automatically. Never hardcode credentials.
https://api.victorops.com
#!/bin/bash
vo_api() {
local method="$1"
local endpoint="$2"
local data="${3:-}"
if [ -n "$data" ]; then
curl -s -X "$method" \
-H "X-VO-Api-Id: $VICTOROPS_API_ID" \
-H "X-VO-Api-Key: $VICTOROPS_API_KEY" \
-H "Content-Type: application/json" \
"https://api.victorops.com${endpoint}" \
-d "$data"
else
curl -s -X "$method" \
-H "X-VO-Api-Id: $VICTOROPS_API_ID" \
-H "X-VO-Api-Key: $VICTOROPS_API_KEY" \
"https://api.victorops.com${endpoint}"
fi
}
jqvo_api GET "/api-public/v1/incidents" | jq '[.incidents[] | {
incidentNumber, currentPhase, startTime,
entityId, entityDisplayName,
transitions: [.transitions[] | {name, at, by}]
}]'
vo_api GET "/api-public/v1/incidents/INCIDENT_NUMBER" | jq '{
incidentNumber, entityDisplayName,
startTime, currentPhase,
pagedTeams, pagedUsers,
timeline: [.transitions[] | {name, at, by, message}]
}'
vo_api GET "/api-public/v1/org/routing-keys" | jq '[.routingKeys[] | {routingKey, targets: [.targets[]?.policySlug]}]'
vo_api POST "/api-public/v1/org/routing-keys" '{
"routingKey": "database-critical",
"targets": [{"policySlug": "team-database", "type": "escalationPolicy"}]
}'
vo_api GET "/api-public/v1/policies" | jq '[.policies[] | {slug, name, steps: [.steps[] | {timeout, entries: [.entries[] | .executionType]}]}]'
vo_api GET "/api-public/v2/team/TEAM_SLUG/oncall/schedule" | jq '.schedule | {
team,
schedules: [.schedules[] | {
policy: .policySlug,
schedule: [.overrides[]? // .rotations[] | {user: .onCallUser.username, start, end}]
}]
}'
vo_api GET "/api-public/v1/team" | jq '[.[] | {name, slug, memberCount: (.members | length)}]'
vo_api GET "/api-public/v1/org/routing-keys/ROUTING_KEY/rules" | jq '[.rules[] | {
id, matchingCondition, transformations
}]'
Present results as a structured report:
Managing Victorops Report
═════════════════════════
Resources discovered: [count]
Resource Status Key Metric Issues
──────────────────────────────────────────────
[name] [ok/warn] [value] [findings]
Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]
Target ≤50 lines of output. Use tables for multi-resource comparisons.
--help output.| Shortcut | Counter | Why |
|---|---|---|
| "I'll skip discovery and check known resources" | Always run Phase 1 discovery first | Resource names change, new resources appear — assumed names cause errors |
| "The user only asked for a quick check" | Follow the full discovery → analysis flow | Quick checks miss critical issues; structured analysis catches silent failures |
| "Default configuration is probably fine" | Audit configuration explicitly | Defaults often leave logging, security, and optimization features disabled |
| "Metrics aren't needed for this" | Always check relevant metrics when available | API/CLI responses show current state; metrics reveal trends and intermittent issues |
| "I don't have access to that" | Try the command and report the actual error | Assumed permission failures prevent useful investigation; actual errors are informative |