# AWS Incident Manager alternatives: what to use now it is closed to new customers

URL: https://rootly.com/on-call-software/aws-incident-manager-alternatives
Pillar: On-Call Operations
Bundle: https://rootly.com/llms/on-call-software.txt

> AWS Incident Manager stopped taking new customers on November 7, 2025 and gets no new features. How it compares on on-call and escalation, and how to move off it.

**AWS Systems Manager Incident Manager stopped accepting new customers on November 7, 2025, and AWS will not add new features to it.** Existing customers can keep using it, but every team on it now runs on-call and incident response on a tool that has stopped developing. AWS's own guidance is to plan an alternative, [export incident data](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.html) before migrating, and clean up Incident Manager resources afterwards to avoid ongoing charges.

This guide compares Incident Manager with dedicated incident platforms on on-call escalation, lists its pros and cons, and lays out a migration that keeps paging working throughout.

## Key takeaways

- Incident Manager is closed to new customers and frozen on features, so its gaps on on-call, chat and status pages won't close.
- Its strength is native AWS integration: CloudWatch alarms, EventBridge, Automation runbooks and deployment findings.
- A replacement should take CloudWatch and EventBridge alerts and every other monitoring source, and cover paging and incident response together.
- Move schedules and escalation as code, run both tools in parallel, then cut over alert routing.

## How AWS Incident Manager compares for on-call escalation

| Capability | AWS Incident Manager | Dedicated incident platform (Rootly) |
| --- | --- | --- |
| Product status | Closed to new customers since Nov 7, 2025; no new features | Actively developed |
| Paging channels | Email, SMS and voice per contact | Push (including critical push that bypasses Do Not Disturb), phone, SMS, email, Slack and Microsoft Teams |
| On-call schedules | Rotations of up to 30 contacts | Schedules and rotations with overrides, shift swaps and shadowing |
| Escalation | Escalation plans with stages | Escalation policies with levels and paths |
| Alert sources | CloudWatch alarms and EventBridge events | CloudWatch through SNS, plus Datadog, Grafana, Prometheus Alertmanager, Sentry, New Relic and more than 100 other integrations |
| Chat | Channels through Amazon Q Developer in chat applications (Slack, Microsoft Teams) | Native incident workflow in Slack, Microsoft Teams and Google Chat |
| Runbooks | Systems Manager Automation runbooks | Workflows that run actions across tools, plus your own runbooks |
| Status pages | Not included | Included with Incident Response |
| Retrospectives | Post-incident analysis with recommended follow-ups | AI-drafted retrospectives from the timeline, with action items synced to Jira or Linear |
| Configuration as code | CloudFormation and the AWS API | Terraform provider, Pulumi, REST API and CLI |

## AWS Incident Manager pros and cons

**Pros**

- Native to AWS: CloudWatch alarms and EventBridge rules create incidents directly, with metrics attached.
- Automation runbooks run remediation inside your AWS accounts.
- Findings show CodeDeploy deployments and CloudFormation stack updates near the time of an incident.
- Response plans bring engagement, runbooks and chat channel together in one template.

**Cons**

- Closed to new customers and frozen on features. New teams and new accounts can't adopt it, and existing users get no improvements.
- AWS-centric alert intake. Alerts from Datadog, Grafana or Sentry need extra plumbing.
- Chat runs through Amazon Q Developer in chat applications, not an incident workflow that lives in Slack or Teams.
- No status pages, so customer communication needs another tool.
- Paging is limited to email, SMS and voice, with no mobile app push.

## How to migrate off AWS Incident Manager

1. **Export incident data.** Follow AWS's export guidance so past incidents stay available for analysis and audits.
2. **Recreate who gets paged.** Map contacts to users, rotations to schedules, and escalation plans to escalation policies. Defining them in [Terraform](https://rootly.com/integrations/terraform) makes the mapping reviewable and repeatable across teams.
3. **Connect AWS alerts.** In Rootly, add a [CloudWatch alert source](https://docs.rootly.com/integrations/aws-cloudwatch) and subscribe it to the SNS topic your alarms already publish to. Rootly opens an alert when an alarm enters `ALARM` and resolves it when the alarm returns to `OK`. Other SNS topics connect through the [Amazon SNS source](https://docs.rootly.com/integrations/aws-sns).
4. **Rebuild response plans as workflows.** A response plan's engagement, chat channel and runbook become a workflow that creates the incident, pages the escalation policy, opens the channel and starts the bridge.
5. **Run in parallel.** Send alarms to both tools for a week, page test incidents through the new escalation policies, and confirm every rotation reaches the right person.
6. **Cut over and clean up.** Remove Incident Manager from alarm actions, then delete its resources to stop charges, as AWS recommends.

## How teams run AWS alerts in Rootly

CloudWatch alarms arrive through SNS with their alarm name, ARN, state and reason, and the alarm ARN keeps repeat triggers on one alert instead of paging twice. Alert routes send each alarm to the owning team's escalation policy, and alert workflows open incidents for the alarms that warrant one. Rootly can also stream incident and alert events back to [Amazon EventBridge](https://docs.rootly.com/integrations/aws-eventbridge), so Lambda functions and Step Functions keep reacting to incidents the way they did before.

Rootly's [On-Call](https://rootly.com/on-call) handles schedules, escalation and paging, and Incident Response runs the incident natively in Slack, Microsoft Teams or Google Chat. A first incident runs in about 15 minutes with starter templates and defaults, and most teams are live within a week. See [pricing](https://rootly.com/pricing) for both products.

## Frequently asked questions

### Is AWS Incident Manager being discontinued?

AWS Systems Manager Incident Manager stopped accepting new customers on November 7, 2025, and AWS will not add new features or capabilities. Existing customers can keep using it in accounts where it is already enabled, and AWS continues to maintain its security and availability. AWS has published migration guides and recommends exporting incident data before moving.

### How does AWS Incident Manager compare with other tools for on-call escalation?

Incident Manager covers the basics: contacts reached by email, SMS or voice, on-call schedules with up to 30 contacts per rotation, and escalation plans. Dedicated on-call platforms add mobile push that can bypass Do Not Disturb, routing alerts from monitoring tools outside AWS, overrides and shift swaps, and incident response that runs in Slack, Microsoft Teams or Google Chat. With no new features coming, the gap will widen.

### What are the pros and cons of AWS Incident Manager?

Pros: native integration with CloudWatch alarms, EventBridge, Systems Manager Automation runbooks, and CodeDeploy and CloudFormation findings, all inside the AWS console. Cons: closed to new customers with no new features, AWS-centric alert intake, chat collaboration through Amazon Q Developer in chat applications rather than a native incident workflow, and no status pages.

### What is the best alternative to AWS Incident Manager?

Pick a platform that ingests CloudWatch and EventBridge alerts as well as your other monitoring tools, covers on-call and incident response together, and runs incidents in the chat tool your team uses. Rootly does all three: CloudWatch alarms arrive through SNS and resolve when they return to OK, On-Call handles schedules and escalation, and incidents run natively in Slack, Microsoft Teams or Google Chat.

### How do I migrate off AWS Incident Manager?

Export your incident data first, as AWS recommends. Recreate contacts, on-call rotations and escalation plans in the new tool, ideally with Terraform so the setup is reviewable. Point CloudWatch alarms and EventBridge rules at the new tool, run both in parallel for a week with test pages, then clean up the Incident Manager resources to stop ongoing charges.