Skip to content
Contact us
  • There are no suggestions because the search field is empty.

Basic Concepts

Overview

This article introduces the core AlertOps concepts you need to understand before delving deeper into the Quick Start Guide. It acts as a bridge between the Introduction to AlertOps and hands-on configuration, helping new users build the right mental model of how AlertOps works.

By the end of this article, you will understand:

  • What an alert represents in AlertOps and how alerts flow through the platform.
  • How users, groups, schedules, and escalation policies work together.
  • Who is responsible for responding to alerts and how escalations progress.
  • Which concepts and design choices you must recognize before configuring your first integration.

Audience: New AlertOps customers, administrators, and responders

Prerequisites:

  • Access to an AlertOps account
  • Familiarity with basic incident or monitoring concepts
  • Completion of the Introduction to AlertOps article

 

What Is an Alert in AlertOps?

An alert is the central object in AlertOps. It represents an incident or event generated by an external system (such as a monitoring, ticketing, or security tool) that requires human attention. Alerts can also be created manually.

In AlertOps, alerts are:

  • Received from integrated tools or Created manually.
  • Routed to the right people the first time, every time.
  • Escalated automatically until someone responds

Think of AlertOps as the decision engine that determines who gets notified, when, and how often.

Users

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

Users can act in different roles depending on configuration:

  • Primary responder – First person expected to respond
  • Secondary responder – Backup if no response is received
  • Manager – Final escalation point

Groups

A group is a logical collection of users who share responsibility for alerts which they have been associated to via integrations.

Groups are important because:

  • Escalation Policies apply to the Group Members who are designated as the Primary, Secondary and Manager.
  • Groups can use schedules for on-call rotation policies, if needed.

Note: You can send alerts directly to a single user, but groups are recommended for real-world operations.

Schedules (On-Call Management)

A schedule associates who is on call within a group to when that member is notified for an incoming alert at a given time.

Schedules allow you to:

  • Rotate on-call responsibility
  • Ensure alerts always reach the correct active responder
  • Reduce alert fatigue

If a group has a schedule:

  • Alerts are routed to the currently on-call user

If a group does not have a schedule:

  • Alerts follow the static user order defined in the group

Escalation Policies

An escalation policy controls how alerts progress when no response is received.

Escalation policies define:

  • How many times a user is notified
  • How long AlertOps waits between notifications
  • When alerts move to the next responder level

The default escalation sequence is:

  1. Primary Users – First responders
  2. Secondary Users – Backup responders
  3. Managers – Final escalation

If no schedules are configured, escalation follows the order of users listed in the group.

Responding to Alerts

When an alert is delivered:

  • A Primary User must assign or acknowledge the alert
  • A response stops further escalation

If:

  • Primary users do not respond → Secondary users are notified
  • Secondary users do not respond → Managers are notified

This ensures that alerts are never ignored and always reach a responsible group member.

Alerts can also be acknowledged and responded to from our comprehensive mobile application.

Integrations

An integration defines how alerts enter AlertOps from external systems such as monitoring, observability, ticketing, or security tools.

Integrations are responsible for:

  • Receiving alert data from external systems
  • Creating alerts inside AlertOps
  • Assigning alerts to the correct group

Integrations act as the entry point into AlertOps. Once an alert is created, routing, notifications, schedules, and escalations are handled entirely by groups and escalation policies.

Integrations do not control who is on call or how alerts escalate—they only determine where alerts start.

AlertOps supports the following integration methods:

  • Webhooks
  • Email-based integrations
  • API-based integrations
  • Chat integrations (ex. MS Teams, Slack)

Prebuilt integrations are available for 200+ common monitoring and ticketing tools, and custom integrations can be created for any system capable of sending alerts.

Note: While configuring an integration, you will realise the massive advantage of AlertOps’ design choice of decoupling Groups and Schedules and Escalation Policies from the Integration promoting re-usability and efficient setup and compatibility.

Best Practices

Do:

  • Use groups instead of individual users for production alerts
  • Configure schedules to avoid alert fatigue
  • Clearly define primary, secondary, and manager roles

Don’t:

  • Rely on a single responder for critical alerts
  • Skip escalation testing
  • Send alerts without clear ownership

 

Related Articles