← All integrations

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.