Incident management software needs eight kinds of integration: monitoring and alerting tools that send alerts in, the chat tool where responders work, on-call paging, an issue tracker for follow-up work, video conferencing, a service catalog, a documents tool for retrospectives, and an API or Terraform provider to manage the setup as code. Each missing integration becomes a manual step that someone repeats in every incident, usually at the worst possible moment.
This page lists what each category has to do, what to check during a trial, and how Rootly covers it. For the wider buying process, see how to choose incident response tools.
The must-have integrations checklist
| Category | What it must do | Examples | Check in a trial |
|---|---|---|---|
| Monitoring and alerting | Send alerts in with service, severity and a link back to the source | Datadog, Grafana, Prometheus Alertmanager, New Relic, Sentry, Dynatrace, Amazon CloudWatch, Google Cloud Monitoring | Fire a test alert and confirm it routes without anyone reading it first |
| Chat | Run the incident where responders already work | Slack, Microsoft Teams, Google Chat | Declare, page, assign a role and post an update without leaving chat |
| On-call paging | Page the right person and escalate if nobody acknowledges | Built-in on-call, or PagerDuty and Opsgenie (end of support April 5, 2027) for teams keeping their pager | Let a page go unacknowledged and watch it escalate |
| Issue tracking | Turn action items into tickets that stay in sync | Jira, Linear, ServiceNow, Asana | Close a ticket and check the incident record updates |
| Video | Open a bridge automatically for high-severity incidents | Zoom, Google Meet, Microsoft Teams meetings | Declare a SEV1 and check the link appears in the channel |
| Service catalog | Tell the tool who owns what | Backstage, Cortex, ServiceNow | Route an alert by service and confirm the owning team is paged |
| Documents | Publish the retrospective where the team reads it | Confluence, Notion, Google Docs | Export a retrospective with its timeline intact |
| Configuration as code | Manage schedules, routes and workflows in review | Terraform, Pulumi, REST API, CLI | Change a rotation in a pull request and apply it |
Monitoring and alerting
The alert integration decides how every incident starts. A good one keeps the alert’s context: the service it belongs to, its severity, the environment and a link back to the dashboard or query that fired. With that context the incident tool can deduplicate the alert, route it to the owning team and open an incident without a human triaging it first.
Check two directions. Alerts should come in with their fields intact, and context should flow back out: graphs, dashboards and notebooks attached to the incident record, so nobody pastes screenshots into the channel.
In Rootly, monitoring tools connect as alert sources. Datadog, Grafana, Prometheus Alertmanager, New Relic, Sentry, Dynatrace, Honeycomb, Chronosphere, Checkly, Amazon CloudWatch and Google Cloud Monitoring have native integrations, and any other tool can send JSON to the generic webhook alert source. Alert workflows then decide what happens next: create an incident, page on-call, or post to a channel.
Chat: Slack, Microsoft Teams and Google Chat
Responders already live in chat, so the incident should too. A notification bot is not enough. Check that responders can declare an incident, page someone, assign the incident commander, change severity and post a status update with chat commands, and that every message lands in the incident timeline.
Rootly runs natively in Slack, Microsoft Teams and Google Chat. Each incident gets its own channel, and the full lifecycle runs from there.
On-call paging
Paging decides who wakes up. The integration should read the schedule, page by push, SMS, phone call and email, and escalate to the next level if nobody acknowledges. If paging lives in a separate tool, the two need to agree on who is on call, or the incident tool will page the wrong person.
Rootly includes On-Call as its own product, with schedules, escalation policies and a mobile app. Teams that keep PagerDuty or Opsgenie for now can connect them instead, and move paging over later. Opsgenie reaches end of support on April 5, 2027, so Opsgenie teams should plan that move early; the Opsgenie migration guide covers it step by step.
Issue tracking: Jira, Linear and ServiceNow
The follow-up work is where incidents stop recurring, and it only happens if action items reach the tracker engineers already use. Check that creating an action item in the incident creates a ticket, and that closing the ticket updates the incident record. One-way sync means someone reconciles two lists by hand.
Rootly syncs Jira, Linear and ServiceNow in both directions, and creates tasks in Asana and ClickUp.
Video conferencing
A bridge should open by itself for high-severity incidents, with the link posted in the channel. Rootly starts Zoom, Google Meet, Microsoft Teams and GoToMeeting calls from a workflow, and its AI Meeting Scribe joins the bridge, transcribes it with speaker labels and turns the call into part of the incident record.
Service catalog
Routing by service only works if the incident tool knows which team owns which service. Syncing from the catalog you already maintain avoids keeping a second copy. Rootly syncs natively with Backstage, Cortex and ServiceNow, connects other systems of record through the Catalog Sync CLI, and has its own catalog for teams without one.
Documents for retrospectives
Retrospectives get read where the team keeps its documents. The tool should export the retrospective with its timeline, contributing factors and action items into Confluence, Notion or Google Docs, and keep a link from the incident. Rootly publishes retrospectives to all three.
Configuration as code
Once a team has more than a handful of services, schedules, alert routes and workflows change often enough that they belong in review. Check for a Terraform provider and an API that cover the objects you change most. Rootly’s Terraform provider manages schedules, escalation policies, alert routes, services, severities and workflows, and Rootly also offers a Pulumi integration, a REST API, a CLI and an MCP server for AI assistants such as Claude and Cursor.
How to test integrations in a proof of concept
Spend the first week of a two-week trial connecting five things: your chat tool, one real monitoring source, one on-call schedule, your issue tracker and your video tool. Then run one test incident end to end:
- Fire a test alert from the monitoring tool.
- Confirm it opens an incident and pages the on-call engineer without anyone copying details.
- Check the incident channel has the right people, the severity and a video link.
- Create an action item and check the ticket appears in your tracker.
- Resolve the incident and export the retrospective to your documents tool.
Write down each manual step as you go. Every one of them is something responders will repeat in every incident until a workflow does it.
How Rootly handles integrations
Rootly’s docs list more than 100 integrations across alerting, chat, paging, ticketing, video, catalogs, documents, identity and AI models. Setup for most is an API key or an OAuth click under Settings → Integrations, and a first incident runs in about 15 minutes with starter templates and defaults. Workflows tie the integrations together, so an alert from Datadog can open an incident, page the owning team, start a Zoom bridge and create a Jira ticket in one run. Browse the full list on the integrations page.
Frequently asked questions
What are the must-have integrations for incident management software?
Eight categories: monitoring and alerting tools that send alerts in, the chat tool where responders work (Slack, Microsoft Teams or Google Chat), on-call paging, an issue tracker for action items (Jira, Linear or ServiceNow), video conferencing, a service catalog, a documents tool for retrospectives, and an API or Terraform provider for managing the setup as code. A gap in any of them becomes a manual step during every incident.
Which integration matters most for incident management?
The alert sources. If alerts from your monitoring tools do not reach the incident tool with their service, severity and dashboard link intact, every incident starts with someone copying details by hand. Check alert intake first, then chat.
How do I test incident management integrations before buying?
During a two-week proof of concept, connect one real monitoring source, your chat tool, one on-call schedule and your issue tracker. Fire a test alert, let it open an incident, create an action item, and check that each system received the right data without anyone copying it across.
What if my monitoring tool has no native integration?
Use a generic webhook alert source. Most incident platforms, including Rootly, accept JSON payloads from any tool that can send a webhook, and map payload fields to alert fields for routing.
How many integrations does Rootly have?
The Rootly docs list more than 100 integrations, covering alerting and observability, chat, paging, ticketing, video, catalogs, documents, HR and identity, AI models, and infrastructure as code. Tools without a native integration connect through the generic webhook alert source, the REST API, the CLI or the MCP server.
Must-have integrations for incident management software