Basic Concepts

Purpose

Build the mental model you need before setting up AlertOps. This article sits between the Introduction to AlertOps and the Quick Start Guide, and explains the six concepts every new user has to understand first: Alerts, Users, Groups, Schedules, Escalation Policies, and Integrations.

Audience

Relevant for new users, Admins, and Responders

Read this before configuring anything in AlertOps. It is especially useful for new Admins standing the platform up for their team, and for Responders who want to know why the alerts they receive arrive the way they do.

What You Will Learn

What an alert is in AlertOps and how it moves through the platform.
How Users, Groups, Schedules, and Escalation Policies fit together.
Who is responsible for responding, and how escalations progress when no one does.
Why AlertOps decouples Integrations from Groups, Schedules, and Escalation Policies.

Prerequisites

Access to an AlertOps account (a free trial is fine).
Familiarity with basic incident or monitoring concepts.
Having read the Introduction to AlertOps

The Six Core Concepts at a Glance

Each row is expanded into its own section below.

Concept	What it means
Alert	The central record of an incident or event that needs human attention.
User	An individual who can receive and respond to alerts across email, SMS, voice, and the AlertOps mobile app.
Group	A logical collection of users who share responsibility for a class of alerts. Escalation and schedules attach to the group.
Schedule	A calendar that decides which group member is on-call at a given moment. Supports rotations, shifts, and overrides.
Escalation Policy	The rules that decide how long to wait and who to notify next if an alert is not acknowledged.
Integration	The entry point that converts events from external tools into AlertOps alerts.

Alerts

Relevant for all users

An alert is the central record in AlertOps. It represents an incident or event that needs human attention, usually generated by a monitoring, ticketing, or security tool, and occasionally created manually from the AlertOps UI.

Every alert in AlertOps:

Is received from an integrated tool, or created manually.
Is routed to the right people on the first try, based on group membership and schedule.
Is escalated automatically until someone acknowledges it.

You can think of AlertOps as the decision engine that answers three questions for every alert: who gets notified, how, and how often.

Users

Relevant for Admins and Responders

A user is an individual who can receive and respond to alerts. A user can be notified through multiple channels: email, SMS, voice call, and mobile push (via the AlertOps mobile app).

There are two separate "role-like" concepts you will meet in AlertOps — do not confuse them:

Platform role. Shown in Configuration → Users under the "Role" column. It controls what a user can do across the whole account (for example, App Admin, Basic, Stakeholder, Billing Admin, Integrations Admin). The exact set of roles available in your account depends on your AlertOps package. See User Roles and User Types Overview for the full list.
Group-member role. Shown on a group's Members tab as three checkboxes next to each member: Primary, Secondary, Manager. It controls how that user is treated inside one group's escalation.

Group-member roles are the layer that matters for incident escalation:

First person expected to respond.
Backup if the Primary does not acknowledge in time.
Final escalation point, usually a team lead or on-call manager.

Groups

Relevant for Admins and Group Managers

A group is a logical collection of users who share responsibility for a class of alerts — for example, "Database On-Call" or "Checkout Service." Integrations route alerts to groups, and escalation policies and schedules attach to groups.

In the product, groups and schedules live together under a single nav item: Configuration → Groups and Schedules. Opening a group reveals six tabs that map onto the concepts in this article:

The people in the group and their Primary/Secondary/Manager assignment.
The on-call calendar for the group — shifts, rotations, overrides.
Contact Methods. How the group is reached when a member is not specifically named.
Tags that help route alerts to the correct group.
Who can view or edit this group.
Approval and audit settings for the group.

Groups matter because:

An escalation policy attaches to the group and notifies the Primary, Secondary, and Manager in order.
Groups can use schedules to rotate on-call responsibility over time.
Groups give you a single place to manage ownership as people join and leave teams.

Tip

You can send alerts directly to a single user, but groups are the recommended pattern for production because they survive team changes and let you share on-call load.

Schedules (On-Call Management)

Relevant for Admins and Schedule Managers

A schedule decides which group member is on-call at a given moment. It turns a group's roster into a calendar: shifts, rotations, and overrides.

Schedules let you:

Rotate on-call responsibility across a team.
Ensure alerts always reach whoever is active right now, not a static first name on a list.
Reduce alert fatigue by giving people time off the pager.

Routing behaviour depends on whether the group has a schedule:

Group has a schedule: alerts go to the user who is currently on-call.
Group has no schedule: alerts follow the static user order defined on the group.

Escalation Policies

Relevant for Admins

An escalation policy controls what happens when an alert is not acknowledged in time. It is the "and-then-what" layer on top of routing. An escalation policy defines:

How many times each responder is notified before moving on.
How long AlertOps waits between notifications.
When the alert advances to the next responder level.

The default escalation sequence is:

Primary — first responders.
Secondary — backup responders.
Manager — final escalation point.

If the group has no schedule, escalation follows the order of users listed on the group.

Every escalation policy also has a Notification Type, which decides whose contact preferences are used when the policy notifies someone:

The policy itself defines the notification channels and sequence. Use this when the organization wants a uniform pattern regardless of individual preferences.
User Preference. The policy falls back to each user's personal notification preferences defined on their profile. Use this when individuals control their own channels.

Responding to Alerts

Relevant for Responders

When an alert is delivered, the current Primary user is expected to either assign it to someone else or acknowledge it. An acknowledgement stops further escalation.

If nobody responds:

Primary does not respond → Secondary is notified.
Secondary does not respond → Manager is notified.

This chain makes sure no alert sits unowned. Responders can acknowledge from email, SMS, the web app, or the AlertOps mobile app.

Integrations

Relevant for Admins

An integration is the entry point that turns an external event into an AlertOps alert. Integrations are responsible for:

Receiving alert data from a monitoring, ticketing, observability, or security tool.
Creating an alert inside AlertOps.
Assigning the alert to the correct group.

Integrations do not decide who is on-call or how alerts escalate — they only decide where alerts start. Routing, notifications, schedules, and escalations are handled by the group and its escalation policy.

AlertOps supports inbound integrations (events coming in from external tools), outbound integrations (AlertOps sending data to downstream systems), technical services (pre-packaged integration bundles for an application service), maintenance windows (time windows during which integrations are silenced), and an inbound log (observability into what events came in). In the product, these appear as tabs on the Configuration → Integrations screen: Technical Services, Inbound Integrations, Outbound Integrations, Maintenance Windows, Inbound Log.

The channels an integration can use include:

Email-based integrations.
REST API-based integrations.

Over 200 pre-built integrations are available for common monitoring and ticketing tools. Any system that can send a webhook or email can also be integrated.

Why the decoupling matters

AlertOps deliberately separates Integrations from Groups, Schedules, and Escalation Policies. That way you can add a second monitoring tool for the same team without rebuilding the on-call logic, and reuse a single escalation policy across many integrations. Build the people side of your operations once and plug tools into it.

How It All Fits Together

Example — A Datadog alert meets all six concepts

4. Integration: Datadog fires a webhook into AlertOps. The Datadog integration creates a new alert and assigns it to the "Payments On-Call" group.

5. Schedule: The group's schedule says Priya is the on-call user this week as Primary.

6. Escalation policy: The group's escalation policy notifies Priya by SMS and push. After 5 minutes with no acknowledgement, it pages the Secondary. After 15 minutes with no acknowledgement, it pages the Manager.

7. Response: The Secondary acknowledges from the mobile app. Escalation stops and the timeline is recorded on the alert.

Best Practices

Use groups, not individual users, as the target for production alerts.
Configure schedules to share on-call load and prevent burnout.
Clearly define Primary, Secondary, and Manager for every group.
Test every new escalation policy end-to-end before taking it live.

Don't

Rely on a single responder for critical alerts — there is no backup if they are unavailable.
Skip escalation testing before go-live.
Send alerts without clear ownership (no group, no on-call).