Scitor + PagerDuty
Page on-call for the tickets that actually can't wait
When Scitor's AI triage escalates a ticket to priority:urgent, a GitHub Actions workflow can send a PagerDuty Events API v2 event straight from that label — turning a critical customer report that arrives at 2am into an on-call page instead of a ticket discovered the next morning.
What this workflow does
It fires when the priority:urgent label is applied to a ticket Scitor's own bot opened — so a contributor can't page your on-call by applying the label themselves — and sends a trigger event directly to PagerDuty's Events API — no marketplace action, just a fetch call with your routing key. It uses the GitHub issue number as PagerDuty's dedup key, so re-applying the label doesn't open a second incident for the same ticket.
What it does not do
It does not resolve the incident when the ticket is closed — that's a second job you'd add yourself (sending event_action: "resolve" with the same dedup key on issues: types: [closed]). And it only pages for priority:urgent — Scitor's AI reserves that for things like an outage, security issue, or data-loss report, not every bug report.
The workflow file
Save this as .github/workflows/pagerduty-urgent.yml in your Scitor-connected repository.
# PagerDuty alert for critical tickets
#
# Triggers a PagerDuty incident via the Events API v2 when Scitor's AI triage
# escalates a ticket to `priority:urgent`.
#
# What this does:
# - Fires when the `priority:urgent` label is applied to a ticket.
# - Sends a `trigger` event to PagerDuty's Events API, creating an incident
# with the ticket title, URL, and issue number as custom details.
# - Uses the GitHub issue number as PagerDuty's `dedup_key`, so re-applying
# the label (e.g. after removing and re-adding it) doesn't open a second
# incident for the same ticket.
#
# What this does NOT do:
# - It does not resolve or acknowledge the incident automatically when the
# ticket is closed. Add a second job on `issues: types: [closed]` sending
# `event_action: "resolve"` with the same `dedup_key` if you want that.
# - It does not page for every ticket — only for `priority:urgent`, which
# Scitor's AI triage reserves for things like a reported outage, security
# issue, or data-loss report (see priority.auto_assign in scitor.yaml).
#
# Required secret:
# PAGERDUTY_ROUTING_KEY — the integration/routing key from a PagerDuty
# "Events API v2" integration on the service you want to alert
# (PagerDuty -> Service -> Integrations -> Add Integration -> Events API v2).
#
# Source: Scitor's own documented example at
# https://support.scitor.io/guides/github-actions#pagerduty-alert-for-critical-tickets
# Endpoint and payload shape (routing_key, event_action, payload.summary,
# payload.source, payload.severity) cross-checked against PagerDuty's Events
# API v2 documentation, fetched 2026-09-17.
name: PagerDuty — priority urgent
on:
issues:
types: [labeled]
jobs:
pagerduty:
if: >
github.event.label.name == 'priority:urgent' &&
github.event.issue.user.login == 'scitor-customerops[bot]'
runs-on: ubuntu-latest
steps:
- name: Send PagerDuty event
uses: actions/github-script@v7
with:
script: |
const res = await fetch('https://events.pagerduty.com/v2/enqueue', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
routing_key: process.env.PAGERDUTY_ROUTING_KEY,
event_action: 'trigger',
dedup_key: `scitor-${context.issue.number}`,
payload: {
summary: `Critical customer issue: ${context.payload.issue.title}`,
severity: 'critical',
source: 'scitor-support',
custom_details: {
url: context.payload.issue.html_url,
issue_number: context.issue.number,
},
},
links: [{ href: context.payload.issue.html_url, text: 'View support ticket' }],
}),
});
if (!res.ok) core.setFailed(`PagerDuty Events API returned ${res.status}`);
env:
PAGERDUTY_ROUTING_KEY: ${{ secrets.PAGERDUTY_ROUTING_KEY }} Required secret
| Secret | Where to get it |
|---|---|
| PAGERDUTY_ROUTING_KEY | PagerDuty → Service → Integrations → Add Integration → Events API v2. Add the routing key it generates under Settings → Secrets and variables → Actions in your repository. |
Questions about this integration
- What counts as 'urgent' — will this over-page my on-call?
- Scitor's priority auto-assignment (when enabled) reserves priority:urgent for things like a reported outage, security issue, or data-loss report — not every bug report. You can also skip AI entirely and set priority.default in scitor.yaml, or write a routing rule that only applies priority:urgent under conditions you choose.
- Will re-opening or re-labeling a ticket create duplicate incidents?
- No. The workflow sets PagerDuty's dedup_key to the GitHub issue number, so re-applying the priority:urgent label to the same ticket updates the existing incident rather than opening a second one.
- Does the incident auto-resolve when I close the ticket?
- Not with the example as shown — it only sends a trigger event. Add a second job triggered on issues: types: [closed] that sends event_action: "resolve" with the same dedup_key if you want closing the GitHub Issue to resolve the PagerDuty incident too.
Critical tickets shouldn't wait for the morning standup
Takes under 5 minutes. Free tier available. No credit card required.