PagerDuty vs incident.io

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   PagerDuty✓fullprobed8/10

   A live probe confirms PagerDuty serves an actual llms.txt at support.pagerduty.com/llms.txt (HTTP 200) with structured knowledge-base content, and PagerDuty separately documents an official MCP server (local and hosted, verified live via runtime probe) enabling agent-native integration. Missing for 10: llms.txt coverage of developer/API docs specifically (only support KB confirmed) and independent hands-on confirmation that agents parse it effectively.

   • [probe] “PROBE llms.txt: HTTP 200 at https://support.pagerduty.com/llms.txt # Knowledge Base Documentation > Get help with configuring your account …”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”

   proof ↗⚑ flag

   incident.io✓fullprobed8/10

   A direct runtime probe confirms `https://docs.incident.io/llms.txt` returns HTTP 200 with a structured index of 452+ help-center pages as markdown, and a further probe shows a companion llms.txt index covering 550+ API-reference pages, confirming agent-oriented docs are genuinely published and machine-readable. Missing for 10: independent/community confirmation that agents actually consume this successfully, and no evidence of an agents.md or similar beyond the llms.txt files.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.incident.io/llms.txt # incident.io - [Help center (452 pages)](https://docs.incident.io/_llms/help…”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to PagerDuty
   PagerDuty✓fullprobed8/10

   PagerDuty exposes a fully headless REST API, async Events API v2, webhooks, and Incident Workflows, all confirmed live via runtime probes (400/401 structured responses), enabling CI/automation pipelines to trigger, manage, and orchestrate incidents without any UI. missing for 10: no first-party CLI tool explicitly marketed for CI pipelines, and no independent case study of running PagerDuty automation fully headless in a CI system.

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”

   proof ↗⚑ flag

   incident.io✓fullprobed7/10

   incident.io exposes a full REST API (api.incident.io) with API-key auth and downloadable per-tag OpenAPI 3.0.3 specs, plus webhooks for event-driven integration and a Terraform provider for infra-as-code — all of which enable declaring/managing incidents and syncing data headlessly from CI/automation pipelines without a UI. Missing for 10: explicit CI/CD pipeline examples or official SDKs/CLI wrapper, and no independent hands-on report of running it in a CI job.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”
   • [claimed-docs] “We're working through our Terraform provider resource by resource to make your infra-as-code setup easier to understand and maintain.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io. This might be useful for annotating graphs in a moni…”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   PagerDuty—none0/10

   All MCP-related evidence describes PagerDuty publishing its own MCP server (server role) so external AI clients can call PagerDuty's tools (pagerduty-docs-1, pagerduty-docs-14, pagerduty-docs-34, pagerduty-probe-2, pagerduty-probe-rt-1) — there is no evidence that PagerDuty itself, or its agentic features like PagerDuty Advance/SRE Agent, can act as an MCP client and plug in external MCP servers to use their tools. Since PagerDuty is a SaaS platform with agentic AI capabilities, this client-side capability is a fair question, but no evidence supports it.

   • [claimed-docs] “provides tools to interact with your PagerDuty account directly from your MCP-enabled client”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”

   proof ↗⚑ flag

   incident.io—none0/10

   All MCP evidence describes incident.io publishing its own remote MCP server so external AI assistants can query incident.io's data — the reverse of what this story asks (the product itself consuming/plugging in third-party MCP servers to gain their tools). No evidence shows incident.io's AI features (e.g. Investigations) can connect out to external MCP servers to use their tools.

   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data.”
   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data. Query …”
   • [claimed-docs] “Query incidents, analyze alerts, check who's on call, manage escalations, and run deep operational analysis — all from your existing AI tool…”
   • [claimed-docs] “connect any AI assistant that supports the Model Context Protocol directly to your incident data”
   • [probe] “official MCP server documented at https://docs.incident.io/ai/remote-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.inci…”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   PagerDuty✓fullprobed9/10

   PagerDuty ships an official documented MCP server (both local GitHub package and hosted remote endpoint at mcp.pagerduty.com), confirmed live via runtime probe returning expected OAuth/Bearer auth challenge, matching official docs. missing for 10: independent third-party hands-on review of the MCP server's tool coverage beyond vendor docs.

   • [claimed-docs] “provides tools to interact with your PagerDuty account directly from your MCP-enabled client”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”

   proof ↗⚑ flag

   incident.io✓fullprobed9/10

   incident.io documents and hosts an official remote MCP server (docs.incident.io/ai/remote-mcp) allowing any MCP-compatible AI assistant to connect and query incidents, alerts, on-call, and analytics; a live runtime probe confirms the hosted mcp.incident.io/mcp endpoint is real and enforces OAuth auth, corroborating the docs beyond marketing claims. Missing for 10: independent third-party (non-vendor) hands-on report of successfully using the MCP server in production.

   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data.”
   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data. Query …”
   • [claimed-docs] “Query incidents, analyze alerts, check who's on call, manage escalations, and run deep operational analysis — all from your existing AI tool…”
   • [claimed-docs] “connect any AI assistant that supports the Model Context Protocol directly to your incident data”
   • [probe] “official MCP server documented at https://docs.incident.io/ai/remote-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.inci…”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   PagerDuty—none0/10

   The evidence pack documents PagerDuty's REST API, Events API, webhooks, and an official MCP server, but no official CLI tool for AI-native workflows is mentioned anywhere in the docs or community sources.

   ⚑ flag

   incident.io—none0/10

   No evidence of an official CLI tool for incident.io; the product offers a REST API, OpenAPI specs, and MCP server, but no dedicated CLI is documented anywhere in the evidence pack. Missing for 10: any mention of an incident.io CLI binary/package, its installation, or command-line usage documentation.

   ⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to PagerDuty
   PagerDuty✓fullprobed9/10

   PagerDuty publishes a well-documented REST API, Events API v2, V3 webhooks, and an official MCP server, all confirmed live via runtime probes (401 auth challenge on MCP endpoint, structured validation errors on Events API), demonstrating genuine programmatic access beyond marketing claims. missing for 10: independent third-party developer testimonials specifically praising API completeness/documentation quality beyond PagerDuty's own docs.

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”

   proof ↗⚑ flag

   incident.io✓fullprobed8/10

   incident.io publishes a documented public REST API (api.incident.io) with API-key auth and downloadable OpenAPI specs (per-tag OpenAPI 3.0.3 JSON verified live), plus 550+ API-reference doc pages, enabling programmatic/agentic control of incidents, alerts, schedules, workflows etc. Missing for 10: a single consolidated OpenAPI root file (only per-tag specs found) and independent third-party developer testimonials on API robustness.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”
   • [claimed-docs] “you will need an API key from your incident.io dashboard to make requests”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.incident.io/llms.txt # incident.io - [Help center (452 pages)](https://docs.incident.io/_llms/help…”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to PagerDuty
   PagerDuty~partialprobed4/10

   PagerDuty's official MCP server and REST API require API-token or OAuth authentication (pagerduty-probe-rt-1, pagerduty-docs-32/39/44), which implies some credential-based access control an agent could use, but the evidence never describes granular scopes, roles, or least-privilege permission tiers specifically for AI-agent credentials. Missing for 10: explicit documentation of scoped/role-based API keys or OAuth scopes for agent use, any read-only vs write-restricted key options, and confirmation these can be issued distinctly per-agent.

   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”

   proof ↗⚑ flag

   incident.io~partialprobed3/10

   incident.io's hosted MCP server (used by AI agents) requires OAuth with a documented protected-resource metadata endpoint, implying some token-scoping mechanism, and the general API requires an API key. However, there is no documentation of configurable least-privilege scopes/roles for API keys or MCP tokens (e.g. read-only vs. write, per-resource permissions) that a user could explicitly issue to an agent. missing for 10: explicit API-key permission/scope configuration UI or docs, role-based least-privilege key issuance, confirmation that MCP OAuth tokens can be scoped down per-agent.

   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.inci…”
   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “you will need an API key from your incident.io dashboard to make requests”
   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to PagerDuty
   PagerDuty✓fullprobed7/10

   PagerDuty provides multiple official developer surfaces — REST API, Events API v2, v3 webhooks, and an official (and now hosted/remote, OAuth-protected) MCP server — all documented on developer.pagerduty.com and confirmed live via runtime probes, which is exactly the kind of programmatic surface an AI-native builder would target. Missing for 10: explicit named official client-library SDKs in multiple languages (e.g., Python/Node SDK packages) beyond the REST/Events APIs, and independent hands-on developer corroboration of SDK ergonomics.

   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”

   proof ↗⚑ flag

   incident.io~partialprobed4/10

   incident.io exposes a full public REST API with an OpenAPI 3.0 spec (and per-tag machine-readable specs verified live) that developers can use to generate client libraries/SDKs, plus API-key auth docs, but there is no evidence of first-party, officially maintained SDK packages (e.g., published npm/pip/Go client libraries) distinct from the raw OpenAPI spec. missing for 10: explicit official SDK packages/libraries in named languages, versioned SDK release notes, or SDK-specific quickstart guides beyond 'generate your own client from OpenAPI'.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”
   • [claimed-docs] “you will need an API key from your incident.io dashboard to make requests”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   PagerDuty✓fullprobed7/10

   PagerDuty's developer docs describe V3 webhooks as a first-class subscription mechanism for incident/priority/responder change events, and the Events API v2 (confirmed live via runtime probe) provides the complementary ingestion side, giving AI-native integrators a documented way to subscribe to and consume PagerDuty events. Missing for 10: independent/hands-on confirmation of webhook subscription setup and payload handling, and no direct linkage of webhooks specifically to AI-agent workflows.

   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks. When compared with previous versions, they provide additional event…”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”

   proof ↗⚑ flag

   incident.io✓fullclaimed7/10

   incident.io documents a native webhooks feature for subscribing to platform events (incident updates, alert/escalation/schedule changes) for external syncing and automation, directly matching the story. Missing for 10: example payload/schema documentation, webhook signing/security details, and independent/hands-on confirmation beyond first-party docs.

   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io. This might be useful for annotating graphs in a moni…”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io... syncing on-call data like alerts, escalations, and…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to incident.io
   PagerDuty~partialclaimed6/10

   PagerDuty Advance and its components (Scribe Agent for post-incident reviews, SRE Agent, Intelligent Alert Grouping via ML, AIOps insights claiming 91% alert reduction) provide AI-generated insights and suggestions embedded in the product, going beyond mere automation. However, evidence is largely first-party marketing copy with no independent/hands-on validation of insight quality, and community feedback is silent on these newer AI features (mostly discussing core paging/escalation). Missing for 10: independent verification of AI-generated insight quality, concrete examples of suggestions surfaced in-product, and community corroboration of the AI/Advance features specifically.

   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty AIOps slashes alerts by 91%, automates repetitive work, and accelerates resolution”
   • [claimed-docs] “Intelligent Alert Grouping automatically consolidates related alerts into a single, actionable incident, using machine learning to reduce al…”

   proof ↗⚑ flag

   incident.io✓fullclaimed8/10

   incident.io ships multiple native AI-insight features directly in-product: Investigations auto-generates root-cause hypotheses from alerts, code, telemetry and past incidents (docs-14,16,23,31,56,62,66), Suggestions/summaries auto-draft incident updates and follow-ups (docs-12,53,54), and Insights dashboards offer trend/period comparisons (docs-18,32,64). Missing for 10: independent/hands-on validation of insight quality and no customer testimonial specifically praising the AI insights (only general company adoption quotes exist).

   • [claimed-docs] “Investigations automatically work out what's going on during an incident, doing the legwork a responder normally would, faster and across ev…”
   • [claimed-docs] “An investigation isn't a single prompt to a model. It's a structured process that gathers evidence, forms a hypothesis, then tests that hypo…”
   • [claimed-docs] “Investigations runs on a purpose-built harness that re-assesses as new signals land, builds findings from real evidence, and pressure-tests …”
   • [claimed-docs] “The moment an incident is declared, an investigation gathers context from across your stack: the alert and its stack trace, similar past inc…”
   • [claimed-docs] “Investigations automatically work out what’s going on during an incident, doing the legwork a responder normally would, faster and across ev…”
   • [claimed-docs] “Find the root cause of incidents faster, with evidence you can trust.”
   • [claimed-docs] “Investigations tackles the hardest part of the incident and gets you from alert to resolution an order of magnitude faster.”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions bas…”
   • [claimed-docs] “responders don’t always have time to digest lots of information or communicate externally what’s going on... This is where suggested summari…”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions”
   • [claimed-docs] “You can also compare with the previous period by toggling it on.”
   • [claimed-docs] “you can choose to include data from the current Week/Month/Quarter... You can also compare with the previous period by toggling it on.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to incident.io
   PagerDuty~partialcommunity7/10

   PagerDuty provides multiple background-automation mechanisms that run without manual triggering: Incident Workflows auto-fire on conditions (e.g., all P1/P2 incidents), Escalation Policies auto-escalate, Event Orchestration auto-dedupes/suppresses alerts, and PagerDuty Advance/SRE Agent is explicitly marketed as an agentic AI that 'handles incidents and fixes' autonomously while a human 'steps in when it matters.' This directly matches the ask of autonomous background automation. Missing for 10: independent/hands-on validation that the SRE Agent or Advance features actually operate unattended in production (community evidence is about legacy escalation/paging behavior, not the newer agentic AI layer), and no user testimonials confirming trust in fully autonomous incident resolution.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

   proof ↗⚑ flag

   incident.io✓fullclaimed8/10

   incident.io ships both a background-automation engine (Workflows, e.g. auto-publishing status pages on incident updates) and an explicitly autonomous AI agent (Investigations) that runs the moment an incident is declared, gathering evidence, forming hypotheses, and testing them without a human prompt — with dedicated trust-and-safety docs describing how it stays 'under your control' while operating autonomously. This directly matches the story of AI-native automations running unattended in the background. missing for 10: independent/hands-on verification that Investigations or Workflows genuinely operate unattended in production (only vendor docs cited), and broader documentation of the general-purpose Workflows automation engine beyond the status-page example.

   • [claimed-docs] “Investigations automatically work out what's going on during an incident, doing the legwork a responder normally would, faster and across ev…”
   • [claimed-docs] “An investigation isn't a single prompt to a model. It's a structured process that gathers evidence, forms a hypothesis, then tests that hypo…”
   • [claimed-docs] “Letting an AI agent work on a live production incident only pays off if you can trust it: to stay within the bounds you set, to show its wor…”
   • [claimed-docs] “Investigations runs on a purpose-built harness that re-assesses as new signals land, builds findings from real evidence, and pressure-tests …”
   • [claimed-docs] “The moment an incident is declared, an investigation gathers context from across your stack: the alert and its stack trace, similar past inc…”
   • [claimed-docs] “With Workflows, you can automatically publish to your status page when an incident is updated.”
   • [claimed-docs] “How investigations stay under your control, keep a full record of their work, and stay honest about what they know.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to incident.io
   PagerDuty~partialclaimed6/10

   PagerDuty Advance embeds agentic AI directly in the product — the SRE Agent handles incidents/fixes and the Scribe Agent assists Post-Incident Reviews, both described as built-in assistants a user can delegate tasks to. However, this is marketing/first-party documentation only, with no independent or hands-on confirmation of how well delegation actually works in practice. Missing for 10: independent/hands-on validation of the SRE Agent or Scribe Agent in real use, and clarity on availability/tier restrictions for PagerDuty Advance.

   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”

   proof ↗⚑ flag

   incident.io✓fullclaimed8/10

   incident.io ships several built-in AI capabilities users can delegate to: Investigations (an agentic, purpose-built harness that gathers evidence, forms/tests hypotheses, and even runs an adversarial agent to pressure-test findings), AI-assisted postmortem drafting/redrafting, and Suggestions which auto-drafts incident updates, summaries and follow-up actions. These are first-party product features distinct from the separate MCP client-connection story. Missing for 10: independent/hands-on user reports validating real-world reliability of these AI features beyond first-party docs.

   • [claimed-docs] “Investigations automatically work out what's going on during an incident, doing the legwork a responder normally would, faster and across ev…”
   • [claimed-docs] “An investigation isn't a single prompt to a model. It's a structured process that gathers evidence, forms a hypothesis, then tests that hypo…”
   • [claimed-docs] “Investigations runs on a purpose-built harness that re-assesses as new signals land, builds findings from real evidence, and pressure-tests …”
   • [claimed-docs] “The moment an incident is declared, an investigation gathers context from across your stack: the alert and its stack trace, similar past inc…”
   • [claimed-docs] “Generate first drafts, get inline review suggestions, and redraft sections with AI.”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions bas…”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to incident.io
   PagerDuty✓fullprobed7/10

   PagerDuty ships an official local and hosted MCP server (verified live via probe returning correct auth challenge) that exposes PagerDuty's incident/on-call tools to any MCP-enabled client, letting AI-native users issue natural-language commands (e.g., via Slack, IDE, or LLM assistants) to trigger/ack/resolve incidents and manage on-call data. This is reinforced by PagerDuty Advance and SRE Agent messaging around agentic/generative AI operating the platform. Missing for 10: no first-party native chat/NL interface within the PagerDuty product itself (reliant on external MCP clients) and no independent hands-on account of a user issuing NL commands end-to-end.

   • [claimed-docs] “provides tools to interact with your PagerDuty account directly from your MCP-enabled client”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”

   proof ↗⚑ flag

   incident.io✓fullprobed8/10

   incident.io ships an official hosted MCP server that lets any AI assistant query incidents, analyze alerts, check on-call, manage escalations and run operational analysis via natural language, confirmed live by a runtime probe (OAuth-protected MCP endpoint) rather than just docs. This is complemented by AI Investigations (agentic root-cause analysis) and an 'update your status page using the agent' feature, showing natural-language/agentic control across incident workflows. Missing for 10: evidence of a native built-in chat/NL command interface inside the product itself (e.g., Slack bot parsing free-form commands) independent of MCP, and independent/hands-on user validation of MCP-driven command accuracy.

   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data.”
   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data. Query …”
   • [claimed-docs] “Query incidents, analyze alerts, check who's on call, manage escalations, and run deep operational analysis — all from your existing AI tool…”
   • [claimed-docs] “connect any AI assistant that supports the Model Context Protocol directly to your incident data”
   • [claimed-docs] “You can now update your status page using the agent, add Pingdom”
   • [probe] “official MCP server documented at https://docs.incident.io/ai/remote-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.inci…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to incident.io
   PagerDuty—none0/10

   Evidence shows PagerDuty publishes REST/Events API overviews and developer docs (e.g. pagerduty-docs-31/32/33/39), but nothing describes an interactive API reference with runnable/try-it examples akin to a Swagger/OpenAPI explorer or code sandbox. This is a fair axis for a product with a public developer API, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”

   proof ↗⚑ flag

   incident.io~partialprobed4/10

   incident.io documents a public API reference with an OpenAPI 3.0 spec (downloadable, and confirmed live per-tag specs at runtime), which is the foundation for an interactive reference, but no evidence describes a 'try it out' console or runnable code examples within the docs themselves. missing for 10: explicit interactive/try-it-out UI in the API reference, runnable code samples, confirmation of live request execution from the docs site.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.incident.io/openapi.json, https://docs.incident.io/swagger.json, https://docs.incident.…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to incident.io
   PagerDuty—none0/10

   The evidence pack documents PagerDuty's REST API, Events API v2, and webhooks overviews, but none of the citations mention an OpenAPI/Swagger spec or any downloadable machine-readable API definition file. Missing for 10: explicit OpenAPI/Swagger spec file or reference, developer portal spec download link, schema versioning info.

   ⚑ flag

   incident.io✓fullprobed9/10

   The API reference docs explicitly offer to 'Download the full OpenAPI 3.0 spec' and a runtime probe confirms machine-readable, keylessly-downloadable per-tag OpenAPI 3.0.3 specs (e.g. incidents-v2.json) are live and parseable. Missing for 10: a single consolidated full-spec file was not directly verified (only per-tag files), and no independent third-party corroboration beyond the probe.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”
   • [claimed-docs] “you will need an API key from your incident.io dashboard to make requests”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to incident.io
   PagerDuty—none0/10

   No evidence pack item mentions a sandbox/test environment, staging account, or test mode for safely trying PagerDuty's API/MCP tooling without affecting production incidents, escalations, or notifications; the closest analogues (MCP server, REST/Events API docs) describe only live production interactions.

   ⚑ flag

   incident.io~partialprobed3/10

   Docs mention a 'test' incident type that lets users 'practice without affecting production' (docs-37), which is a lightweight sandbox-like mechanism within the core incident workflow, but there's no evidence of a dedicated sandbox environment, test API keys, or staging tenant for AI/MCP integrations or API testing separate from production data. Missing for 10: dedicated sandbox/staging environment for API or MCP testing, documented test API keys or environment flags, and any AI-native testing workflow beyond the single 'test incident' type.

   • [claimed-docs] “a **test** incident to practice without affecting production”
   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data.”
   • [probe] “official MCP server documented at https://docs.incident.io/ai/remote-mcp”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to PagerDuty
   PagerDuty~partialcommunity5/10

   PagerDuty's developer docs show clear API versioning (REST API, Events API v2, webhooks v3) with dedicated overview pages, and probes confirm live, self-describing endpoints — but no evidence pack item states an explicit deprecation policy or sunset timeline for older versions. A dated community report also describes real confusion around distinguishing v1 vs v2 event API keys and an unhelpful support response, undercutting confidence that versioning transitions are cleanly documented in practice. Missing for 10: an explicit published deprecation/sunset policy document, and independent confirmation that version transitions are smooth rather than confusing.

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks. When compared with previous versions, they provide additional event…”
   • [community] “I run a service that integrates with pager duty... they have two versions of their event API, and keys for the v1 API don't work with v2 and…”

   proof ↗⚑ flag

   incident.io~partialprobed3/10

   incident.io publishes a documented REST API with downloadable OpenAPI 3.0 specs (including versioned tags like 'incidents-v2') and an API-reference site, suggesting some versioning discipline, but there is no explicit deprecation-policy documentation, changelog for API breaking changes, or SLAs for version support lifecycle. missing for 10: explicit deprecation policy docs, version sunset timelines, migration guides between API versions.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.incident.io/openapi.json, https://docs.incident.io/swagger.json, https://docs.incident.…”

   proof ↗⚑ flag

Agent ops

1. ai-native userMy agent can acknowledge, escalate, and resolve incidents end to end through a documented API or MCP connection — no dashboard in the loop

   weight 3 · round to PagerDuty
   PagerDuty✓fullprobed8/10

   PagerDuty ships an official local and hosted remote MCP server (verified live via runtime probe requiring only API-token/OAuth auth, no dashboard) plus a documented REST/Events API that lets integrations trigger, acknowledge, and resolve incidents, with escalation policies automating assignment without human/dashboard intervention. Independent probes confirm both the MCP endpoint and Events API v2 are functioning, self-describing endpoints, corroborating vendor docs claims. Missing for 10: explicit API/MCP documentation of an 'escalate' action being callable directly (escalation is largely policy-driven rather than an explicit agent-triggered API call), and no independent hands-on account of an agent performing the full ack→escalate→resolve loop end to end.

   • [claimed-docs] “provides tools to interact with your PagerDuty account directly from your MCP-enabled client”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [claimed-docs] “Trigger, acknowledge, and resolve incidents created by service integrations.”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”

   proof ↗⚑ flag

   incident.io~partialprobed7/10

   incident.io ships both a documented REST API (full OpenAPI spec, api.incident.io) and an official hosted remote MCP server that lets AI assistants 'query incidents, analyze alerts, check who's on call, manage escalations, and run deep operational analysis' — covering escalation and much of incident lifecycle management without a dashboard. However, the MCP/API docs emphasize querying, escalating, and analysis; explicit end-to-end 'acknowledge' and 'resolve' actions via MCP tools are not directly named in the evidence, only implied by broader incident-management API coverage. Missing for 10: explicit documentation naming acknowledge/resolve as MCP tool actions, and independent hands-on confirmation that an agent can fully close the incident lifecycle via MCP alone.

   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data. Query …”
   • [claimed-docs] “Query incidents, analyze alerts, check who's on call, manage escalations, and run deep operational analysis — all from your existing AI tool…”
   • [claimed-docs] “connect any AI assistant that supports the Model Context Protocol directly to your incident data”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.inci…”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”
   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”

   proof ↗⚑ flag

Ai investigation

1. ai-native userAn AI investigator digs into the probable cause — correlating changes, telemetry, and similar past incidents — before a human even asks

   weight 2 · round to incident.io
   PagerDuty~partialclaimed5/10

   PagerDuty Advance and the SRE Agent are marketed as agentic AI that 'handles incidents and fixes' and Intelligent Alert Grouping/AIOps use ML to reduce noise, suggesting some proactive investigative capability, but the evidence never describes the agent correlating changes, telemetry, and similar past incidents into a probable-cause narrative before a human asks. Post-Incident Review's Scribe Agent builds narratives, but only after/during incident lifecycle, not as a proactive pre-emptive root-cause investigator. Missing for 10: concrete description of autonomous correlation of deploy/change events + telemetry + historical incident similarity, and evidence of it surfacing findings unprompted.

   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty AIOps slashes alerts by 91%, automates repetitive work, and accelerates resolution”
   • [claimed-docs] “Intelligent Alert Grouping automatically consolidates related alerts into a single, actionable incident, using machine learning to reduce al…”

   proof ↗⚑ flag

   incident.io✓fullclaimed8/10

   incident.io's Investigations feature explicitly proactively gathers evidence the moment an incident is declared — correlating alert stack traces, similar past incidents, code changes, runbooks, and telemetry — and builds/tests hypotheses via a structured harness with adversarial pressure-testing before a human digs in. This directly matches the story's ask for AI-driven correlation of changes, telemetry, and past incidents ahead of human investigation. missing for 10: independent/hands-on validation of investigation accuracy and speed claims beyond vendor docs, and more detail on how 'similar past incidents' matching works technically.

   • [claimed-docs] “Investigations automatically work out what's going on during an incident, doing the legwork a responder normally would, faster and across ev…”
   • [claimed-docs] “An investigation isn't a single prompt to a model. It's a structured process that gathers evidence, forms a hypothesis, then tests that hypo…”
   • [claimed-docs] “Investigations runs on a purpose-built harness that re-assesses as new signals land, builds findings from real evidence, and pressure-tests …”
   • [claimed-docs] “The moment an incident is declared, an investigation gathers context from across your stack: the alert and its stack trace, similar past inc…”
   • [claimed-docs] “Investigations automatically work out what’s going on during an incident, doing the legwork a responder normally would, faster and across ev…”
   • [claimed-docs] “Find the root cause of incidents faster, with evidence you can trust.”
   • [claimed-docs] “Investigations tackles the hardest part of the incident and gets you from alert to resolution an order of magnitude faster.”

   proof ↗⚑ flag

Ai summaries

1. ai-native userAI drafts the postmortem from the incident record — timeline, contributing factors, follow-ups — ready for human review

   weight 2 · round to incident.io
   PagerDuty~partialclaimed7/10

   PagerDuty's Post-Incident Reviews feature explicitly integrates with the PagerDuty Advance Scribe Agent to auto-build chronological incident narratives, uncover systemic patterns, and coordinate preventative follow-up actions — matching the AI-drafted timeline/contributing-factors/follow-ups story closely. Missing for 10: explicit documentation of 'human review' framing/draft-approval workflow, explicit mention of 'contributing factors' as a distinct output field, and any independent/hands-on confirmation of the Scribe Agent's output quality.

   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”

   proof ↗⚑ flag

   incident.io✓fullclaimed8/10

   Docs explicitly describe AI generating first drafts of postmortems, inline review suggestions, and redrafting sections (incident-io-docs-6), plus customizable timelines (docs-4/49), follow-ups tracked separately (docs-7/39/61), and AI summaries/suggestions drawing on incident activity (docs-11/12/53/54) — together covering timeline, contributing factors via investigations (docs-14/31), and follow-ups feeding into a human-reviewable draft. Missing for 10: no independent/hands-on account of the postmortem draft quality or explicit confirmation that 'contributing factors' section specifically is auto-populated, and no third-party review of the AI drafting feature itself.

   • [claimed-docs] “Generate first drafts, get inline review suggestions, and redraft sections with AI.”
   • [claimed-docs] “Our timeline is completely customizable. We generate a simple timeline based on key events, but you can always add your own narrative or eve…”
   • [claimed-docs] “Our timeline is completely customizable. We generate a simple timeline based on key events, but you can always add your own narrative or eve…”
   • [claimed-docs] “We believe you create two types of actions during an incident – those that need doing now and those that should be followed up after an inci…”
   • [claimed-docs] “follow-ups could be: Improve test coverage of a given codepath, Share the debrief document with all affected customers”
   • [claimed-docs] “follow-ups could be: Improve test coverage of a given codepath”
   • [claimed-docs] “This is where suggested summaries comes in.”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions bas…”
   • [claimed-docs] “responders don’t always have time to digest lots of information or communicate externally what’s going on... This is where suggested summari…”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions”
   • [claimed-docs] “Investigations automatically work out what's going on during an incident, doing the legwork a responder normally would, faster and across ev…”
   • [claimed-docs] “The moment an incident is declared, an investigation gathers context from across your stack: the alert and its stack trace, similar past inc…”

   proof ↗⚑ flag

2. ai-native userAI writes the incident as it happens — live summaries, drafted updates, and scribed call notes — so responders respond instead of typing

   weight 3 · round to incident.io
   PagerDuty~partialclaimed7/10

   PagerDuty Advance's generative AI explicitly summarizes incidents and the Scribe Agent builds chronological incident narratives from Slack/incident data, directly matching 'AI writes the incident as it happens' and 'scribed call notes' (pagerduty-docs-23, pagerduty-docs-26, pagerduty-docs-38). However, the Scribe Agent is documented as tied to Post-Incident Reviews (after resolution) rather than clearly live/real-time during the call, and there's no explicit evidence of AI auto-drafting status-page updates in real time. Missing for 10: clear documentation that summaries/notes are generated live during an active incident (not just post-incident), and evidence of AI-drafted stakeholder updates during the incident itself.

   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”

   proof ↗⚑ flag

   incident.io✓fullclaimed7/10

   incident.io documents AI Suggestions that auto-draft updates, summaries, and follow-up actions from incident activity, AI-generated suggested summaries for responders, and Scribe which transcribes/scribes incident calls — directly matching the story's live summaries, drafted updates, and call scribing. Missing for 10: independent/hands-on evidence validating real-world accuracy or adoption of these AI drafting features, and no first-party detail on latency/quality of live summary generation during actual calls.

   • [claimed-docs] “This is where suggested summaries comes in.”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions bas…”
   • [claimed-docs] “No call could be found for the given incident, and so Scribe was unable to find a call to join.”
   • [claimed-docs] “suggested summaries comes in”
   • [claimed-docs] “responders don’t always have time to digest lots of information or communicate externally what’s going on... This is where suggested summari…”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions”
   • [claimed-docs] “when using Scribe to transcribe your incident calls”
   • [claimed-docs] “errors that you might see when using incident.io to manage your incident calls, or when using Scribe to transcribe your incident calls.”

   proof ↗⚑ flag

Escalation

1. sreEscalation policies walk unacknowledged pages through multiple steps — delays, fallback responders, and repeat rounds — until someone acknowledges

   weight 3 · round to PagerDuty
   PagerDuty✓fullcommunity8/10

   Docs explicitly describe escalation policies that notify a single target until acknowledged, with multi-level steps connecting to schedules and users, and incidents escalating per the policy automatically; a first-hand community report confirms it works as designed in practice (notify app, then call after a delay if unacknowledged). missing for 10: no explicit documentation of repeating the full escalation cycle multiple times or granular fallback-responder configuration details beyond general escalation-level language.

   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “The incident escalates in accordance with the service's escalation policy.”
   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

   proof ↗⚑ flag

   incident.io~partialclaimed6/10

   Docs confirm escalation paths with priority/working-hours rules, on-call schedules, and routing alerts to escalation paths ([incident-io-docs-25],[incident-io-docs-50],[incident-io-docs-15],[incident-io-docs-24]), which implies multi-step escalation. However, the evidence never explicitly describes the specific mechanics the story asks about — configurable delay timers between steps, fallback responder chains, or repeat/looping rounds until acknowledgment. Missing for 10: explicit documentation of delay-based escalation steps, fallback responder configuration, and repeat-round behavior on non-acknowledgment.

   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time without causing addition…”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time”
   • [claimed-docs] “Alerts: Configure alerts from your observability tools. Escalations: Route alerts to the appropriate escalation paths, schedules, and team m…”
   • [claimed-docs] “Name your new schedule, set up rotation, and choose the people who should be in that specific s”
   • [claimed-docs] “Leverage schedules to tell us who should be on-call and when.”

   proof ↗⚑ flag

Noise reduction

1. sreDuplicate and related alerts are deduplicated and grouped so one incident pages one human, not fifty

   weight 2 · round to PagerDuty
   PagerDuty✓fullprobed9/10

   PagerDuty documents native dedup via `dedup_key` on Events API integrations, Event Orchestration to automatically deduplicate/suppress alerts, and Intelligent Alert Grouping using ML to consolidate related alerts into a single actionable incident specifically to reduce alert noise for SREs; escalation policies then notify a single target at a time until acknowledged, matching 'one incident pages one human.' Runtime probe confirms the Events API is live and enforces routing/event fields, corroborating the dedup mechanism is real and functioning. Missing for 10: independent/hands-on evidence quantifying grouping accuracy or false-negative rates beyond vendor claims.

   • [claimed-docs] “Services with Events API integrations deduplicate alerts with matching `dedup_key` values.”
   • [claimed-docs] “Intelligent Alert Grouping automatically consolidates related alerts into a single, actionable incident, using machine learning to reduce al…”
   • [claimed-docs] “Intelligent Alert Grouping automatically consolidates related alerts into a single, actionable incident, using machine learning to reduce al…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”

   proof ↗⚑ flag

   incident.io✓fullclaimed8/10

   Docs directly document deduplication by key (dedup key prevents duplicate alerts while one remains active) and alert grouping (related alerts grouped into one alert group for single triage/escalation/incident attach), which together deliver exactly the story of not paging fifty times for one issue. Missing for 10: independent/hands-on validation of grouping accuracy at scale and configurability details beyond docs (e.g., custom grouping rules) aren't detailed.

   • [claimed-docs] “if alert A is received with a deduplication key "x" and alert B with the same deduplication key is received while alert A is still active...…”
   • [claimed-docs] “if alert A is received with a deduplication key "x" and alert B with the same deduplication key is received while alert A is still active...…”
   • [claimed-docs] “a deduplication key is used to uniquely identify alerts and prevent the generation of duplicate alerts”
   • [claimed-docs] “Alert grouping groups those related alerts into a single alert group, so you can triage, escalate and attach them to an incident once”
   • [claimed-docs] “Group related alerts into an alert group so you can triage, escalate and attach them to incidents as one.”

   proof ↗⚑ flag

Paging

1. on-call engineerPages reach me over the channels I choose — push, SMS, phone call, and email — with per-channel notification rules

   weight 2 · round to PagerDuty
   PagerDuty~partialcommunity6/10

   PagerDuty's docs confirm on-call notification rules and readiness reports tied to responder notification configurations, mobile app for push, and escalation policies with schedules controlling who is notified; a hands-on account also confirms app-then-phone-call escalation in practice. However, no evidence explicitly enumerates SMS, phone call, and email as configurable per-channel notification rule options together, so full breadth of channel choice isn't directly documented in this pack. Missing for 10: explicit documentation naming SMS/email/push/phone as selectable channels with per-channel ordering, and independent confirmation of all four channel types working.

   • [claimed-docs] “On-Call Readiness Reports help organizations improve incident response quality by ensuring responders have optimal notification rule configu…”
   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “The PagerDuty mobile app allows you to respond to incidents, view account objects, and manage settings on the go, wherever you are.”
   • [claimed-docs] “Every report provides a Team-filtered overview of each responder's on-call readiness status”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

   proof ↗⚑ flag

   incident.io—none0/10

   The evidence covers on-call schedules, escalation paths (priority/working-hours rules), and alert sources, but nothing in the pack describes per-engineer notification channel preferences (push, SMS, phone call, email) for how a page reaches an individual on-call responder. Escalation-path docs (docs-25/50) discuss routing rules to people/teams, not personal channel selection.

   • [claimed-docs] “Alerts: Configure alerts from your observability tools. Escalations: Route alerts to the appropriate escalation paths, schedules, and team m…”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time without causing addition…”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time”
   • [claimed-docs] “Name your new schedule, set up rotation, and choose the people who should be in that specific s”
   • [claimed-docs] “Leverage schedules to tell us who should be on-call and when.”

   proof ↗⚑ flag

Routing

1. sreAlerts from my monitoring tools are ingested through documented sources and routed to the right team by conditions I define

   weight 3 · round drawn
   PagerDuty✓fullprobed8/10

   PagerDuty documents Events API v2 as a reliable, self-describing ingestion endpoint for monitoring alerts (confirmed live via runtime probe), plus Event Orchestration for condition-based routing/deduplication and Escalation Policies to route to the right team/individual per configurable rules. This directly matches the story of documented ingestion sources routed by defined conditions to the correct team. missing for 10: independent hands-on validation of complex routing/orchestration setups (community evidence only covers general escalation behavior and unrelated API versioning friction, not routing-condition failures).

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “Trigger, acknowledge, and resolve incidents created by service integrations.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

   proof ↗⚑ flag

   incident.io✓fullclaimed8/10

   incident.io documents 40+ pre-built alert sources plus custom HTTP sources, and describes escalation paths with configurable rules by priority and working hours, schedules, alert grouping and deduplication — directly matching the SRE story of documented ingestion and condition-based routing. Missing for 10: independent/hands-on verification of the routing conditions in practice and a public catalog of all 40+ sources beyond the marketing claim.

   • [claimed-docs] “Alerts: Configure alerts from your observability tools. Escalations: Route alerts to the appropriate escalation paths, schedules, and team m…”
   • [claimed-docs] “We have over 40 alert sources ready to go, plus the ability to roll your own via HTTP.”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time without causing addition…”
   • [claimed-docs] “if alert A is received with a deduplication key "x" and alert B with the same deduplication key is received while alert A is still active...…”
   • [claimed-docs] “Alert grouping groups those related alerts into a single alert group, so you can triage, escalate and attach them to an incident once”
   • [claimed-docs] “Group related alerts into an alert group so you can triage, escalate and attach them to incidents as one.”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time”
   • [claimed-docs] “Alerts: Configure alerts from your observability tools.”

   proof ↗⚑ flag

Metrics

1. engineering leaderI get reliability analytics — MTTA/MTTR trends, incident load, on-call health — to see whether we are actually improving

   weight 2 · round to incident.io
   PagerDuty~partialclaimed4/10

   PagerDuty documents On-Call Readiness Reports (responder notification health) and Post-Incident Reviews (systemic pattern uncovering), which touch parts of 'on-call health' and post-incident learning, but no evidence explicitly describes MTTA/MTTR trend dashboards or incident-load analytics over time for leadership reporting. Missing for 10: explicit MTTA/MTTR trend reporting, incident load/volume analytics dashboards, and any leadership-facing 'are we improving' trend view.

   • [claimed-docs] “On-Call Readiness Reports help organizations improve incident response quality by ensuring responders have optimal notification rule configu…”
   • [claimed-docs] “On-Call Readiness Reports help organizations improve incident response quality by ensuring responders have optimal notification rule configu…”
   • [claimed-docs] “Every report provides a Team-filtered overview of each responder's on-call readiness status”
   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”
   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”

   proof ↗⚑ flag

   incident.io~partialclaimed6/10

   incident.io's Insights product provides period-over-period comparisons and dashboards (docs-18/32/64), and its case study claims 'strengthened reliability company-wide' (docs-44), but the evidence pack lacks concrete detail on MTTA/MTTR trend tracking specifically, on-call health metrics, or incident load trending as named leadership-facing analytics — only generic 'Insights' mentions with period comparison toggles are documented. missing for 10: explicit MTTA/MTTR metric definitions and dashboards, on-call health scorecards, incident load/volume trend reporting, and independent validation that leaders use these to measure improvement over time.

   • [claimed-docs] “You can also compare with the previous period by toggling it on.”
   • [claimed-docs] “you can choose to include data from the current Week/Month/Quarter... You can also compare with the previous period by toggling it on.”
   • [claimed-docs] “you can also compare with the previous period by toggling it on”
   • [claimed-docs] “With incident.io, Zendesk modernized incident response across 1,200+ engineers and strengthened reliability company-wide.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to PagerDuty
   PagerDuty~partialprobed5/10

   PagerDuty exposes a REST API and MCP server that could be scripted to act on many items, and it explicitly supports bulk CSV user import, but there is no documented dedicated bulk-operations endpoint (e.g., bulk acknowledge/resolve many incidents in one call) or MCP tool description for batch actions across incidents/services. Missing for 10: explicit bulk incident/alert operation API or MCP tool documentation, and any hands-on evidence of performing large-scale bulk actions via AI-native tooling.

   • [claimed-docs] “Import Users from a CSV”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”

   proof ↗⚑ flag

   incident.io—none0/10

   The evidence pack shows a REST API, webhooks, and an MCP server for querying incidents/alerts/on-call data, but nothing describes bulk/batch operations (e.g., updating many incidents, alerts, or schedules in one call) that an AI agent could invoke at scale. Alert grouping/deduplication reduce duplicate alerts automatically but are not user- or agent-driven bulk actions across arbitrary item sets.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “The incident.io MCP server lets you connect any AI assistant that supports the Model Context Protocol directly to your incident data. Query …”
   • [claimed-docs] “Query incidents, analyze alerts, check who's on call, manage escalations, and run deep operational analysis — all from your existing AI tool…”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”
   • [claimed-docs] “Group related alerts into an alert group so you can triage, escalate and attach them to incidents as one.”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to PagerDuty
   PagerDuty✓fullprobed8/10

   PagerDuty's Incident Workflows and Event Orchestration explicitly support configurable 'if-this-then-that' triggers/actions on incidents and events (auto-trigger for P1/P2, dedup/suppress alerts, escalation policies notifying on-call chains), and this automation is exposed via Events API, REST API, webhooks, and an official MCP server for AI-agent integration. Community evidence corroborates escalation policies working reliably in practice (comm-1), though some report friction with configuration and API versioning (comm-4, comm-6). Missing for 10: independent hands-on validation specifically of Incident Workflow/Orchestration rule automation (vs. just escalation) and confirmation that AI agents can programmatically define these rules via MCP rather than just fetch/manage data.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”

   proof ↗⚑ flag

   incident.io~partialclaimed5/10

   incident.io's Workflows feature lets users configure rule-based automatic actions on incident events (e.g. auto-publish status pages, escalation-path rules keyed on priority/working-hours, alert deduplication/grouping), and webhooks let external systems react to events too. However the evidence never documents a general-purpose rules/workflow builder (trigger types, condition logic, full action catalog) in depth — only a couple of narrow examples are given. missing for 10: comprehensive workflow-engine documentation showing arbitrary event triggers and action library, independent/hands-on verification of workflow automation breadth.

   • [claimed-docs] “With Workflows, you can automatically publish to your status page when an incident is updated.”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time without causing addition…”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time”
   • [claimed-docs] “if alert A is received with a deduplication key "x" and alert B with the same deduplication key is received while alert A is still active...…”
   • [claimed-docs] “Alert grouping groups those related alerts into a single alert group, so you can triage, escalate and attach them to an incident once”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io... syncing on-call data like alerts, escalations, and…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   PagerDuty—none0/10

   PagerDuty's automation features (Incident Workflows, escalation policies) are event-triggered by incident conditions, not time-based recurring job/workflow scheduling; the on-call 'Schedules' evidence (pagerduty-docs-12) covers staff rotation, not scheduled automation jobs. No evidence shows a mechanism for an AI-native user to schedule recurring automated workflows via API or MCP.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident... you can apply "if-this-then-that" logic to orchestrate the…”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”

   proof ↗⚑ flag

   incident.io—none0/10

   incident.io's Workflows feature (docs-9) is event-triggered (e.g., publish to status page when an incident updates) and on-call 'Schedules' (docs-24, docs-42) refer to rotation calendars, not recurring automation jobs. No evidence describes cron-style or time-based recurring workflow scheduling that an AI-native user could configure via API, MCP, or workflow builder.

   • [claimed-docs] “With Workflows, you can automatically publish to your status page when an incident is updated.”
   • [claimed-docs] “Name your new schedule, set up rotation, and choose the people who should be in that specific s”
   • [claimed-docs] “Leverage schedules to tell us who should be on-call and when.”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   PagerDuty—none0/10

   PagerDuty documents building automations (Incident Workflows, Event Orchestration, escalation policies) but no evidence pack item describes versioning, change history, review workflows, or rollback capability for these automations. The axis clearly applies since PagerDuty offers configurable automation objects, but no supporting evidence exists for version control or rollback.

   ⚑ flag

   incident.io—none0/10

   incident.io ships Workflows/automation features and even an in-progress Terraform provider for infra-as-code, but nothing in the evidence describes version history, diff/review, or rollback capabilities specifically for automations/workflows — the Terraform mention only covers general infra config, not workflow versioning or revert. Missing for 10: workflow version history, change review/diff UI, and a rollback mechanism for automations.

   • [claimed-docs] “We're working through our Terraform provider resource by resource to make your infra-as-code setup easier to understand and maintain.”

   proof ↗⚑ flag

Runbooks

1. sreRunbooks attach to incidents and their steps can trigger automatically — creating channels, assigning tasks, running diagnostics

   weight 2 · round to PagerDuty
   PagerDuty~partialclaimed7/10

   PagerDuty's Incident Workflows explicitly support automated, triggerable 'if-this-then-that' responses attached to incidents (e.g., auto-trigger for P1/P2 incidents), which functionally matches the runbook-automation story, and Advance/agentic features add AI-driven remediation. However, the evidence never uses the term 'runbook' nor cites concrete step examples like auto-creating chat channels or running diagnostics scripts as named actions. Missing for 10: explicit runbook terminology, named step types (channel creation, task assignment, diagnostics execution), and independent/hands-on confirmation of these specific triggered actions.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident... you can apply "if-this-then-that" logic to orchestrate the…”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”
   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”

   proof ↗⚑ flag

   incident.io—none0/10

   The evidence only mentions 'runbooks' in passing as an input source that investigations reference (docs-31), and describes a separate 'Workflows' automation feature that can auto-publish status pages (docs-9), but there is no documentation tying runbook steps to automatic actions like creating channels, assigning tasks, or running diagnostics as the story describes. missing for 10: dedicated runbook-step automation, evidence of channel-creation/task-assignment/diagnostic triggers, any docs page specifically on runbook execution.

   • [claimed-docs] “The moment an incident is declared, an investigation gathers context from across your stack: the alert and its stack trace, similar past inc…”
   • [claimed-docs] “With Workflows, you can automatically publish to your status page when an incident is updated.”

   proof ↗⚑ flag

Workflows

1. sreA condition-based workflow engine automates the toil — updates, reminders, field changes — triggered by incident events

   weight 2 · round to PagerDuty
   PagerDuty✓fullclaimed7/10

   PagerDuty Incident Workflows are explicitly documented as a condition-based automation engine using 'if-this-then-that' logic that triggers automated actions (e.g., field changes, notifications, reminders) based on incident event conditions like P1/P2 severity. Escalation policies and event orchestration further automate incident-response toil (assignment, deduplication, escalation) without manual intervention. Missing for 10: independent/hands-on corroboration of Incident Workflows specifically (community evidence discusses escalation and paging generally but not the workflow engine), and detailed examples of field-change/reminder automation beyond marketing-style docs.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident... you can apply "if-this-then-that" logic to orchestrate the…”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”
   • [claimed-docs] “The incident escalates in accordance with the service's escalation policy.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”

   proof ↗⚑ flag

   incident.io~partialclaimed6/10

   incident.io documents Workflows that trigger automated actions on incident events (e.g. auto-publishing status page updates, follow-up creation, webhooks for event-driven automation), which supports condition-based automation of toil like updates and field changes. However, the evidence pack lacks a dedicated 'Workflows' engine page detailing conditions/triggers/actions configuration in depth — only auto-publishing and adjacent features are directly cited. Missing for 10: a first-party doc explicitly describing the workflow engine's condition-based trigger/action model (e.g. 'when X happens, do Y' rules beyond status-page publishing), evidence of reminders/field-change automation specifically, and independent/hands-on confirmation of workflow reliability.

   • [claimed-docs] “With Workflows, you can automatically publish to your status page when an incident is updated.”
   • [claimed-docs] “We believe you create two types of actions during an incident – those that need doing now and those that should be followed up after an inci…”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io. This might be useful for annotating graphs in a moni…”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io... syncing on-call data like alerts, escalations, and…”

   proof ↗⚑ flag

Communications

1. engineering leaderInternal stakeholders get structured incident updates they can subscribe to, without joining the war room

   weight 1 · round to PagerDuty
   PagerDuty~partialclaimed6/10

   PagerDuty Status Pages give stakeholders visual, real-time updates on incident status 'without context switching to other tools,' and Incident Workflows/Post-Incident Reviews can push structured summaries, all without requiring war-room participation. However, the evidence never explicitly confirms a subscription/notification mechanism for external stakeholders or a dedicated 'structured update' template feature. Missing for 10: explicit subscribe/follow functionality for status pages, dedicated stakeholder-update templates, and independent confirmation that non-responders actually use this instead of joining incident channels.

   • [claimed-docs] “PagerDuty Status Pages provide visual, real-time insights into an organization's operations, and the status of incident resolution.”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools, giving user…”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools.”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”

   proof ↗⚑ flag

   incident.io~partialclaimed5/10

   Private/public Status Pages and auto-publish Workflows let stakeholders get structured updates without joining the incident channel, and AI-generated 'suggested summaries' support drafting those updates. However, no explicit 'subscribe' mechanism for internal stakeholders (e.g., follow/opt-in to specific incidents) is documented, and evidence focuses more on customer-facing status pages than internal exec/stakeholder subscriptions. Missing for 10: explicit internal-stakeholder subscription/opt-in feature, evidence of granular update cadence or digest for non-responders, and independent confirmation of use for internal (not just customer) communications.

   • [claimed-docs] “With Workflows, you can automatically publish to your status page when an incident is updated.”
   • [claimed-docs] “We've built an easy and delightful way to communicate with customers during an incident with our public and private Status Pages.”
   • [claimed-docs] “We’ve built an easy and delightful way to communicate with customers during an incident with our public and private Status Pages.”
   • [claimed-docs] “responders don’t always have time to digest lots of information or communicate externally what’s going on... This is where suggested summari…”
   • [claimed-docs] “Suggestions uses AI to help teams communicate better during incidents by automatically drafting updates, summaries and follow-up actions”
   • [claimed-docs] “Automate status page incidents, maintenance windows, and embed status data in your product.”

   proof ↗⚑ flag

Coordination

1. engineering leaderIncidents carry defined roles (commander, comms lead) and task checklists so response stays coordinated under pressure

   weight 1 · round to PagerDuty
   PagerDuty~partialclaimed4/10

   PagerDuty's Incident Workflows and Escalation Policies show automated, rule-based assignment and orchestration of incident response tasks, which speaks to coordinated response, but no evidence explicitly describes named incident roles like 'commander' or 'comms lead' or human-facing task checklists for responders. missing for 10: explicit incident commander/communications lead role definitions, structured task checklists per role, and any hands-on validation that these roles function as intended under pressure.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”

   proof ↗⚑ flag

   incident.io—none0/10

   The evidence pack covers incident declaration, timelines, follow-ups, on-call scheduling, and AI investigations, but nowhere mentions assignable incident roles (e.g., commander, comms lead) or structured task checklists during response. Missing for 10: any documentation of role assignment features, role definitions, or checklist/runbook task tracking during active incidents.

   ⚑ flag

Declaration

1. on-call engineerDeclare and run an incident from chat — Slack or Teams — with channels, roles, and updates created for me

   weight 3 · round to incident.io
   PagerDuty~partialclaimed3/10

   PagerDuty's own marketing states you can 'manage incidents and coordinate response from Slack' (pagerduty-docs-2), and Post-Incident Reviews integrate with Slack data (pagerduty-docs-23/38), indicating some Slack tie-in, but there is no documented capability for declaring an incident directly from a Slack/Teams command with automatic channel creation, role assignment, and status updates. Missing for 10: explicit ChatOps slash-command/incident-declaration workflow docs, Teams support, evidence of auto-created channels and role assignment from chat, and any independent confirmation of this specific flow.

   • [claimed-docs] “Manage incidents and coordinate response from Slack or your IDE.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”

   proof ↗⚑ flag

   incident.io✓fullclaimed7/10

   Docs explicitly confirm incidents can be declared in seconds directly from Slack or Microsoft Teams, and other docs show incident.io auto-generates a timeline and provides post-incident/update tooling. However, the evidence pack doesn't explicitly detail automatic Slack/Teams channel creation or role assignment during declaration. Missing for 10: explicit documentation of automatic channel provisioning and role assignment during declare flow, hands-on/independent confirmation of the chat-native flow.

   • [claimed-docs] “Declaring an incident takes seconds, and you can do it right from where your team already works, whether that's Slack or Microsoft Teams.”
   • [claimed-docs] “Declaring an incident takes seconds, and you can do it right from where your team already works, whether that’s Slack or Microsoft Teams.”
   • [claimed-docs] “Our timeline is completely customizable. We generate a simple timeline based on key events, but you can always add your own narrative or eve…”
   • [claimed-docs] “a **test** incident to practice without affecting production”
   • [claimed-docs] “responders don’t always have time to digest lots of information or communicate externally what’s going on... This is where suggested summari…”

   proof ↗⚑ flag

Timeline

1. sreThe incident timeline is captured automatically — alerts, actions, and chat decisions — and I can edit or annotate it afterwards

   weight 2 · round to incident.io
   PagerDuty~partialclaimed5/10

   PagerDuty's Post-Incident Reviews integrate with the incident lifecycle and Slack data (via the Scribe Agent) to automatically build 'chronological incident narratives,' which is evidence of automated timeline capture of alerts/actions/chat, and PIRs function as editable review documents. However, there's no explicit evidence of a dedicated incident timeline UI feature, nor documentation confirming that responders can directly edit or annotate the captured timeline entries after the fact. Missing for 10: explicit incident timeline/log feature docs, confirmation of manual editing/annotation of timeline entries, and independent corroboration of automatic chat-decision capture accuracy.

   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”

   proof ↗⚑ flag

   incident.io✓fullclaimed8/10

   Docs confirm automatic timeline generation from key events (alerts, actions, chat) with full manual editing/annotation support, including adding custom narrative or external-system events (incident-io-docs-4, docs-38, docs-49). Alert/on-call integration and chat-based incident declaration (Slack/Teams) further support that timeline events originate from these sources automatically. Missing for 10: independent hands-on verification of exactly which event types (alerts vs chat decisions) populate automatically versus require manual entry, and no third-party review confirming the editing UX in practice.

   • [claimed-docs] “Our timeline is completely customizable. We generate a simple timeline based on key events, but you can always add your own narrative or eve…”
   • [claimed-docs] “you can always add your own narrative or events that happened in an external system”
   • [claimed-docs] “Our timeline is completely customizable. We generate a simple timeline based on key events, but you can always add your own narrative or eve…”
   • [claimed-docs] “Declaring an incident takes seconds, and you can do it right from where your team already works, whether that's Slack or Microsoft Teams.”
   • [claimed-docs] “Declaring an incident takes seconds, and you can do it right from where your team already works, whether that’s Slack or Microsoft Teams.”
   • [claimed-docs] “Alerts: Configure alerts from your observability tools. Escalations: Route alerts to the appropriate escalation paths, schedules, and team m…”

   proof ↗⚑ flag

Alert sources

1. sreFirst-party integrations cover my observability stack — Datadog, Grafana, Prometheus, CloudWatch, Sentry — with documented setup

   weight 3 · round drawn
   PagerDuty—none0/10

   The evidence pack documents generic integration mechanisms (Events API v2, REST API, webhooks, service integrations) but never names or links documented setup guides for the specific tools cited in the story—Datadog, Grafana, Prometheus, CloudWatch, or Sentry—so there is no evidence of first-party, per-tool documented integrations for this observability stack.

   • [claimed-docs] “Services with Events API integrations deduplicate alerts with matching `dedup_key` values.”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”

   proof ↗⚑ flag

   incident.io—none0/10

   Evidence only mentions generic claims like '40 alert sources ready to go' and 'Configure alerts from your observability tools' without naming or documenting setup for Datadog, Grafana, Prometheus, CloudWatch, or Sentry specifically. No integration-specific setup docs, screenshots, or named connectors for any of these five tools appear anywhere in the pack.

   • [claimed-docs] “We have over 40 alert sources ready to go, plus the ability to roll your own via HTTP.”
   • [claimed-docs] “Alerts: Configure alerts from your observability tools. Escalations: Route alerts to the appropriate escalation paths, schedules, and team m…”
   • [claimed-docs] “Alerts: Configure alerts from your observability tools.”

   proof ↗⚑ flag

Workflow tools

1. sreThe platform integrates with the tools around the incident — Jira, Slack, Teams, Zoom, GitHub — so state flows both ways

   weight 2 · round to incident.io
   PagerDuty~partialclaimed5/10

   PagerDuty documents strong two-way integration infrastructure (REST API, Events API, V3 webhooks, MCP server) and explicitly calls out Slack integration for incident response and Post-Incident Reviews pulling in Slack data, but the evidence pack never names Jira, Teams, Zoom, or GitHub as specific bidirectional integrations — only Slack is concretely evidenced. Missing for 10: explicit documented integrations/state-sync with Jira, Microsoft Teams, Zoom, and GitHub specifically, plus confirmation these flow both ways rather than just PagerDuty→tool notifications.

   • [claimed-docs] “Manage incidents and coordinate response from Slack or your IDE.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks. When compared with previous versions, they provide additional event…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”

   proof ↗⚑ flag

   incident.io~partialclaimed6/10

   Docs clearly show two-way integration with Slack and Microsoft Teams (declaring incidents, timeline updates) plus a generic webhook/API layer and 40+ alert-source integrations that could plumb in tools like Jira/GitHub/Zoom, and investigations pull in 'recent code changes' implying some code-host integration. However, no evidence explicitly names Jira, GitHub, or Zoom as first-class two-way integrations. Missing for 10: explicit Jira ticket sync, GitHub PR/commit linkage, Zoom call integration documentation, and independent confirmation these named tools sync state bidirectionally.

   • [claimed-docs] “Declaring an incident takes seconds, and you can do it right from where your team already works, whether that's Slack or Microsoft Teams.”
   • [claimed-docs] “Declaring an incident takes seconds, and you can do it right from where your team already works, whether that’s Slack or Microsoft Teams.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io. This might be useful for annotating graphs in a moni…”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io... syncing on-call data like alerts, escalations, and…”
   • [claimed-docs] “We have over 40 alert sources ready to go, plus the ability to roll your own via HTTP.”
   • [claimed-docs] “The moment an incident is declared, an investigation gathers context from across your stack: the alert and its stack trace, similar past inc…”
   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”

   proof ↗⚑ flag

Mobile

1. on-call engineerA full mobile app lets me acknowledge, escalate, and resolve from my phone at 3am

   weight 2 · round to PagerDuty
   PagerDuty~partialcommunity6/10

   PagerDuty's mobile app docs confirm responding to incidents, viewing objects, and managing settings on the go, and community evidence confirms the app is used for acknowledging pages and is core to escalation flow. However, the evidence doesn't explicitly confirm resolve/escalate actions from the app specifically (only 'respond to incidents' generally) and one community comment notes engineers 'only use the app for ack'ing the page,' suggesting other actions may be underused or less central. missing for 10: explicit documentation/hands-on confirmation of resolving and manually escalating incidents (not just acknowledging) from the mobile app, and independent third-party mobile UX reviews.

   • [claimed-docs] “The PagerDuty mobile app allows you to respond to incidents, view account objects, and manage settings on the go, wherever you are.”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”
   • [community] “PagerDuty is super expensive. A lot of the bells and whistles they have aren't useful. Engineers never need to actually use the PagerDuty we…”

   proof ↗⚑ flag

   incident.io—none0/10

   The evidence pack shows incident.io operates through Slack/Teams, web dashboard, escalation paths, and on-call schedules, but contains no mention of a dedicated mobile app for acknowledging, escalating, or resolving incidents from a phone. Mobile app capability is a reasonable expectation for an on-call/incident management product, so the axis applies, but nothing in the evidence confirms it exists.

   • [claimed-docs] “Alerts: Configure alerts from your observability tools. Escalations: Route alerts to the appropriate escalation paths, schedules, and team m…”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time without causing addition…”
   • [claimed-docs] “Declaring an incident takes seconds, and you can do it right from where your team already works, whether that's Slack or Microsoft Teams.”

   proof ↗⚑ flag

Quality of life

1. on-call engineerMy shifts sync to my personal calendar via a feed so I always know when I'm on the hook

   weight 1 · round drawn
   PagerDuty—none0/10

   The evidence pack covers schedules, escalation policies, and mobile app notifications but contains no mention of an iCal/calendar feed or personal calendar sync capability for on-call shifts.

   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [claimed-docs] “The PagerDuty mobile app allows you to respond to incidents, view account objects, and manage settings on the go, wherever you are.”

   proof ↗⚑ flag

   incident.io—none0/10

   The docs describe calendar feeds only for importing personal holidays/PTO into incident.io, not for exporting an engineer's on-call shifts as a subscribable feed to their personal calendar. No evidence pack item shows an outbound iCal/webcal feed of on-call schedules for personal calendar apps.

   • [claimed-docs] “If your calendar system or HRIS provides an iCal feed, you can import your team's personal holidays (time-off, vacation, PTO) into incident.…”
   • [claimed-docs] “you can import your team's personal holidays (time-off, vacation, PTO) into incident.io”
   • [claimed-docs] “you can import your team’s personal holidays (time-off, vacation, PTO) into incident.io”

   proof ↗⚑ flag

Schedules

1. sreBuild on-call schedules with rotations, layers, time zones, and round-robin coverage that match how my teams actually work

   weight 3 · round to incident.io
   PagerDuty~partialcommunity4/10

   Docs confirm schedules exist to map coverage needs (pagerduty-docs-12) and escalation policies connect services to users/schedules (pagerduty-docs-7/37), but no evidence explicitly documents layers, rotations, round-robin coverage, or time-zone handling within schedules, and community feedback flags 'clunky calendar overrides' (pagerduty-comm-4) as a friction point. Missing for 10: explicit documentation of schedule layers, rotation types, round-robin distribution, and time-zone-aware scheduling, plus hands-on confirmation these work smoothly.

   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [community] “None of them have SCIM integration to make managing your teams automatic. All of them have clunky calendar overrides. For PagerDuty you need…”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

   proof ↗⚑ flag

   incident.io~partialclaimed6/10

   Docs confirm core on-call scheduling: creating schedules with rotations and choosing on-call members, escalation paths with priority/working-hours rules, and calendar-feed imports for PTO/time-off (docs-15, docs-24, docs-42, docs-25, docs-50, docs-26, docs-43, docs-60). However, the evidence never explicitly mentions 'layers' as a schedule concept, multi-timezone handling within schedules, or round-robin rotation logic by name. missing for 10: explicit documentation of layered schedules, timezone-aware rotation configuration, and round-robin coverage patterns.

   • [claimed-docs] “Alerts: Configure alerts from your observability tools. Escalations: Route alerts to the appropriate escalation paths, schedules, and team m…”
   • [claimed-docs] “Name your new schedule, set up rotation, and choose the people who should be in that specific s”
   • [claimed-docs] “Leverage schedules to tell us who should be on-call and when.”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time without causing addition…”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time”
   • [claimed-docs] “If your calendar system or HRIS provides an iCal feed, you can import your team's personal holidays (time-off, vacation, PTO) into incident.…”
   • [claimed-docs] “you can import your team's personal holidays (time-off, vacation, PTO) into incident.io”
   • [claimed-docs] “create schedules that will work for your organization's needs”

   proof ↗⚑ flag

2. on-call engineerTake an override, swap a shift, or request coverage without an admin rebuilding the schedule

   weight 2 · round to PagerDuty
   PagerDuty~partialcommunity3/10

   PagerDuty's schedule docs describe mapping coverage needs (docs-12) and escalation policies tied to schedules (docs-7), and a community comment confirms that calendar overrides exist in the product (comm-4), but no evidence details a self-service flow for taking an override, swapping a shift, or requesting coverage without admin involvement — the same community comment actually calls overrides 'clunky,' undercutting a smooth self-service experience. Missing for 10: first-party docs on override/shift-swap UI or API, evidence of coverage-request workflow, and confirmation these actions require no admin intervention.

   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [community] “None of them have SCIM integration to make managing your teams automatic. All of them have clunky calendar overrides. For PagerDuty you need…”

   proof ↗⚑ flag

   incident.io—none0/10

   Docs describe schedule creation, rotations, escalation paths, and importing calendar/PTO feeds, but none of the evidence mentions an on-call engineer being able to self-service an override, swap a shift, or request coverage without admin intervention. This is a fair axis for an on-call scheduling product, so absence of evidence yields 'none'.

   • [claimed-docs] “Name your new schedule, set up rotation, and choose the people who should be in that specific s”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time without causing addition…”
   • [claimed-docs] “If your calendar system or HRIS provides an iCal feed, you can import your team's personal holidays (time-off, vacation, PTO) into incident.…”
   • [claimed-docs] “Leverage schedules to tell us who should be on-call and when.”
   • [claimed-docs] “You can now set up rules around priority and/or working hours to ensure you page the right people at the right time”
   • [claimed-docs] “you can import your team’s personal holidays (time-off, vacation, PTO) into incident.io”
   • [claimed-docs] “create schedules that will work for your organization's needs”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to PagerDuty
   PagerDuty~partialprobed7/10

   PagerDuty documents a broad REST API for configuration/user/workflow management, an Events API v2, V3 webhooks, and an official MCP server (with a live hosted endpoint) letting AI clients trigger/manage incidents, confirming strong API-driven parity with UI actions. However, no evidence explicitly confirms 100% feature parity between API and UI, and community comments note at least one case (OIDC/Azure AD SSO config) requiring manual support intervention outside normal UI/API self-service, suggesting some settings aren't fully API/UI accessible. Missing for 10: an explicit parity statement or audit showing all UI functions are API-exposed, and independent verification beyond vendor docs.

   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [community] “None of them have SCIM integration to make managing your teams automatic. All of them have clunky calendar overrides. For PagerDuty you need…”

   proof ↗⚑ flag

   incident.io~partialprobed6/10

   incident.io documents a public REST API (api.incident.io) with per-tag OpenAPI 3.0.3 specs covering incidents, alerts, on-call/schedules, status pages, and webhooks, plus an MCP server that lets AI tools query incidents, alerts, on-call and escalations — evidence of broad, structured API coverage across most core UI functions. However, there is no explicit vendor claim or independent confirmation of full UI/API parity, and newer AI-native features like Investigations, AI summaries/suggestions, and Scribe are described only as UI/product capabilities without documented API/programmatic equivalents. Missing for 10: an explicit parity statement or docs, API coverage confirmation for Investigations/AI-suggestion features, and independent/hands-on verification that every UI action has an API equivalent.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”
   • [claimed-docs] “Automate status page incidents, maintenance windows, and embed status data in your product.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io.”
   • [claimed-docs] “Query incidents, analyze alerts, check who's on call, manage escalations, and run deep operational analysis — all from your existing AI tool…”
   • [probe] “official MCP server documented at https://docs.incident.io/ai/remote-mcp”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   PagerDuty~partialclaimed4/10

   PagerDuty's REST API exposes configuration and incident data programmatically (docs-32, docs-39, docs-44), which a technically capable user could use to pull out their data, but there is no documented bulk 'export all my data' feature, data-portability tool, or GDPR-style export mechanism in open formats. Missing for 10: an explicit account-wide export/backup feature, documentation of supported open export formats (CSV/JSON dump), and confirmation that all data types (incidents, schedules, users, workflows) can be fully extracted and are portable to another system.

   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [claimed-docs] “Import Users from a CSV”

   proof ↗⚑ flag

   incident.io~partialprobed4/10

   incident.io exposes a documented REST API (OpenAPI 3.0 spec, per-tag JSON specs) and webhooks that could be used to pull out incidents, alerts, schedules, etc., giving a technical path to extract data, but there is no explicit 'export all your data' feature, bulk-export tool, or documented open-format full-account export/offboarding process. missing for 10: a dedicated data-export/backup feature, documentation of export formats (CSV/JSON dumps), and any account-closure/data-portability guarantee.

   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”
   • [claimed-docs] “Download the full OpenAPI 3.0 spec to generate”
   • [claimed-docs] “you will need an API key from your incident.io dashboard to make requests”
   • [probe] “PROBE runtime (recorded 2026-09-06): incident.io publishes machine-readable per-tag OpenAPI 3.0.3 specs keylessly (e.g. https://docs.inciden…”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io.”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io... syncing on-call data like alerts, escalations, and…”

   proof ↗⚑ flag

Follow ups

1. engineering leaderFollow-up actions from incidents are tracked to completion and sync to our issue tracker

   weight 2 · round drawn
   PagerDuty~partialclaimed5/10

   Post-Incident Reviews explicitly state they 'coordinate preventative follow-up actions' and integrate with incident lifecycle data (docs-36, docs-38, docs-23), showing PagerDuty tracks follow-up items generated from postmortems. However, no evidence documents a native or documented sync of these action items into an external issue tracker (Jira, Linear, etc.) or shows tracking-to-completion status/reporting; REST API/webhooks (docs-32, docs-33) could technically enable such integration but this is not demonstrated for follow-up actions specifically. Missing for 10: explicit issue-tracker sync documentation for post-incident follow-up items, evidence of completion-status tracking/reporting on these actions.

   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”

   proof ↗⚑ flag

   incident.io~partialclaimed5/10

   incident.io documents clear follow-up action creation/tracking (docs-7, docs-39, docs-61) and org-wide postmortem completion tracking via list views and policies (docs-5), but explicit native syncing of follow-ups to an issue tracker (e.g., Jira/Linear) is not documented — the closest evidence is a generic webhooks note that mentions 'keeping track of follow-ups' as a possible use case (docs-33/docs-45) plus a general API for building custom integrations (docs-20, docs-34). Missing for 10: a named native issue-tracker integration (Jira/Linear/Asana) for follow-ups, documentation of bidirectional sync/status updates, and any customer proof point of this specific sync working.

   • [claimed-docs] “Track post-mortem completion across your org with list views, the post-incident flow, and policies.”
   • [claimed-docs] “We believe you create two types of actions during an incident – those that need doing now and those that should be followed up after an inci…”
   • [claimed-docs] “follow-ups could be: Improve test coverage of a given codepath, Share the debrief document with all affected customers”
   • [claimed-docs] “follow-ups could be: Improve test coverage of a given codepath”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io. This might be useful for annotating graphs in a moni…”
   • [claimed-docs] “Webhooks can be used to receive notifications when certain events occur in incident.io... syncing on-call data like alerts, escalations, and…”
   • [claimed-docs] “The API is hosted at `https://api.incident.io/`, and you will need an API key from your incident.io dashboard to make requests.”

   proof ↗⚑ flag

Postmortems

1. engineering leaderPostmortems follow a real workflow — templates, drafting from the timeline, review, and publication

   weight 3 · round to incident.io
   PagerDuty~partialclaimed5/10

   PagerDuty's Post-Incident Reviews (formerly Jeli PIR) integrate with the incident lifecycle and Slack data, and the PagerDuty Advance Scribe Agent helps 'build chronological incident narratives' and 'coordinate preventative follow-up actions,' which covers timeline-based drafting and some learning workflow. However, there is no explicit documentation of templates, a distinct review/approval step, or a publication mechanism for postmortems. missing for 10: named postmortem templates, explicit review/approval workflow, publication/sharing step, and independent corroboration of the drafting experience.

   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”
   • [claimed-docs] “PagerDuty Post-Incident Reviews (formerly Jeli Post-Incident Reviews) allow you to turn incidents into learning opportunities.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”

   proof ↗⚑ flag

   incident.io~partialclaimed7/10

   Docs show clear postmortem workflow pieces: timeline customization and narrative capture (docs-4/38/49), AI-assisted first-draft generation with inline review suggestions and redrafting (docs-6), follow-up action tracking (docs-7/39/61), and org-wide completion tracking via post-incident flow and policies (docs-5). However, there's no explicit mention of a postmortem 'template' system or a distinct publication/sign-off step, so the full templates→draft→review→publish pipeline isn't fully evidenced. Missing for 10: explicit template library/selection for postmortems, and a documented publication/approval step beyond 'policies' and 'completion tracking'.

   • [claimed-docs] “Our timeline is completely customizable. We generate a simple timeline based on key events, but you can always add your own narrative or eve…”
   • [claimed-docs] “Track post-mortem completion across your org with list views, the post-incident flow, and policies.”
   • [claimed-docs] “Generate first drafts, get inline review suggestions, and redraft sections with AI.”
   • [claimed-docs] “We believe you create two types of actions during an incident – those that need doing now and those that should be followed up after an inci…”
   • [claimed-docs] “you can always add your own narrative or events that happened in an external system”
   • [claimed-docs] “follow-ups could be: Improve test coverage of a given codepath, Share the debrief document with all affected customers”
   • [claimed-docs] “Our timeline is completely customizable. We generate a simple timeline based on key events, but you can always add your own narrative or eve…”
   • [claimed-docs] “follow-ups could be: Improve test coverage of a given codepath”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   PagerDuty—none0/10

   No evidence in the pack addresses data residency, regional data storage, or the ability to choose where account/data is hosted for PagerDuty. Missing for 10: any mention of regional data centers, EU/US data residency options, or configurable data-storage location.

   ⚑ flag

   incident.io—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic data location controls anywhere in incident.io's docs, changelog, or API references; this is an applicable privacy-posture axis for a SaaS platform handling incident/customer data, but no proof of a data-residency feature exists.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   PagerDuty—none0/10

   No evidence pack item addresses AI training data usage, opt-out controls, or any privacy policy statement about model training on customer data; PagerDuty Advance and MCP references describe AI features, not data-training privacy controls.

   ⚑ flag

   incident.io—none0/10

   No evidence in the pack addresses any data usage, AI training opt-out, or privacy policy commitments regarding customer/incident data being used to train AI models; the docs cover AI features (Investigations, Suggestions, Scribe, MCP) but never mention data-training exclusion or opt-out controls.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   PagerDuty—none0/10

   The evidence pack covers MCP server access, incident workflows, alert grouping, and AI features (PagerDuty Advance), but contains no documentation on data retention policies, deletion controls, or data lifecycle management for AI-native users. Missing for 10: any retention policy documentation, data deletion/export mechanisms, or configurable retention windows relevant to AI-ingested incident data.

   ⚑ flag

   incident.io—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or data lifecycle management for AI-native users; docs cover incidents, on-call, AI investigations, MCP, and API but nothing about retention/deletion settings.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   PagerDuty—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings for PagerDuty or its AI features (MCP server, Advance); this is an applicable privacy-posture axis for an AI-native user but no documentation or community evidence confirms such a control exists. Missing for 10: any privacy policy or settings page describing telemetry collection and an opt-out mechanism.

   ⚑ flag

   incident.io—none0/10

   No evidence pack item addresses telemetry/usage-tracking opt-out settings or a privacy control for AI-native users; the docs cover incident management, on-call, investigations, and MCP but nothing about disabling analytics/tracking.

   ⚑ flag

Status pages

1. engineering leaderRun private or internal status pages with access control for customer-specific or employee-only audiences

   weight 1 · round to incident.io
   PagerDuty—none0/10

   PagerDuty Status Pages are documented as a general capability for real-time operational updates, but no evidence describes private/internal-only pages, audience-specific access control, or separate customer vs employee-only views.

   • [claimed-docs] “PagerDuty Status Pages provide visual, real-time insights into an organization's operations, and the status of incident resolution.”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools, giving user…”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools.”

   proof ↗⚑ flag

   incident.io~partialclaimed6/10

   Docs explicitly confirm both public and private Status Pages exist ('public and private Status Pages') and status-page automation/API features, but no evidence details how access control is scoped (e.g., customer-only vs employee-only audiences, SSO/auth mechanisms) for private pages. missing for 10: explicit documentation of audience-based access control, authentication method for private pages, and independent confirmation of enterprise-grade access segmentation.

   • [claimed-docs] “We've built an easy and delightful way to communicate with customers during an incident with our public and private Status Pages.”
   • [claimed-docs] “We’ve built an easy and delightful way to communicate with customers during an incident with our public and private Status Pages.”
   • [claimed-docs] “Automate status page incidents, maintenance windows, and embed status data in your product.”

   proof ↗⚑ flag

2. engineering leaderPublish a hosted public status page — custom domain, subscriber notifications — driven from incident state

   weight 2 · round to incident.io
   PagerDuty~partialclaimed5/10

   PagerDuty ships a dedicated Status Pages product that is explicitly driven from incident state and lets teams communicate real-time operational updates without leaving PagerDuty (pagerduty-docs-10, pagerduty-docs-17, pagerduty-docs-24). However, the evidence never confirms custom-domain hosting or subscriber notification/opt-in mechanics for the status page. Missing for 10: explicit documentation of custom domain support, subscriber sign-up/notification delivery, and any independent/hands-on confirmation of these specific features.

   • [claimed-docs] “PagerDuty Status Pages provide visual, real-time insights into an organization's operations, and the status of incident resolution.”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools, giving user…”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools.”

   proof ↗⚑ flag

   incident.io~partialclaimed7/10

   Docs confirm hosted public and private Status Pages, workflow-driven auto-publishing from incident state, an agent that can update status pages, and an API to automate status page incidents and maintenance windows. However, the evidence pack contains no explicit mention of custom domain support or subscriber notification features, which are key parts of the story. Missing for 10: explicit documentation of custom domain hosting for status pages, subscriber/email-notification functionality, and independent/hands-on verification of these features.

   • [claimed-docs] “Automate status page incidents, maintenance windows, and embed status data in your product.”
   • [claimed-docs] “With Workflows, you can automatically publish to your status page when an incident is updated.”
   • [claimed-docs] “We've built an easy and delightful way to communicate with customers during an incident with our public and private Status Pages.”
   • [claimed-docs] “We’ve built an easy and delightful way to communicate with customers during an incident with our public and private Status Pages.”
   • [claimed-docs] “You can now update your status page using the agent, add Pingdom”

   proof ↗⚑ flag