---
title: "Incident Management"
description: "How Incident Management works: alert sources, routing, teams, on-call schedules, escalation, notifications, status pages and reports, and how to set it up."
---

Incident Management (IM) turns alerts into incidents and makes sure the right person is woken up. It works next to [Monitoring](/monitoring): Uptimeify's own checks are one alert source among others (Zabbix, Datadog, Grafana, Prometheus, Sentry, email, your own webhook or code).

Everything below can also be done through the [Incident Management API](/api/incident-management).

## Who can use it

Organization members with the role `admin`, `editor` or `responder`. Customer logins (`readonly`) have no access. Within a team, every member (team role `admin`, `member` or `stakeholder`) may work on that team's incidents; team admins may also change the team itself. Organization admins may do both for every team.

## Setting it up

1. **Activate** Incident Management for your organization (organization admin). In the dashboard: **Incidents**. API: [Activate](/api/incident-management/activate).
2. **Create a team** and add its members (**Incidents → Teams**).
3. **Create a schedule** for the team: who is on call when, and how the rotation moves on.
4. **Build the escalation chain** of the team: tier 1 is paged first; each tier has its schedules and decides when the incident moves on to the next tier.
5. **Connect an alert source** (**Incidents → Sources**): pick a preset, copy its ingest URL into your tool. The [setup guides](/api/incident-management/alert-sources) cover each tool.
6. **Set your own notifications** (**Incidents → Notifications**): how and after how long you are reached, and verify your phone number for SMS and voice calls.
7. **Send a test page** to check that paging reaches you.

## From alert to incident

- An **alert** is one signal from a source. Alerts with the same deduplication key belong together, so a flapping check does not open ten incidents.
- An **incident** groups alerts and is what people work on. It has a **severity** (`sev1` most severe to `sev4`) and a **status**: `triggered` (nobody has reacted yet), `acknowledged`, `investigating`, `identified`, `monitoring`, and finally `resolved` (or `merged` into another incident).
- **Routing rules** decide which team a new incident goes to, for example by source or customer, and can override its severity. Without a matching rule, the source's default team takes it.
- The **monitoring bridge** (organization settings) brings incidents from Uptimeify's own checks into Incident Management automatically.

## On-call and escalation

- A **schedule** defines rotations: who is on shift and when the shift hands over.
- An **override** replaces the schedule for a period: someone takes over a shift, or hands it off while unavailable.
- The **escalation chain** pages tier 1 first. If nobody acknowledges within the tier's time, the next tier is paged. A tier can be paged again before moving on, and the whole chain can repeat.
- On an incident you can **acknowledge** (stops escalation), **snooze** (pause escalation and reminders for up to 7 days), **escalate now** (page the next tier immediately), **add a responder**, **comment**, **change severity**, **merge** duplicates and **resolve**.

## How you are notified

Each person decides for themselves how they are reached:

- **Channels**: push (mobile app), SMS, voice call, email. SMS and voice need a verified phone number.
- **Rules per urgency**: for example "push immediately, SMS after 5 minutes, call after 10 minutes".
- **Severity filter**: for example no SMS or calls for `sev4`.
- The **notification log** shows every notification that was sent, skipped or failed for you.

Shared **channels** (webhook, Slack, email) belong to the organization or a team. One of them can be the **fallback channel**: the last resort when an escalation runs out of tiers.

Details: [Personal Notification Settings](/api/incident-management/notification-settings), [Channels](/api/incident-management/channels).

## Status pages and other tools

- **Status page rules** switch a [status page](/status-pages) to warning or degraded while a team has open incidents of a given severity, with a manual override.
- **Outbound integrations** forward incident events to Slack, Microsoft Teams, Discord, Jira, PagerDuty, Opsgenie or a generic webhook. Failed deliveries can be inspected and retried.

## Reports and audit

- **Analytics**: incident volume, MTTA and MTTR per day, the noise ratio of alerts to incidents, and on-call load per person.
- **Reports**: incident report (by team, severity or month) and on-call report (minutes per person), also as CSV.
- **Audit log** (organization admins): who changed what in Incident Management.

## API

Every step above has an endpoint: [Incident Management API](/api/incident-management). Most endpoints accept an organization-wide API token; personal on-call status and notification settings need a user session.