PagerDuty Analytics

PagerDuty Analytics

Overview

PagerDuty Analytics provides data-driven insights into incident response performance. Key metrics include Mean Time to Acknowledge (MTTA), Mean Time to Resolve (MTTR), incident frequency, and responder workload. These metrics help MSPs identify operational bottlenecks, measure SLA compliance, and demonstrate value to clients.

Anti-triggers

MTTA and MTTR measure how fast responders reacted to a page. They are not the same number as contractual SLA attainment on customer tickets, and reporting one as the other misstates compliance to a client.

• SLA attainment against a customer agreement — first-response and resolution targets, business-hours clocks, and breach counts are freshdesk-sla-business-hours or halopsa-contracts.
• Ticket volume, backlog, or technician utilisation — those come from the PSA, not PagerDuty; use halopsa-tickets or connectwise-psa-tickets.
• Per-shift incident load and burnout risk — Rootly models on-call health directly; use rootly-oncall.

Key Concepts

Core Metrics

Aggregation Levels

Analytics can be aggregated at different levels:

• Account -- Overall account performance
• Service -- Per-service performance
• Team -- Per-team workload and performance
• Escalation Policy -- Policy-level response metrics

Time Ranges

All analytics queries require a time range:

• since -- Start of the analysis period (ISO 8601)
• until -- End of the analysis period (ISO 8601)
• Maximum range varies by endpoint (typically 6 months)

API Patterns

Get Incident Analytics

pagerduty_get_analytics_incidents

Parameters:

• since -- Start of date range (ISO 8601)
• until -- End of date range (ISO 8601)
• urgency -- Filter by urgency (high, low)
• service_ids[] -- Filter by service
• team_ids[] -- Filter by team

Example response:

{
  "data": {
    "mean_seconds_to_acknowledge": 180,
    "mean_seconds_to_resolve": 3600,
    "mean_seconds_to_engage": 120,
    "mean_seconds_to_first_ack": 180,
    "mean_seconds_to_mobilize": 300,
    "total_incident_count": 42,
    "total_interruptions": 8,
    "up_time_pct": 99.5
  },
  "filters": {
    "since": "2026-03-01T00:00:00Z",
    "until": "2026-03-27T00:00:00Z"
  }
}

Get Service Analytics

pagerduty_get_analytics_services

Parameters:

• since -- Start of date range (ISO 8601)
• until -- End of date range (ISO 8601)
• service_ids[] -- Filter to specific services

Example response:

{
  "data": [
    {
      "service_id": "PSVC123",
      "service_name": "Payment API",
      "mean_seconds_to_acknowledge": 120,
      "mean_seconds_to_resolve": 2400,
      "total_incident_count": 15,
      "total_interruptions": 3,
      "up_time_pct": 99.8
    },
    {
      "service_id": "PSVC456",
      "service_name": "Auth Service",
      "mean_seconds_to_acknowledge": 300,
      "mean_seconds_to_resolve": 7200,
      "total_incident_count": 27,
      "total_interruptions": 5,
      "up_time_pct": 98.9
    }
  ]
}

Common Workflows

Monthly Performance Report

1. Call pagerduty_get_analytics_incidents for the past month
2. Call pagerduty_get_analytics_services to break down by service
3. Calculate trends by comparing to the previous month
4. Highlight services with degrading MTTA/MTTR
5. Report on total incident count and interruption frequency

Service-Level SLA Compliance

1. Get analytics for the target service over the SLA period
2. Compare MTTA against the acknowledgement SLA (e.g., < 5 minutes)
3. Compare MTTR against the resolution SLA (e.g., < 4 hours)
4. Calculate uptime percentage
5. Flag any SLA violations

Identify Problem Services

1. Get per-service analytics for the past 30 days
2. Sort by total_incident_count descending to find noisiest services
3. Sort by mean_seconds_to_resolve to find slowest-to-resolve services
4. Cross-reference with service dependencies to assess impact
5. Recommend alert tuning or architectural improvements

On-Call Workload Assessment

1. Get analytics filtered by team for the past month
2. Review total_interruptions to measure off-hours impact
3. Compare workload across teams to identify imbalances
4. Review escalation frequency to assess coverage gaps
5. Recommend schedule adjustments for better distribution

Trend Analysis

1. Query analytics for multiple time periods (e.g., each of the last 6 months)
2. Track MTTA and MTTR trends over time
3. Identify whether incident response is improving or degrading
4. Correlate changes with team size, tool changes, or process improvements
5. Present trends in a summary table

Metric Interpretation Guide

MTTA Benchmarks

MTTR Benchmarks

Error Handling

Insufficient Data

Cause: No incidents in the requested time range Solution: Expand the time range or remove filters

Analytics API Rate Limit

Cause: Exceeded 60 requests per minute for analytics endpoints Solution: Cache results and reduce query frequency; use broader time ranges

Time Range Too Large

Cause: Requested time range exceeds the maximum (typically 6 months) Solution: Break the query into smaller time windows

Best Practices

• Generate reports on a weekly or monthly cadence
• Track MTTA and MTTR trends over time, not just point-in-time values
• Compare metrics across services to identify outliers
• Use service-level analytics to justify infrastructure investments
• Monitor interruption counts to protect on-call responder wellbeing
• Set SLA targets for MTTA and MTTR and measure compliance
• Include analytics in client-facing reports to demonstrate operational maturity

Related Skills

• api-patterns - Rate limits and error handling
• incidents - Incident data that feeds analytics
• services - Service-level performance context
• oncall - On-call workload related to interruptions