How You Can Build Incident Management Inside Jira

Years before we built Phoenix Incidents, I built it by hand inside Jira. Twice.

At two different companies, years apart, I went looking for an incident management app in the Atlassian Marketplace. There wasn’t one. There were hundreds of ITSM add-ons and connectors to external incident tools, but nothing that actually ran incident response end-to-end inside Jira — without adding another system to learn.

So I built it.

The idea felt obvious: incidents are simply the most urgent kind of work. They sit alongside bugs, stories, and tasks, so pulling them into a separate tool never made sense. You lose the context — linked issues, ownership, and the visibility & traceability. Alerts can live elsewhere; they’re the signal. But once an alert becomes an incident, it deserves to live where work happens, which for many teams, that’s Jira.

What followed was a surprisingly complete system — one you can still recreate today — and a lesson in where Jira shines, and where it needs help.

1. Why I Did It

We already had all the tools: Jira for tracking, Slack for comms, Splunk On-Call or PagerDuty for paging (depending on the company). It just felt absurd that these couldn’t work together out of the box to build a solid, modern Incident Management system for software engineering teams.

So I wired them up:

Jira workflows to model the full incident lifecycle.
Jira Automation rules that sent Slack alerts when incidents were created, or transitioned and reminders to keep the team on track to our SLAs.
Outgoing webhooks that posted to our paging system to page the right team.
Confluence templates for RCAs that auto-linked back to the incident.
Linked issues for action items that, when all resolved, automatically closed the parent incident.

It worked. It was scrappy, but the system handled hundreds and hundreds of real incidents over years. We shipped faster, closed loops more consistently, and the automation kept things moving without constant babysitting. One of the very early wins was the transparency of the system kept our customer facing teams in the loop, and we saw increased accountability from the engineering teams.

2. What I Built — and Why It Worked

The setup wasn’t fancy, but it got the job done:

Slack automation. Every incident created or transitioned sent messages to two channels — a general incident feed and a team-specific one.
Auto-closure logic. When all linked “action item” issues were marked done, the parent incident automatically resolved.
RCA enforcement. If someone tried to close an incident without critical data or tasks completed, we leveraged workflow conditions when possible, or Jira automation to reopen it and comment (for the cases where native conditions were limited).
Confluence integration. A Confluence template pre-populated fields from the Jira issue so postmortems were automatically linked.
Daily RCA reminders. Jira automation pinged assignees when RCAs weren’t completed by their target date.
Escalation reminders. If an engineer hadn’t acknowledged, verified, or sent an update, automation rules fired timed Slack nudges until they did.
Reporting & Charts. We used an off the shelf charting app in the Atlassian marketplace. With significant setup we had all the requisite reporting needed for quarterly business reviews

For a single company, it was surprisingly effective — a zero-budget incident platform that made Jira feel purpose-built for ops.

This post is the overview. The full implementation guide is delivered by email below.

The full details on how to build this are in the guide linked at the bottom.

3. The Edges: Where It Fell Apart

It wasn’t the logic that broke down. It was maintainability and process drift.

Manual maintenance. Some configuration was brittle — for example, Slack User Id mappings or confluence API keys.
Clunky reminders. The update reminders couldn’t detect if an update was actually sent — they were just timers. Add different SLAs for different severities, and it got unmanageable fast.
Templates ≠ process. Confluence templates worked fine, but they don’t enforce good RCA practices. Engineers skipped required fields, the “five whys” were inconsistently filled, and root causes varied from insightful to ¯\_(ツ)_/¯.
Timeline chaos. Slack conversations, Zoom calls, and Jira comments all lived in different places. The “timeline” was whatever someone remembered to write down later.
One-way Slack. Notifications weren’t interactive — you couldn’t acknowledge or update from Slack without jumping back into Jira.
Reporting and dashboards. The reporting technically worked — we used a 3rd-party charting jira app and built dozens of custom views. It got the job done, but the setup was heavy, and every quarter someone had to rebuild or recalibrate charts just to keep the data meaningful.

It all functioned, but it required constant tending. Someone had to maintain the automation rules, chase missing data, and update Confluence templates. It was a clever system, not a sustainable one.

4. What It Taught Me

You can stretch Jira incredibly far with Automation and Confluence. But eventually, the work shifts from automating incidents to maintaining the automation.

The challenge wasn’t technical — it was human:

Enforcing consistency in how engineers documented root causes.
Making sure the lessons were actually reusable six months later.
Keeping communication loops tight without overwhelming people with pings.

Those gaps weren’t bugs to fix — they were signals. They showed where process, structure, and guided tooling matter more than clever rules.

And that learning became the foundation for Phoenix Incidents: a system built to handle the human side of incident management reliably, at scale.

5. The Role of AI — and What to Be Deliberate About

Today AI can handle parts of this beautifully:

Reconstructing timelines automatically from Slack, Zoom, and Jira.
Suggesting status updates or summaries.
Recommending similar past incidents or runbooks.

That’s all powerful — and it should be automated.

But there’s a line. In some places, you want a human in the loop, in others, the process is the value.

Take Post-mortems (RCAs), for example, the “Five Whys” exercise is an intentional process, not a rote task. The learning comes from the conversation — engineers debating causes, challenging assumptions, uncovering the real systemic issues. Some tools try to skip that by letting an LLM auto-generate root causes and a polished write-up. It looks slick, but it misses the point entirely: nobody learns, and the document just becomes noise — even if it’s useful later as training data.

AI should absolutely support the process — prompting better questions, surfacing blind spots, suggesting related incidents — but it shouldn’t replace the reasoning itself.

The future of incident management is AI-driven, but deliberately so. Automate everything that doesn’t teach you something. Keep humans in the loop where reflection, context, and improvement matter.

6. Takeaway: Build First, Then Evolve

You can build this inside Jira. And if you do, you’ll learn a lot — what your process actually needs, which automations help, and where the friction lives.

But you’ll also hit the ceiling fast. Maintenance, reporting, data quality — all the same problems I ran into — will start to eat your weekends. That’s the signal it’s time for something purpose-built.

That’s why we built Phoenix Incidents: not as a collection of scripts or automations, but as a reliable, scalable Forge app shaped by those early lessons. It takes everything that worked — the workflows, the Slack links, the RCA discipline — and rebuilds them as a mature, reliable platform. Slack is fully interactive with buttons, slash commands, and real-time updates. Reminders are precise, not timer hacks. Reporting is built-in, not bolted on. Everything runs automatically and at scale — the way it should have from the start.

So yes, you can recreate what I did.

Or you can let Phoenix Incidents handle all the heavy lifting — built on years of experience running incidents the hard way.

Get the Full Setup Guide

I documented the full setup — automation rules, workflows, Confluence templates, and example reminders — so you can build your own version.