Rootly On-Call

Rootly On-Call Management

Overview

Rootly's on-call management provides visibility into who is currently on-call, what incidents occurred during a shift, and whether responders are at risk of burnout. For MSPs and SRE teams, the on-call tools help with:

• Shift Handoffs — Generate a structured summary of open incidents and shift history before handing off to the next responder
• Health Monitoring — Detect workload health risks before they cause burnout or missed pages
• Shift Metrics — Analyse incident volume, severity distribution, and response time per user, team, or schedule
• Incident Scoping — Pull only the incidents that occurred during a specific shift period

Anti-triggers

This skill analyses on-call — handoffs, shift load, burnout risk. It does not author rotations or decide who gets paged.

• Building or editing a rotation — schedule layers, restrictions, and temporary overrides are pagerduty-oncall; Rootly reads shift data rather than authoring it.
• When the SLA clock runs against a customer — business-hours calendars and coverage windows are a contractual construct, unrelated to responder shifts; use freshdesk-sla-business-hours or halopsa-contracts.
• The incidents themselves — triage, severity, and resolution are rootly-incidents; this skill only scopes them to a shift window.
• Escalation policy configuration — routing and escalation tiers are rootly-alerts.
• A rotation kept in BetterStack — BetterStack owns its schedules next to its monitors and feeds Rootly no shift data; use betterstack-oncall.

MCP Tools

On-Call Tools

Key Concepts

On-Call Shift Structure

A shift is a period assigned to one or more responders in a schedule. Rootly supports:

• Simple rotations — Daily/weekly hand-offs (Engineer A → Engineer B → Engineer C)
• Follow-the-sun — Regional rotations based on business hours
• Layered schedules — Primary + secondary + escalation policy
• Temporary overrides — One-off coverage swaps without changing the base schedule

Health Risk Indicators

check_oncall_health_risk analyses patterns that correlate with burnout:

Escalation Policies

When a page is not acknowledged within the configured timeout:

1. Tier 1 — Primary on-call responder
2. Tier 2 — Secondary responder or team lead
3. Tier 3 — Engineering manager or global escalation
4. Fallback — Slack channel broadcast, status page alert

Common Workflows

On-Call Handoff (End of Shift)

Before handing off to the incoming responder:

1. Call get_oncall_handoff_summary to get a structured overview:
   • Who is currently on-call and when their shift ends
   • Who is next on-call and when they take over
   • Open/in-triage incidents from the current shift with status and severity
2. Review any in_triage incidents — add a handoff note as an action item on each open incident
3. Call get_shift_incidents to list all incidents during the shift (for the outgoing responder's records)
4. Share the handoff summary in the team's Slack channel or incident war room

Reviewing Shift Health (Manager / Team Lead)

1. Call check_oncall_health_risk for the current schedule or team
2. Review flagged risks (high volume, late-night pages, repeat alerts)
3. If risk is elevated:
   • Consider temporarily adding a secondary responder
   • Review the repeat alerts for systemic fixes (runbook gaps, noisy alerts)
   • Check if open incidents can be deprioritised to reduce cognitive load
4. Call get_oncall_shift_metrics grouped by user to identify individual responder load imbalances

Weekly On-Call Retrospective

1. Call get_oncall_shift_metrics with group_by=schedule for the past 7 days
2. Review incident volume per shift and per responder
3. Identify the top noisy alerts (high frequency, low severity)
4. Identify incidents that escalated beyond Tier 1 (indicates alerting or runbook gaps)
5. Create action items in Rootly for the top 3 improvement areas

Pre-Deployment Health Check

Before a major deployment or planned maintenance window:

1. Call check_oncall_health_risk to confirm responders are not already overloaded
2. Call get_oncall_handoff_summary to confirm the on-call team is available during the deployment window
3. If health risk is elevated, consider scheduling the deployment during a lighter shift

Shift Incident Review

After a shift ends, review its full incident history:

1. Call get_shift_incidents scoped to the shift time range
2. Filter by severity=critical or severity=high to focus on the most impactful events
3. For each critical incident, call find_related_incidents to check if it is part of a pattern
4. Flag recurring incidents for postmortem action items

Field Reference

Handoff Summary Fields

Shift Metrics Fields

Error Handling

Best Practices

1. Run handoff summary before every shift transition — Prevents dropped context between responders
2. Act on health risk signals early — Don't wait for burnout; rotate responders proactively
3. Review shift metrics weekly — Trending upward volume is an early warning of systemic issues
4. Tag incidents during a shift — Labels like deployment-related or third-party make shift analysis more useful
5. Combine with incident tools — Always pair on-call review with find_related_incidents for recurring alerts

Related Skills

• Incidents — Incident lifecycle, AI analysis, action items
• API Patterns — Auth, pagination, all available tools