Help us improve
Share bugs, ideas, or general feedback.
From betterstack
Manages Better Stack on-call schedules, rotations, calendars, escalation/notification policies, and queries current on-call responders for incident response.
npx claudepluginhub wyre-technology/msp-claude-plugins --plugin betterstackHow this skill is triggered — by the user, by Claude, or both
Slash command
/betterstack:oncallThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Better Stack Uptime includes integrated on-call scheduling that determines who gets paged when a monitor fails. Schedules define rotation patterns, and notification/escalation policies define how and when responders are alerted (via phone, SMS, email, or push). For MSPs, on-call is commonly configured per customer team, with separate schedules for each client's SLA requirements.
Manages PagerDuty on-call: views current on-call users, lists/manages schedules and rotations, configures escalation policies, creates overrides, handles teams.
Automates PagerDuty incident management, services, schedules, escalation policies, and on-call rotations via Rube MCP (Composio) toolkit.
Sets up and manages Grafana OnCall and IRM: alert routing, escalation chains, on-call schedules, integrations with Alertmanager, Grafana Alerting, and Slack.
Share bugs, ideas, or general feedback.
Better Stack Uptime includes integrated on-call scheduling that determines who gets paged when a monitor fails. Schedules define rotation patterns, and notification/escalation policies define how and when responders are alerted (via phone, SMS, email, or push). For MSPs, on-call is commonly configured per customer team, with separate schedules for each client's SLA requirements.
Better Stack schedules define:
Policies define the alert cascade when a monitor goes down:
| Step | Description |
|---|---|
| 1 | Page the on-call schedule via phone, SMS, email, push |
| 2 (after timeout) | Escalate to a secondary schedule or individual |
| 3 (after timeout) | Escalate to team manager or broader group |
Better Stack calls these "notification policies" rather than "escalation policies", but they serve the same purpose.
Monitors are linked to notification policies at creation time. When a monitor goes down:
list_on_call_schedules
Parameters:
per_page - Results per pagepage[after] - Pagination cursorget_on_call_schedule
Parameters:
id - The schedule IDKey fields:
attributes.name - Schedule nameattributes.time_zone - Time zone (e.g., "America/New_York")attributes.current_shift - Current on-call user and shift endattributes.next_shift - Upcoming on-call user and shift startcreate_on_call_schedule
Parameters:
name - Schedule name (required)time_zone - Time zone for the schedulelist_schedule_policies
Parameters:
per_page - Results per pagelist_on_call_schedules to get all schedulesget_on_call_schedule for each relevant schedulecurrent_shift field -- shows who is currently on-call and when their shift endslist_schedule_policies to see all notification policiesBefore transitioning between on-call shifts:
list_incidents with status=acknowledged to find any open, active incidentsget_incident to get current statusget_monitor for the affected serviceacknowledge_incident if they are taking ownershipDuring planned maintenance:
pause_monitor to prevent false pages during the windowcreate_status_page_incident for customer-facing workresume_monitor on all paused monitorslist_incidentsCause: Invalid schedule ID or schedule was deleted Solution: List schedules to verify the correct ID
Cause: Invalid time zone format or member IDs Solution: Verify time zone format and confirm member IDs exist
Cause: Schedule has no on-call user for the current time Solution: Check schedule configuration and ensure rotations cover all time periods
current_shift before major changes to confirm the right person is on-call