Incident Management in 2026: Opsgenie Ends April 2027, AI SREs Arrive

Every few years the paging tool I recommend to people changes, and 2026 is one of those years. Atlassian stopped selling Opsgenie in June 2025 and will switch it off, data and all, in April 2027. FireHydrant now belongs to Freshworks. Grafana archived the open-source OnCall project. Meanwhile every vendor left standing is selling an "AI SRE" that promises to investigate the incident before you have found your laptop. This post is a plain map of incident management in 2026: what changed in the tooling, what the AI agents can and cannot be trusted with, what the on-call health surveys actually measured, and why the boring part (blameless postmortems with owned action items) is still where most teams lose.

What incident management covers in 2026

Split the job into four layers; vendors blur them, and migrations break along the seams.

1. Alerting and paging. Turning a signal from monitoring into a phone ringing in the right pocket: routing, schedules, escalation policies, overrides, acknowledgement timeouts.
2. Response coordination. Declaring an incident, setting severity, spinning up a channel and a call, assigning an incident commander, keeping a timeline, updating a status page.
3. Investigation. Finding what changed and why it hurts. This is where the AI agents now sit.
4. Learning. The postmortem, the review meeting, the action items, and the follow-through that stops a repeat.

Paging is a commodity with high switching costs, because schedules encode years of organisational habit. Coordination moved into Slack and Teams years ago. Investigation is the new battleground. Learning is what every survey says teams do badly, and no tool can do it for you.

Opsgenie end of life: the dates that matter

If you run Opsgenie, this is the section to forward to your manager. Atlassian's migration page is explicit: end of sale was 4 June 2025, after which you cannot upgrade or downgrade editions or add sites, though you can still buy seats. End of support is 5 April 2027, at which point Opsgenie is shut down and data that has not been moved is deleted. The supported destination is Jira Service Management (Compass is also named in some Atlassian material for development teams). The migration runs automatically on a date you pick and gives you 120 days of parallel access to check the result.

Date	What happens	Source
4 June 2025	Opsgenie end of sale: no new customers, no edition changes, seats still purchasable	Atlassian
Any date you choose	Automated move to Jira Service Management, then 120 days of parallel access	Atlassian
5 April 2027	End of support: Opsgenie shut down, unmigrated data deleted	Atlassian
11 March 2025	Grafana OnCall OSS enters maintenance mode (fixes for CVSS 7.0+ only)	Grafana
24 March 2026	Grafana OnCall OSS archived; Cloud Connection, SMS, phone and push relay stop	Grafana, GitHub

The arithmetic matters more than the dates. Today is 20 October 2026, so there are under six months left. If you want to evaluate an alternative rather than take the default path, you need time to rebuild schedules, re-point every integration (Alertmanager, CloudWatch, Datadog, synthetic checks), run both systems side by side for a few rotations, and test that escalations actually reach people at 3am. I checked the Grafana repository myself: gh api repos/grafana/oncall reports archived: true, with the last release, v1.16.11, published in February 2026. Existing self-hosted installs keep running, but without the cloud relay you are wiring up your own SMS and phone provider.

PagerDuty vs incident.io vs Rootly vs FireHydrant: who owns what now

The market consolidated in a way that changes the risk profile of each choice.

Vendor	2026 status	Verified recent fact	Source
PagerDuty	Public company, new CEO	John DiLullo named CEO, Jennifer Tejada to executive chair; Q1 FY2027 revenue $121.0M, up 1.0%	SEC 8-K, 28 May 2026
incident.io	Independent, venture-backed	$62M Series B led by Insight Partners, April 2025, total over $96M	incident.io
Rootly	Independent, venture-backed	$12M Series A in August 2023; launched Rootly AI Labs in April 2025	Dark Reading, Business Wire
FireHydrant	Part of Freshworks	Deal announced 15 December 2025, closed in January 2026, being folded into Freshservice	Constellation Research, Freshworks
Opsgenie	End of support 5 April 2027	Customers moved to Jira Service Management	Atlassian
Grafana OnCall OSS	Archived 24 March 2026	Replacement is Grafana Cloud IRM	Grafana

My reading, as opinion: PagerDuty remains the safe default for paging at scale, with the broadest integration catalogue, but revenue growth of one percent a year tells you its market is mature and its roadmap is now about AI add-ons. incident.io is the Slack-native response tool most engineering-led teams I talk to evaluate first, and it added its own on-call product in 2024 so you can replace PagerDuty entirely. Rootly competes in the same space with a smaller balance sheet. FireHydrant buyers should ask Freshworks directly what the roadmap looks like inside an ITSM suite, because acquisitions of developer tools by service-desk companies tend to bend the product towards the acquirer's buyers.

Two options disappeared (Opsgenie as a product, Grafana OnCall OSS as a maintained project), and the survivors are per-seat SaaS. If you must self-host, you are now assembling Alertmanager, a paging relay and a postmortem process yourself.

Does AI in incident response actually work yet?

Every vendor in the table now ships an agent. PagerDuty announced an AI agent suite including an SRE Agent in October 2025, and by its May 2026 earnings release had added automated triage that a team's workflows can trigger directly, plus partnerships with Anthropic, Cursor and LangChain. incident.io raised its Series B explicitly to build agents that investigate incidents, surface likely bad changes, suggest reverts, and pull up similar past incidents; at the time it described applying fixes on your behalf as something it would do "eventually".

I went through the benchmarks and the vendor claims in detail in AIOps in 2026, so I will not repeat them here. The short version: agents are useful at the parts of an investigation that are search problems (what deployed in the last hour, which dashboards moved, which past incident looks like this one) and unreliable at naming a root cause unsupervised. The least glamorous feature, a bot that writes the timeline from the channel and call transcript, is the most immediately valuable.

The less comfortable data point comes from Catchpoint. Its SRE Report 2025, from 301 respondents surveyed in July and August 2024, found the median share of work spent on toil rose to 30 percent from 25 percent, ending five years of decline, at exactly the point AI tooling was supposed to reduce it. The most selected attitude towards AI was a cautious approach, at 37 percent. AI does not remove operational work by default; it moves it, often into reviewing what the agent did.

My rule of thumb: let the agent read everything and write a draft, and keep a human holding the button for anything that changes production. That is the same discipline I argue for in what your AI agent does at 2am, applied to the agent that is supposed to be fixing your outage.

What the on-call health data says

PagerDuty's 2026 State of AI-First Operations report, published 17 March 2026, surveyed 1,000 director-level-and-above leaders and senior developers through Wakefield Research. On cost, 68 percent said they lose more than $300,000 an hour during IT incidents and 8 percent more than $1 million. When asked about the impacts of disruptions, 42 percent named developer burnout, behind brand reputation (52 percent), recovery costs (50 percent) and lost productivity (48 percent). And only 48 percent said they had increased resilience by turning incidents into structured learning. A vendor survey of executives measures perception, not pager volume.

Catchpoint's 2025 report adds that 40 percent of respondents handled one to five incidents in the previous 30 days, and over two thirds frequently feel pressured to put release schedules ahead of reliability. Its 2026 edition, announced through LogicMonitor's newsroom on 22 January 2026, drew on more than 400 respondents and leads with nearly two thirds saying performance degradations are as serious as outages. Outside the vendor world, LeadDev's Engineering Leadership Report 2025 measured 22 percent of 617 engineers and leaders at critical burnout on a Maslach-based scale; it does not isolate on-call, but on-call load is one of the obvious inputs.

What I take from this: nobody publishes a credible, cross-industry number for pages per engineer per week, so measure your own. Pages outside working hours, pages that needed no action, and time to acknowledge are cheap to extract from any paging tool's API, and they tell you more than a survey will. The alert fatigue guide covers the Alertmanager side of that.

Why blameless postmortems still matter more than tooling

Every tool above can create a postmortem document. None can make your organisation act on it, and fewer than half reliably do.

Google's SRE book chapter on postmortem culture still sets the baseline: write one for user-visible downtime beyond a threshold, any data loss, any on-call intervention such as a rollback, resolution time beyond a threshold, or a monitoring failure, and assume everyone acted reasonably with the information they had. Its line that "an unreviewed postmortem might as well never have existed" is the one most teams quietly ignore. Atlassian's incident handbook shows what enforcement looks like: postmortems for severity 1 and 2 incidents, approval by named managers, and "priority actions" with an agreed SLO of four or eight weeks depending on the service, with reminders and reports. That approval step is the difference between a document and a fix.

The method has moved on too. Atlassian still recommends the Five Whys; John Allspaw argued as far back as 2014 that asking "why" pushes people towards a single causal chain and a person to blame, and that asking "how" produces richer accounts of the conditions people were working in. Public postmortems show the newer style. Cloudflare's 18 November 2025 write-up traces a ClickHouse permissions change that doubled the size of a Bot Management feature file past a hard limit of 200 features, and its fixes are systemic: validate internally generated config like user input, add more global kill switches, review failure modes across proxy modules. Nobody is told to be more careful.

If you are writing your first one, the companion blameless postmortem template guide has a copy-paste template and a meeting agenda.

How to choose an incident management tool in 2026

My selection criteria, in the order I would apply them:

1. Can you leave? Keep schedules, escalation policies and service definitions in code so the next forced migration is a provider swap, not an archaeology project.
2. Does paging work when your chat tool is down? Slack-native response is pleasant until Slack is part of the outage.
3. Where do postmortems and action items live? If they do not land in the same tracker your teams plan work from, they will not get done.
4. What do the AI features need access to? An agent that can read your logs, deploy history and code is a new privileged identity. Treat it like one.

On the first point, here is the kind of configuration I keep in Git. It is the PagerDuty Terraform provider, but the shape (users, a rotation, an escalation policy, a service) maps onto every serious tool.

# on-call.tf: on-call as code, so a vendor migration is a rewrite of one file
terraform {
  required_version = ">= 1.14.0"
  required_providers {
    pagerduty = {
      source  = "PagerDuty/pagerduty"
      version = "3.36.0" # latest release, 25 August 2026
    }
  }
}

data "pagerduty_user" "alice" { email = "alice@example.com" }
data "pagerduty_user" "bob"   { email = "bob@example.com" }

resource "pagerduty_schedule" "platform_primary" {
  name      = "Platform primary"
  time_zone = "Europe/London"

  layer {
    name                         = "Weekly handover, Monday 10:00"
    start                        = "2026-10-26T10:00:00Z"
    rotation_virtual_start       = "2026-10-26T10:00:00Z"
    rotation_turn_length_seconds = 604800 # one week per person
    users                        = [data.pagerduty_user.alice.id, data.pagerduty_user.bob.id]
  }
}

resource "pagerduty_escalation_policy" "platform" {
  name      = "Platform escalation"
  num_loops = 2

  rule {
    escalation_delay_in_minutes = 10 # unacknowledged for 10 min: page again, up to num_loops
    target {
      type = "schedule_reference"
      id   = pagerduty_schedule.platform_primary.id
    }
  }
}

resource "pagerduty_service" "api" {
  name                    = "Public API"
  escalation_policy       = pagerduty_escalation_policy.platform.id
  acknowledgement_timeout = 600   # re-page if acked but not resolved in 10 min
  auto_resolve_timeout    = 14400 # close stale incidents after 4 hours
}

Field names match the provider's v3.36.0 documentation; note that the provider marks alert_creation and the old alert_grouping fields as deprecated, so leave them out of new code.

FAQ

When does Opsgenie shut down?

Opsgenie end of support is 5 April 2027, according to Atlassian. On that date the service is shut down and any data you have not migrated is deleted. New sales already stopped on 4 June 2025.

What is the best Opsgenie alternative?

Atlassian's own path is Jira Service Management, which is the lowest-effort move if you already live in Jira. Teams leaving the Atlassian stack usually shortlist PagerDuty for paging breadth and incident.io or Rootly for Slack-native response. Run any candidate in parallel for at least two full rotations before cutting over.

Can AI agents handle incidents on their own in 2026?

Not safely. Current agents are good at gathering context, correlating recent changes and drafting timelines, and unreliable at naming root causes without supervision. Keep a human approval step for any action that changes production.

What makes a postmortem blameless?

A blameless postmortem describes what the system allowed to happen rather than who made a mistake, and assumes people acted reasonably with the information they had at the time. Its action items change systems and processes, have a named owner and a tracked ticket, and get reviewed until they are closed.

This quarter, if I were running an Opsgenie shop, I would pick the destination by the end of October, export schedules and escalation policies into Terraform before touching anything else, and run old and new paging in parallel through at least two handovers. If I were already settled on a tool, I would spend the same effort on the learning layer: an agreed severity threshold for postmortems, an approver for each service, and a due date on every priority action. The AI agents will keep getting better on their own. The follow-through will not.

Related: AIOps in 2026: 47% on ITBench, 10% on Hard On-Call, $6.50 an Investigation, and Four Outages Where the Automation Was the Incident, It's 2 AM. Do You Know What Your AI Agent Is Doing? and DevOps Still Matters in 2026: AI Cut Delivery Stability 7.2%, Then Doubled Merged PRs and Added 91% to Review Time.