Teams, Rotations, Layers and Routes#

IncidentRelay routes alerts through teams, rotations, layers and notification channels.

CopyIncoming alert
  -> Route
  -> Service
  -> Team
  -> Rotation / Escalation policy
  -> Final schedule
  -> On-call user
  -> Channels

Team#

A team is an on-call ownership unit inside a group.

Example:

CopyGroup: Production
Team: Infrastructure
Team slug: infra

The team slug is commonly used in alert labels, for example with Alertmanager:

Copyteam: infra

Teams define ownership and escalation behavior. Users must be active team members before they can be added to rotation layers.

Service#

A service is a logical affected system owned by a team.

Example:

CopyTeam: Infrastructure
Service: RabbitMQ Cloud
Service slug: rabbitmq-cloud
Type: queue
Environment: production
Criticality: critical

Services help group alerts by the system that is broken, not only by the route that received the alert.

A service can have:

links to dashboards, logs, traces and repositories; runbooks; dependencies; status and impact analytics; optional default rotation or escalation policy.

Rotation#

A rotation is the route-facing schedule object. Routes point to rotations, and rotations produce the final on-call user.

A rotation belongs to one team and can contain one or more layers.

Example:

CopyTeam: infra
Rotation: infra-primary
Timezone: Europe/Berlin
Reminder interval: 300 seconds

When a rotation is created, IncidentRelay creates a default layer. If Add all active team members to this rotation is enabled, active team members are added to that default layer in order.

Layer#

A layer is a schedule rule inside a rotation.

Each layer has:

• name;
• priority;
• enabled flag;
• start time;
• rotation type;
• handoff time;
• optional weekly handoff day;
• timezone;
• ordered members;
• optional active time restrictions.

A rotation may have multiple layers. This is useful for different coverage patterns, for example:

CopyLayer: Business hours
Members: Ivan -> Petr -> Anna
Active: Monday-Friday 09:00-18:00

Layer: Nights
Members: Petr -> Anna -> Ivan
Active: Monday-Friday 18:00-09:00

Layer: Weekend
Members: Anna -> Ivan -> Petr
Active: Saturday-Sunday 00:00-00:00

Layer priority#

When more than one layer is active at the same time, the layer with the higher priority wins.

Copypriority 10: Business hours
priority 20: Nights
priority 30: Weekend

A higher priority layer overrides a lower priority layer for overlapping time windows.

Layer restrictions#

Restrictions define when a layer is active.

If a layer has no restrictions, it is active 24/7.

Restriction examples:

CopyMonday-Friday 09:00-18:00
Monday-Friday 18:00-09:00
Saturday-Sunday 00:00-00:00

00:00-00:00 means the whole day.

Times are interpreted in the layer timezone. Store absolute timestamps in UTC, but define recurring weekly/daily restrictions in local layer time.

Final schedule#

The final schedule is the effective schedule used by the calendar and alert routing.

Order of precedence:

Copyrotation override > highest-priority active layer > no assignee

If no layer is active, IncidentRelay returns no scheduled on-call user for that rotation. Routing and escalation logic can then decide how to handle the alert.

Overrides#

An override temporarily replaces the final scheduled user for a rotation.

Overrides apply on top of all layers.

Example:

CopyRotation: infra-primary
Override: Anna replaces current on-call user
Window: 2026-05-25 12:00 -> 2026-05-26 12:00

Route#

A route can have a default service. This is useful when all alerts entering the route belong to the same logical system.

If one route receives alerts for multiple systems, configure service match rules. A service match rule can use alert labels, annotations or payload fields to attach the alert to the right service.

Example:

CopySource: alertmanager
Team: infra
Rotation: infra-primary
Channels: infra-mattermost, infra-voice-critical
Matchers: {"labels": {"team": "infra"}}

A route may exist without a rotation. This can happen if a rotation is deleted. The route remains, but rotation_id is cleared. In that state, the route still exists as configuration, but it does not assign a scheduled on-call user from that rotation.

Multiple routes for one team#

One team can have multiple independent intake routes:

Copyinfra-alertmanager -> source alertmanager -> Alertmanager token
infra-webhook      -> source webhook      -> Generic webhook token
infra-zabbix       -> source zabbix       -> Zabbix token

Routes can point to the same team, rotation and channels, or they can use different rotations and channels.

Multiple rotations for one team#

One team can have multiple rotations.

Example:

CopyTeam: Cloud
Rotation: Cloud primary
Rotation: Cloud secondary
Rotation: Cloud weekend

In the calendar UI, a rotation is treated as a separate calendar. This prevents multiple rotations for the same team from being mixed into one schedule.