Pagerduty Automation Agent Skill

PagerDuty Automation via Rube MCP

Automate PagerDuty incident management and operations through Composio's PagerDuty toolkit via Rube MCP.

Toolkit docs: composio.dev/toolkits/pagerduty

Prerequisites

• Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
• Active PagerDuty connection via RUBE_MANAGE_CONNECTIONS with toolkit pagerduty
• Always call RUBE_SEARCH_TOOLS first to get current tool schemas

Setup

Get Rube MCP: Add https://rube.app/mcp as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.

• Verify Rube MCP is available by confirming RUBE_SEARCH_TOOLS responds
• Call RUBE_MANAGE_CONNECTIONS with toolkit pagerduty
• If connection is not ACTIVE, follow the returned auth link to complete PagerDuty authentication
• Confirm connection status shows ACTIVE before running any workflows

Core Workflows

1. Manage Incidents

When to use: User wants to create, update, acknowledge, or resolve incidents

Tool sequence:

• PAGERDUTY_FETCH_INCIDENT_LIST - List incidents with filters [Required]
• PAGERDUTY_RETRIEVE_INCIDENT_BY_INCIDENT_ID - Get specific incident details [Optional]
• PAGERDUTY_CREATE_INCIDENT_RECORD - Create a new incident [Optional]
• PAGERDUTY_UPDATE_INCIDENT_BY_ID - Update incident status or assignment [Optional]
• PAGERDUTY_POST_INCIDENT_NOTE_USING_ID - Add a note to an incident [Optional]
• PAGERDUTY_SNOOZE_INCIDENT_BY_DURATION - Snooze an incident for a period [Optional]

Key parameters:

• statuses[]: Filter by status ('triggered', 'acknowledged', 'resolved')
• service_ids[]: Filter by service IDs
• urgencies[]: Filter by urgency ('high', 'low')
• title: Incident title (for creation)
• service: Service object with id and type (for creation)
• status: New status for update operations

Pitfalls:

• Incident creation requires a service object with both id and type: 'service_reference'
• Status transitions follow: triggered -> acknowledged -> resolved
• Cannot transition from resolved back to triggered directly
• PAGERDUTY_UPDATE_INCIDENT_BY_ID requires the incident ID as a path parameter
• Snooze duration is in seconds; the incident re-triggers after the snooze period

2. Inspect Incident Alerts and Analytics

When to use: User wants to review alerts within an incident or analyze incident metrics

Tool sequence:

• PAGERDUTY_GET_ALERTS_BY_INCIDENT_ID - List alerts for an incident [Required]
• PAGERDUTY_GET_INCIDENT_ALERT_DETAILS - Get details of a specific alert [Optional]
• PAGERDUTY_FETCH_INCIDENT_ANALYTICS_BY_ID - Get incident analytics/metrics [Optional]

Key parameters:

• incident_id: The incident ID
• alert_id: Specific alert ID within the incident
• statuses[]: Filter alerts by status

Pitfalls:

• An incident can have multiple alerts; each alert has its own status
• Alert IDs are scoped to the incident
• Analytics data includes response times, engagement metrics, and resolution times

3. Manage Services

When to use: User wants to create, update, or list services

Tool sequence:

• PAGERDUTY_RETRIEVE_LIST_OF_SERVICES - List all services [Required]
• PAGERDUTY_RETRIEVE_SERVICE_BY_ID - Get service details [Optional]
• PAGERDUTY_CREATE_NEW_SERVICE - Create a new technical service [Optional]
• PAGERDUTY_UPDATE_SERVICE_BY_ID - Update service configuration [Optional]
• PAGERDUTY_CREATE_INTEGRATION_FOR_SERVICE - Add an integration to a service [Optional]
• PAGERDUTY_CREATE_BUSINESS_SERVICE - Create a business service [Optional]
• PAGERDUTY_UPDATE_BUSINESS_SERVICE_BY_ID - Update a business service [Optional]

Key parameters:

• name: Service name
• escalation_policy: Escalation policy object with id and type
• alert_creation: Alert creation mode ('create_alerts_and_incidents' or 'create_incidents')
• status: Service status ('active', 'warning', 'critical', 'maintenance', 'disabled')

Pitfalls:

• Creating a service requires an existing escalation policy
• Business services are different from technical services; they represent business-level groupings
• Service integrations define how alerts are created (email, API, events)
• Disabling a service stops all incident creation for that service

4. Manage Schedules and On-Call

When to use: User wants to view or manage on-call schedules and rotations

Tool sequence:

• PAGERDUTY_GET_SCHEDULES - List all schedules [Required]
• PAGERDUTY_RETRIEVE_SCHEDULE_BY_ID - Get specific schedule details [Optional]
• PAGERDUTY_CREATE_NEW_SCHEDULE_LAYER - Create a new schedule [Optional]
• PAGERDUTY_UPDATE_SCHEDULE_BY_ID - Update an existing schedule [Optional]
• PAGERDUTY_RETRIEVE_ONCALL_LIST - View who is currently on-call [Optional]
• PAGERDUTY_CREATE_SCHEDULE_OVERRIDES_CONFIGURATION - Create temporary overrides [Optional]
• PAGERDUTY_DELETE_SCHEDULE_OVERRIDE_BY_ID - Remove an override [Optional]
• PAGERDUTY_RETRIEVE_USERS_BY_SCHEDULE_ID - List users in a schedule [Optional]
• PAGERDUTY_PREVIEW_SCHEDULE_OBJECT - Preview schedule changes before saving [Optional]

Key parameters:

• schedule_id: Schedule identifier
• time_zone: Schedule timezone (e.g., 'America/New_York')
• schedule_layers: Array of rotation layer configurations
• since/until: Date range for on-call queries (ISO 8601)
• override: Override object with user, start, and end times

Pitfalls:

• Schedule layers define rotation order; multiple layers can overlap
• Overrides are temporary and take precedence over the normal schedule
• since and until are required for on-call queries to scope the time range
• Time zones must be valid IANA timezone strings
• Preview before saving complex schedule changes to verify correctness

5. Manage Escalation Policies

When to use: User wants to create or modify escalation policies

Tool sequence:

• PAGERDUTY_FETCH_ESCALATION_POLICES_LIST - List all escalation policies [Required]
• PAGERDUTY_GET_ESCALATION_POLICY_BY_ID - Get policy details [Optional]
• PAGERDUTY_CREATE_ESCALATION_POLICY - Create a new policy [Optional]
• PAGERDUTY_UPDATE_ESCALATION_POLICY_BY_ID - Update an existing policy [Optional]
• PAGERDUTY_AUDIT_ESCALATION_POLICY_RECORDS - View audit trail for a policy [Optional]

Key parameters:

• name: Policy name
• escalation_rules: Array of escalation rule objects
• num_loops: Number of times to loop through rules before stopping (0 = no loop)
• escalation_delay_in_minutes: Delay between escalation levels

Pitfalls:

• Each escalation rule requires at least one target (user, schedule, or team)
• escalation_delay_in_minutes defines how long before escalating to the next level
• Setting num_loops to 0 means the policy runs once and stops
• Deleting a policy fails if services still reference it

6. Manage Teams

When to use: User wants to create or manage PagerDuty teams

Tool sequence:

• PAGERDUTY_CREATE_NEW_TEAM_WITH_DETAILS - Create a new team [Required]

Key parameters:

• name: Team name
• description: Team description

Pitfalls:

• Team names must be unique within the account
• Teams are used to scope services, escalation policies, and schedules

Common Patterns

ID Resolution

Service name -> Service ID:

1. Call PAGERDUTY_RETRIEVE_LIST_OF_SERVICES
2. Find service by name in response
3. Extract id field

Schedule name -> Schedule ID:

1. Call PAGERDUTY_GET_SCHEDULES
2. Find schedule by name in response
3. Extract id field

Incident Lifecycle

1. Incident triggered (via API, integration, or manual creation)
2. On-call user notified per escalation policy
3. User acknowledges -> status: 'acknowledged'
4. User resolves -> status: 'resolved'

Pagination

• PagerDuty uses offset-based pagination
• Check response for more boolean field
• Use offset and limit parameters
• Continue until more is false

Known Pitfalls

ID Formats:

• All PagerDuty IDs are alphanumeric strings (e.g., 'P1234AB')
• Service references require type: 'service_reference'
• User references require type: 'user_reference'

Status Transitions:

• Incidents: triggered -> acknowledged -> resolved (forward only)
• Services: active, warning, critical, maintenance, disabled

Rate Limits:

• PagerDuty API enforces rate limits per account
• Implement exponential backoff on 429 responses
• Bulk operations should be spaced out

Response Parsing:

• Response data may be nested under data or data.data
• Parse defensively with fallback patterns
• Pagination uses offset/limit/more pattern

Quick Reference

| Task | Tool Slug | Key Params |

|------|-----------|------------|

| List incidents | PAGERDUTY_FETCH_INCIDENT_LIST | statuses[], service_ids[] |

| Get incident | PAGERDUTY_RETRIEVE_INCIDENT_BY_INCIDENT_ID | incident_id |

| Create incident | PAGERDUTY_CREATE_INCIDENT_RECORD | title, service |

| Update incident | PAGERDUTY_UPDATE_INCIDENT_BY_ID | incident_id, status |

| Add incident note | PAGERDUTY_POST_INCIDENT_NOTE_USING_ID | incident_id, content |

| Snooze incident | PAGERDUTY_SNOOZE_INCIDENT_BY_DURATION | incident_id, duration |

| Get incident alerts | PAGERDUTY_GET_ALERTS_BY_INCIDENT_ID | incident_id |

| Incident analytics | PAGERDUTY_FETCH_INCIDENT_ANALYTICS_BY_ID | incident_id |

| List services | PAGERDUTY_RETRIEVE_LIST_OF_SERVICES | (none) |

| Get service | PAGERDUTY_RETRIEVE_SERVICE_BY_ID | service_id |

| Create service | PAGERDUTY_CREATE_NEW_SERVICE | name, escalation_policy |

| Update service | PAGERDUTY_UPDATE_SERVICE_BY_ID | service_id |

| List schedules | PAGERDUTY_GET_SCHEDULES | (none) |

| Get schedule | PAGERDUTY_RETRIEVE_SCHEDULE_BY_ID | schedule_id |

| Get on-call | PAGERDUTY_RETRIEVE_ONCALL_LIST | since, until |

| Create schedule override | PAGERDUTY_CREATE_SCHEDULE_OVERRIDES_CONFIGURATION | schedule_id |

| List escalation policies | PAGERDUTY_FETCH_ESCALATION_POLICES_LIST | (none) |

| Create escalation policy | PAGERDUTY_CREATE_ESCALATION_POLICY | name, escalation_rules |

| Create team | PAGERDUTY_CREATE_NEW_TEAM_WITH_DETAILS | name, description |

*Powered by Composio*