🔗 Integrating Slack with PagerDuty and Jira for Closed-Loop Ops

The dream of ChatOps is a closed loop: a page fires, the team responds in Slack, and the follow-up work lands in Jira — all without anyone re-typing the same incident three times in three tools. After 25 years of stitching these systems together, I can tell you the loop is achievable, but only if you’re deliberate about which steps are automatic and which stay manual. Automate the wrong step and you’ll drown Jira in junk tickets.

Here’s how I wire Slack, PagerDuty, and Jira into one coherent flow.

Map the loop before you build it

Sketch the lifecycle first:

1. PagerDuty pages on a critical alert.
2. Slack gets a message about the new incident and (ideally) spins up an incident channel.
3. The team acknowledges, investigates, and resolves from Slack — actions that flow back to PagerDuty.
4. On resolution, follow-up action items become Jira tickets linked back to the incident.

Knowing the loop tells you where the integration points are and which direction data flows at each one.

Slack ↔ PagerDuty: bidirectional, mostly automatic

PagerDuty’s Slack integration is mature, but I tune it rather than accept defaults:

• Page to channel. A new high-urgency incident posts to the relevant ops channel and triggers your incident-channel automation. This is safe to fully automate — a page already happened; you’re just routing the notification.
• Acknowledge from Slack. Responders ack with a button, and it reflects in PagerDuty. This is the highest-value bit: people are already in Slack, so don’t make them context-switch to ack.
• Resolve from Slack. I allow this but with a confirmation, because resolving a PagerDuty incident has real consequences (it can re-page if the underlying issue persists). Acknowledging is low-stakes; resolving is a deliberate act.

Map PagerDuty services to specific Slack channels by ownership so a payments page lands in the payments channel, not a global firehose.

Slack ↔ Jira: automatic creation is a trap

Here’s the mistake I see constantly: teams auto-create a Jira ticket for every incident. Six weeks later Jira is a graveyard of duplicate, empty, never-closed tickets and everyone ignores the project.

My rule: ticket creation is human-triggered, ticket enrichment is automatic. A responder decides “this needs a follow-up” and clicks a button or runs /jira create from the incident channel. The bot then enriches the ticket automatically — pulling the incident title, severity, timeline, affected service, and a link back to the Slack channel.

app.action('create_followup', async ({ ack, body, client }) => {
  await ack();
  const incident = await getIncidentContext(body.channel.id);
  const issue = await jira.createIssue({
    fields: {
      project: { key: 'OPS' },
      issuetype: { name: 'Task' },
      summary: `Follow-up: ${incident.title}`,
      description: buildDescription(incident), // timeline + slack link
      labels: ['incident-followup', incident.severity],
    },
  });
  await client.chat.postMessage({
    channel: body.channel.id,
    text: `:white_check_mark: Created <${issue.url}|${issue.key}>`,
  });
});

The human decides whether; the automation handles the tedious typing. That split keeps Jira clean and the loop fast.

Keep links bidirectional

Every connection should be navigable both ways. The Jira ticket links to the Slack incident channel; the Slack channel’s pinned card links to the PagerDuty incident and any Jira tickets. Six months later, someone reading the postmortem can jump to the ticket, the page, and the original conversation in two clicks. Broken or one-way links are how incident context rots.

Avoid the duplicate-notification storm

The classic failure when you connect three systems: one event becomes three Slack messages. PagerDuty posts, your incident bot posts, and a Jira automation posts — all about the same incident. Be ruthless about ownership:

• The incident channel bot owns the in-channel narrative.
• PagerDuty posts only page/ack/resolve state changes.
• Jira posts only when a ticket is created or its status changes.

Decide who owns each message type and turn off everyone else’s overlap. One event, one clear notification.

Where AI fits in the loop

AI earns its place at the boundaries where information transforms:

• Drafting the Jira ticket. When a responder clicks “create follow-up,” the LLM reads the incident timeline and drafts a clear summary, reproduction context, and a suggested title — far better than the terse line a tired human types. The responder reviews before submit.
• Suggesting follow-ups. At resolution, AI reads the incident channel and proposes the action items worth ticketing (“the connection-pool limit needs raising; the missing runbook should be written”). It suggests; the human picks which become tickets.
• Correlating PagerDuty incidents. AI can flag “this looks like the same root cause as last Tuesday’s page,” surfacing patterns across incidents.

The boundary never moves: AI drafts ticket content and suggests follow-ups; humans decide what gets created, acknowledged, and resolved. The model never opens a ticket or resolves a page on its own.

A staged rollout

1. PagerDuty → Slack notifications and ack-from-Slack. Immediate value, low risk.
2. Resolve-from-Slack with confirmation.
3. Human-triggered Jira creation with automatic enrichment.
4. AI ticket drafting and follow-up suggestions last.

Each stage stands alone, so you’re useful before the full loop exists.

The payoff

Done right, an incident flows from page to resolution to follow-up without anyone re-typing context, and every system links back to the others. The discipline is knowing that notifications and acks can be automatic while ticket creation and resolution stay human. Get that split right and your loop is fast and your Jira stays clean.

For AI prompts that draft tickets and suggest follow-ups, see our Slack integration prompts and the prompt library.

Automate notifications and enrichment. Keep ticket creation and incident resolution as human decisions, with AI drafting the content.