PagerDuty vs Rootly

Agent access

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

   weight 2 · round to Rootly
   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

   Rootly✓fullprobed9/10

   Rootly serves a live llms.txt file (HTTP 200) with a structured summary of the product, directly confirming an AI-native agent can be pointed at agent-oriented docs; this complements its documented MCP server for agentic tool use. Missing for 10: no independent/community confirmation that agents successfully consume llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.rootly.com/llms.txt # Rootly > Rootly is an incident management platform that helps engineering te…”
   • [claimed-docs] “This means you can query incidents, check on-call schedules, find similar past incidents, and take action — all from within Cursor, Windsurf…”
   • [probe] “official MCP server documented at https://docs.rootly.com/integrations/mcp-server”

   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

   Rootly~partialprobed6/10

   Rootly's REST API supports creating/managing incidents from CI/CD pipelines and external automation systems (rootly-docs-11, rootly-docs-24), and the API key/token flow enables headless, non-interactive use, including via the MCP server which can run keylessly until gated by an API token (rootly-probe-rt-2). However, there's no dedicated CLI tool, no CI-specific integration guide/examples (e.g., GitHub Actions snippet), and no evidence of a documented headless batch/automation mode beyond API calls. missing for 10: dedicated CLI for CI pipelines, explicit CI/CD integration examples or GitHub Actions templates, and independent confirmation of headless automation use in production CI environments.

   • [claimed-docs] “The Rootly API allows you to create incidents automatically from monitoring tools, CI/CD pipelines, internal services, or any external autom…”
   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Global API Keys are assigned an On-Call and Incident Response role when they’re generated.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official rootly-mcp-server installed keylessly from pypi via uvx and started far enough to log its …”
   • [probe] “PROBE runtime (recorded 2026-09-06): Rootly's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rootly.co…”

   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

   Rootly—none0/10

   All evidence describes Rootly exposing its own MCP server so external AI tools (Cursor, Claude Code, etc.) can consume Rootly's data/actions — this is the reverse direction of the story, which asks whether a user can plug external MCP servers INTO Rootly so its own AI features (e.g. Rootly AI chat, workflows) can use their tools. No evidence shows Rootly acting as an MCP client or supporting external MCP server configuration.

   • [claimed-docs] “This means you can query incidents, check on-call schedules, find similar past incidents, and take action — all from within Cursor, Windsurf…”
   • [claimed-docs] “The Rootly MCP Server implements the Model Context Protocol to expose Rootly incident data and actions as tools that any MCP-compatible clie…”
   • [probe] “official MCP server documented at https://docs.rootly.com/integrations/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): Rootly's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rootly.co…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official rootly-mcp-server installed keylessly from pypi via uvx and started far enough to log its …”

   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

   Rootly✓fullprobed9/10

   Rootly ships an official documented MCP server (docs.rootly.com/integrations/mcp-server) exposing incident data/tools to MCP-compatible clients like Cursor, Windsurf, Claude Code, Gemini CLI, and this is corroborated by a live runtime probe showing the hosted remote MCP endpoint responding with proper OAuth flow and a PyPI-installable server package starting with 124 tools. Missing for 10: independent third-party hands-on review of the MCP server's tool quality beyond vendor docs/probes.

   • [claimed-docs] “This means you can query incidents, check on-call schedules, find similar past incidents, and take action — all from within Cursor, Windsurf…”
   • [claimed-docs] “The Rootly MCP Server implements the Model Context Protocol to expose Rootly incident data and actions as tools that any MCP-compatible clie…”
   • [probe] “official MCP server documented at https://docs.rootly.com/integrations/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): Rootly's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rootly.co…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official rootly-mcp-server installed keylessly from pypi via uvx and started far enough to log its …”

   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

   Rootly—none0/10

   Evidence shows an API, MCP server, and Slack slash-commands, but no official CLI tool is documented anywhere in the pack. missing for 10: any mention of a dedicated Rootly CLI, its install method, or command reference.

   ⚑ 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

   Rootly✓fullprobed8/10

   Rootly documents a public REST API for creating/managing incidents programmatically (rootly-docs-11), an API key generation/auth flow with scoped roles (rootly-docs-24, rootly-docs-49), and a public status-page JSON API (rootly-docs-19), giving AI-native users multiple documented ways to drive the product programmatically; this is reinforced by a documented MCP server exposing incident data/actions as callable tools for AI agents (rootly-docs-44, rootly-probe-3, rootly-probe-rt-1/2). Missing for 10: a discoverable OpenAPI/swagger spec (probe found only 404s at standard OpenAPI paths) and independent third-party corroboration of API robustness beyond vendor docs.

   • [claimed-docs] “The Rootly API allows you to create incidents automatically from monitoring tools, CI/CD pipelines, internal services, or any external autom…”
   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Global API Keys are assigned an On-Call and Incident Response role when they’re generated.”
   • [claimed-docs] “Rootly exposes a public JSON API on your status page's custom domain, allowing you to programmatically retrieve current status and incident …”
   • [claimed-docs] “The Rootly MCP Server implements the Model Context Protocol to expose Rootly incident data and actions as tools that any MCP-compatible clie…”
   • [probe] “official MCP server documented at https://docs.rootly.com/integrations/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): Rootly's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rootly.co…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official rootly-mcp-server installed keylessly from pypi via uvx and started far enough to log its …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rootly.com/openapi.json, https://docs.rootly.com/swagger.json, https://docs.rootly.com/…”

   proof ↗⚑ flag

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

   weight 2 · round to Rootly
   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

   Rootly~partialprobed5/10

   Rootly documents generating API keys (rootly-docs-24) that are assigned a role ('On-Call and Incident Response') at creation (rootly-docs-49), and the official MCP server requires a distinct ROOTLY_API_TOKEN credential for agent access (rootly-probe-rt-2). This shows some notion of scoped credentials for machine/agent use, but there's no evidence of fine-grained least-privilege controls (e.g., read-only vs write, per-resource/team scoping) — indeed the MCP server logs show 135 write-capable tools enabled by default, suggesting broad rather than minimal privilege. Missing for 10: documented ability to restrict API keys to specific resources/teams, read-only or write-limited key types, and independent confirmation that scoping actually limits agent capability in practice.

   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Global API Keys are assigned an On-Call and Incident Response role when they’re generated.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official rootly-mcp-server installed keylessly from pypi via uvx and started far enough to log its …”
   • [claimed-docs] “The Rootly MCP Server implements the Model Context Protocol to expose Rootly incident data and actions as tools that any MCP-compatible clie…”

   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

   Rootly—none0/10

   The evidence shows Rootly offers a REST API with API-key auth (rootly-docs-11, rootly-docs-24, rootly-docs-49) and an MCP server for agentic tool use, but there is no mention anywhere of official client SDKs (e.g., Python/JS/Go libraries) for developers to build against — the OpenAPI spec probe even returned 404s (rootly-probe-2), suggesting no formal SDK generation pipeline is publicly documented.

   • [claimed-docs] “The Rootly API allows you to create incidents automatically from monitoring tools, CI/CD pipelines, internal services, or any external autom…”
   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Global API Keys are assigned an On-Call and Incident Response role when they’re generated.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rootly.com/openapi.json, https://docs.rootly.com/swagger.json, https://docs.rootly.com/…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to PagerDuty
   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

   Rootly—none0/10

   The evidence pack never mentions webhook subscriptions for events (e.g., incident created/updated) that an AI agent could subscribe to; it only covers inbound alert ingestion, workflows, and the MCP server for pull-based querying, not outbound webhook event subscriptions. Missing for 10: any documentation of a webhook subscription/registration mechanism, event payload schema, or signing/verification for outbound webhooks.

   ⚑ flag

Agentic features

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

   weight 2 · round to Rootly
   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

   Rootly✓fullclaimed7/10

   Rootly ships AI Summaries that auto-generate incident retrospectives and summaries from timeline/Slack/transcript data, plus an in-app 'Ask Rootly AI' chat for querying incident data in natural language and MCP-based similar-incident detection (TF-IDF). These are first-party documented AI-insight features embedded directly in the product. Missing for 10: independent/hands-on verification of output quality and no community corroboration of these specific AI features (community comments focus on pricing/workflow, not AI insights).

   • [claimed-docs] “AI Summaries writes it for you, from what the incident already knows: metadata, alerts, timeline events, action items, and (when permitted) …”
   • [claimed-docs] “Rootly AI in Web is an AI chat built into the incident page of the Rootly web app. Open it on any incident and ask questions in natural lang…”
   • [claimed-docs] “**`find_related_incidents`** — uses TF-IDF similarity analysis to surface historically similar incidents”
   • [claimed-docs] “Run `/rootly summary` in the incident channel.”
   • [claimed-docs] “The summary, expanded and delivered privately to responders joining midstream. Only you see it.”

   proof ↗⚑ flag

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

   weight 2 · round to Rootly
   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

   Rootly✓fullclaimed7/10

   Rootly's Workflows are explicitly documented as an 'automation engine' that runs structured actions automatically based on trigger events and run conditions, with 152 available action types spanning Slack, Jira, on-call, AI, and incident ops — enabling background automations like auto-creating channels, notifying stakeholders, filing tickets, and starting retros without manual intervention. missing for 10: independent/hands-on evidence confirming autonomous background execution in practice, and clearer detail on trigger types (e.g., scheduled/webhook triggers) beyond docs summaries.

   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**”
   • [claimed-docs] “Reference for all 152 Rootly workflow action types, grouped by category: Slack, Google Chat, Jira, on-call, AI, and incident operations.”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**... **…”
   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: Trigger events... Run co…”
   • [claimed-docs] “Create or manage an incident communication channel (Slack or Microsoft Teams)”

   proof ↗⚑ flag

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

   weight 3 · round to PagerDuty
   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

   Rootly~partialclaimed5/10

   Rootly ships a built-in AI assistant ('Rootly AI in Web') embedded in the incident page for natural-language Q&A and an automated AI Summaries feature (/rootly summary) that drafts incident data — evidence of a built-in assistant exists. However, the documented 'take action' capability (query incidents, run actions) is explicitly scoped to external MCP-compatible clients (Cursor, Claude Code, etc.), not the in-product assistant itself, so true task delegation within the product's own UI is unproven. Missing for 10: documented examples of the built-in web AI assistant executing actions/workflows (not just answering questions), and independent/hands-on confirmation of task delegation via the in-app assistant.

   • [claimed-docs] “AI Summaries writes it for you, from what the incident already knows: metadata, alerts, timeline events, action items, and (when permitted) …”
   • [claimed-docs] “Rootly AI in Web is an AI chat built into the incident page of the Rootly web app. Open it on any incident and ask questions in natural lang…”
   • [claimed-docs] “Run `/rootly summary` in the incident channel.”
   • [claimed-docs] “Run /rootly summary in the incident channel.”
   • [claimed-docs] “The summary, expanded and delivered privately to responders joining midstream. Only you see it.”
   • [claimed-docs] “This means you can query incidents, check on-call schedules, find similar past incidents, and take action — all from within Cursor, Windsurf…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Rootly✓fullprobed7/10

   Rootly ships an in-app AI chat ('Ask Rootly AI') for natural-language queries on incidents, a Slack slash command (/rootly summary) and, notably, an official MCP server that lets users query incidents, check on-call schedules, and take actions using natural language from AI-native environments like Cursor, Claude Code, and Gemini CLI. Runtime probes confirm the MCP server is live and functioning (401/auth-gated as expected), corroborating the documented capability. missing for 10: independent/hands-on evidence of natural-language command quality/accuracy, broader third-party review of the AI chat or MCP NL experience beyond first-party docs.

   • [claimed-docs] “Rootly AI in Web is an AI chat built into the incident page of the Rootly web app. Open it on any incident and ask questions in natural lang…”
   • [claimed-docs] “This means you can query incidents, check on-call schedules, find similar past incidents, and take action — all from within Cursor, Windsurf…”
   • [claimed-docs] “Run `/rootly summary` in the incident channel.”
   • [claimed-docs] “The Rootly MCP Server implements the Model Context Protocol to expose Rootly incident data and actions as tools that any MCP-compatible clie…”
   • [probe] “official MCP server documented at https://docs.rootly.com/integrations/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): Rootly's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rootly.co…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official rootly-mcp-server installed keylessly from pypi via uvx and started far enough to log its …”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   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

   Rootly—none0/10

   Rootly documents an API reference page and API-key generation (rootly-docs-24, rootly-docs-49) but there's no evidence of an interactive, runnable-example explorer — probes for standard OpenAPI/Swagger specs at docs.rootly.com all returned 404 (rootly-probe-2), and no docs mention a 'try it out' console or embedded runnable code samples.

   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Global API Keys are assigned an On-Call and Incident Response role when they’re generated.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rootly.com/openapi.json, https://docs.rootly.com/swagger.json, https://docs.rootly.com/…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Rootly—none0/10

   Rootly has a documented REST API and API-key system (rootly-docs-24, rootly-docs-49), but an explicit probe for a machine-readable OpenAPI/Swagger spec at all standard paths (openapi.json, swagger.json, etc.) returned 404 on every candidate (rootly-probe-2), and no other evidence pack item shows a downloadable spec file.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rootly.com/openapi.json, https://docs.rootly.com/swagger.json, https://docs.rootly.com/…”
   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Global API Keys are assigned an On-Call and Incident Response role when they’re generated.”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   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

   Rootly—none0/10

   No evidence anywhere in the pack of a sandbox/staging environment, test mode, or data isolation feature for Rootly or its MCP server; in fact the MCP server evidence shows write-enabled tools (135 write paths) operating against live data with no mention of a non-production mode.

   ⚑ 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

   Rootly—none0/10

   There is evidence of an API with key generation (rootly-docs-24, rootly-docs-49) and an incident-creation API (rootly-docs-11), but no documentation of API versioning, version headers, or a deprecation policy anywhere in the pack; probes show no OpenAPI spec discoverable (rootly-probe-2). Missing for 10: any mention of API version numbers, backward-compatibility guarantees, or a published deprecation/sunset policy.

   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Global API Keys are assigned an On-Call and Incident Response role when they’re generated.”
   • [claimed-docs] “The Rootly API allows you to create incidents automatically from monitoring tools, CI/CD pipelines, internal services, or any external autom…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rootly.com/openapi.json, https://docs.rootly.com/swagger.json, https://docs.rootly.com/…”

   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

   Rootly~partialprobed6/10

   Rootly documents a full incident-management API (create incidents, timeline, retrospectives) and a hosted MCP server that lets AI clients query incidents, on-call schedules, and 'take action' with a large set of write-enabled tools (135 write paths per runtime probe), which strongly implies end-to-end incident handling without a dashboard. However, no evidence explicitly names 'acknowledge', 'escalate', or 'resolve' as documented API/MCP actions, leaving the exact scope of automatable lifecycle actions unconfirmed. Missing for 10: explicit doc/example showing ack/escalate/resolve calls via API or MCP tool names, and independent confirmation of successful end-to-end agent-driven resolution.

   • [claimed-docs] “The Rootly API allows you to create incidents automatically from monitoring tools, CI/CD pipelines, internal services, or any external autom…”
   • [claimed-docs] “This means you can query incidents, check on-call schedules, find similar past incidents, and take action — all from within Cursor, Windsurf…”
   • [claimed-docs] “The Rootly MCP Server implements the Model Context Protocol to expose Rootly incident data and actions as tools that any MCP-compatible clie…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official rootly-mcp-server installed keylessly from pypi via uvx and started far enough to log its …”
   • [probe] “official MCP server documented at https://docs.rootly.com/integrations/mcp-server”

   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 drawn
   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

   Rootly~partialclaimed5/10

   Rootly's AI features (AI Summaries, Ask Rootly AI, and the MCP `find_related_incidents` tool using TF-IDF similarity) can surface similar past incidents and draft a Root Cause section from incident data, timeline, and transcripts, giving partial coverage of the 'similar past incidents' and root-cause narrative pieces. However, these are user-triggered (slash command, chat query, or explicit MCP tool call) rather than an autonomous investigator that proactively correlates code/infra changes and live telemetry before a human asks. Missing for 10: evidence of automatic/unprompted change-correlation, telemetry ingestion and analysis, and a proactive (not command-triggered) investigation workflow.

   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “AI Summaries writes it for you, from what the incident already knows: metadata, alerts, timeline events, action items, and (when permitted) …”
   • [claimed-docs] “**`find_related_incidents`** — uses TF-IDF similarity analysis to surface historically similar incidents”
   • [claimed-docs] “Rootly AI in Web is an AI chat built into the incident page of the Rootly web app. Open it on any incident and ask questions in natural lang…”
   • [claimed-docs] “Run `/rootly summary` in the incident channel.”

   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 Rootly
   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

   Rootly✓fullclaimed8/10

   Rootly's retrospectives feature auto-drafts Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline sections directly from incident data, Slack channel, and bridge-call transcripts, with real-time collaborative editing for human review — directly matching the story's ask for AI-drafted postmortems ready for review. missing for 10: explicit mention of 'follow-ups/action items' as a drafted postmortem section (action items are referenced only in AI Summaries, not explicitly tied to the retrospective draft), and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “Rootly lets you define multiple processes and route each incident to the right one based on severity, type, or team, so a SEV0 gets full for…”
   • [claimed-docs] “Real-time collaboration so multiple authors can wo”
   • [claimed-docs] “Rootly includes a rich text editor in retrospectives that supports live incident data and real-time collaboration - all without leaving the …”
   • [claimed-docs] “Incident metadata that resolves to actual values and stays in sync as you write... Real-time collaboration so multiple authors can wo”
   • [claimed-docs] “The incident timeline is the **authoritative record of what happened during an incident**.”
   • [claimed-docs] “AI Summaries writes it for you, from what the incident already knows: metadata, alerts, timeline events, action items, and (when permitted) …”

   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 Rootly
   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

   Rootly✓fullclaimed7/10

   Rootly's AI Summaries feature explicitly drafts live summaries from incident metadata, alerts, timeline, Slack messages and meeting transcripts, triggerable via a slash command mid-incident and delivered privately to responders (rootly-docs-20, -30, -47, -48). Retrospective drafting further auto-generates Summary/Impact/Root Cause/Timeline sections from Slack channel and bridge-call transcripts (rootly-docs-13, -27), covering the 'scribed call notes' and 'drafted updates' parts of the story. Missing for 10: independent/hands-on verification of summary/transcript quality, and no dedicated real-time call-transcription product page distinct from retrospective drafting.

   • [claimed-docs] “AI Summaries writes it for you, from what the incident already knows: metadata, alerts, timeline events, action items, and (when permitted) …”
   • [claimed-docs] “Run `/rootly summary` in the incident channel.”
   • [claimed-docs] “Run /rootly summary in the incident channel.”
   • [claimed-docs] “The summary, expanded and delivered privately to responders joining midstream. Only you see it.”
   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”

   proof ↗⚑ flag

Escalation

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

   weight 3 · round drawn
   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

   Rootly✓fullclaimed8/10

   Rootly's docs explicitly describe escalation policies with multi-step targets, time delays, and round robin to ensure alerts get acknowledged, directly matching the story's requirements for delays, fallback responders, and repeat rounds until acknowledgment (rootly-docs-39, rootly-docs-7). Missing for 10: independent hands-on validation of escalation behavior in practice and more detail on repeat-round/fallback mechanics beyond the doc summary.

   • [claimed-docs] “Configure Rootly escalation policies with multi-step targets, time delays, and round robin to make sure on-call alerts get acknowledged and …”
   • [claimed-docs] “Escalation Policies define **how Rootly notifies responders when an alert requires attention** and what happens if that alert is not acknowl…”
   • [claimed-docs] “Every critical signal reaches the right human, right away, with zero manual coordination.”

   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

   Rootly✓fullclaimed8/10

   Rootly's Alert Deduplication feature explicitly collapses repeat events from the same monitor into a single open alert using a stable identifier so responders aren't paged twice, and Alert Routing provides a unified layer to direct alerts to the right team/escalation policy, combining to reduce duplicate paging. Escalation Policies then ensure one incident routes to the correct on-call human via multi-step targets. Missing for 10: independent/hands-on validation of dedup accuracy at scale and no community evidence specifically confirming the anti-noise outcome in production.

   • [claimed-docs] “Collapse repeat events from the same monitor into a single open Rootly alert using a stable identifier, so responders aren't paged twice.”
   • [claimed-docs] “Alert Deduplication collapses those repeat events onto a single open alert, so the responder sees the count climbing instead of getting page…”
   • [claimed-docs] “Use Alert Routes to determine which teams, services, and escalation policies receive incoming alerts from your monitoring tools based on con…”
   • [claimed-docs] “Rootly provides a unified routing layer that works across all alert sources, enabling consistent on-call workflows.”
   • [claimed-docs] “Escalation Policies define **how Rootly notifies responders when an alert requires attention** and what happens if that alert is not acknowl…”
   • [claimed-docs] “Configure Rootly escalation policies with multi-step targets, time delays, and round robin to make sure on-call alerts get acknowledged and …”

   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

   Rootly~partialclaimed5/10

   Rootly docs confirm push-style alerts via its mobile app and phone-call paging via Live Call Routing, plus escalation policies with multi-step targets and delays, but there is no explicit documentation of SMS or email as notification channels, nor of user-configurable per-channel notification rules (e.g., 'push first, then SMS, then call'). missing for 10: SMS channel support, email channel support, explicit per-channel notification-rule configuration UI/API.

   • [claimed-docs] “Every critical signal reaches the right human, right away, with zero manual coordination.”
   • [claimed-docs] “Turn a phone call into a page. Route inbound calls to the on-call responder, or drop them to voicemail with an automatic alert.”
   • [claimed-docs] “Live Call Routing gives your team a phone number that pages the right person. A caller dials the number, Rootly figures out who's on call, a…”
   • [claimed-docs] “Configure Rootly escalation policies with multi-step targets, time delays, and round robin to make sure on-call alerts get acknowledged and …”
   • [claimed-docs] “Rootly mobile app for iOS and Android on-ca”

   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 to Rootly
   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

   Rootly✓fullclaimed9/10

   Rootly explicitly documents Alert Routes to route incoming monitoring alerts to teams/services/escalation policies 'based on conditions you define' (rootly-docs-10), backed by a unified routing layer across alert sources (rootly-docs-37), deduplication to avoid double-paging (rootly-docs-9, rootly-docs-36), and escalation policies with multi-step targets/time delays/round robin (rootly-docs-7, rootly-docs-39). Migration docs (PagerDuty/Opsgenie) confirm ingestion from common monitoring/alerting tool ecosystems. Missing for 10: independent hands-on validation of the routing-conditions engine itself (community evidence covers general sentiment, not this specific feature).

   • [claimed-docs] “Use Alert Routes to determine which teams, services, and escalation policies receive incoming alerts from your monitoring tools based on con…”
   • [claimed-docs] “Rootly provides a unified routing layer that works across all alert sources, enabling consistent on-call workflows.”
   • [claimed-docs] “Collapse repeat events from the same monitor into a single open Rootly alert using a stable identifier, so responders aren't paged twice.”
   • [claimed-docs] “Alert Deduplication collapses those repeat events onto a single open alert, so the responder sees the count climbing instead of getting page…”
   • [claimed-docs] “Escalation Policies define **how Rootly notifies responders when an alert requires attention** and what happens if that alert is not acknowl…”
   • [claimed-docs] “Configure Rootly escalation policies with multi-step targets, time delays, and round robin to make sure on-call alerts get acknowledged and …”
   • [claimed-docs] “Migrating from Opsgenie”
   • [claimed-docs] “Migrating from PagerDuty”

   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 PagerDuty
   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

   Rootly—none0/10

   The evidence pack covers incident response, on-call scheduling, retrospectives, workflows, and AI summaries, but contains no mention of MTTA/MTTR trend dashboards, incident-load analytics, or on-call health reporting features that an engineering leader could use to track improvement over time. This is a fair ask for an incident management platform, but no documentation, screenshots, or community evidence support it.

   ⚑ 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

   Rootly—none0/10

   Rootly's docs describe workflows, an API, and an MCP server for automating individual incident/alert actions, but nothing describes bulk operations (e.g., batch-updating or resolving many incidents/alerts/schedules in one call). Workflow triggers and API creation are per-incident/event, not a documented multi-item batch operation feature.

   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**”
   • [claimed-docs] “Reference for all 152 Rootly workflow action types, grouped by category: Slack, Google Chat, Jira, on-call, AI, and incident operations.”
   • [claimed-docs] “The Rootly API allows you to create incidents automatically from monitoring tools, CI/CD pipelines, internal services, or any external autom…”
   • [claimed-docs] “The Rootly MCP Server implements the Model Context Protocol to expose Rootly incident data and actions as tools that any MCP-compatible clie…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Rootly✓fullclaimed8/10

   Rootly's Workflows engine is explicitly documented as its automation engine, running structured actions automatically based on trigger events, run conditions, and actions, with 152 distinct workflow action types across Slack, Jira, on-call, AI, and incident operations. This directly satisfies rule-based automatic triggering on events, reinforced by alert routing rules and escalation policies that also apply condition-based automated behavior. Missing for 10: independent/hands-on verification of workflow rule configuration in practice and more detail on conditional logic complexity beyond docs summaries.

   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**”
   • [claimed-docs] “Reference for all 152 Rootly workflow action types, grouped by category: Slack, Google Chat, Jira, on-call, AI, and incident operations.”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**... **…”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: Trigger events... Run co…”
   • [claimed-docs] “Use Alert Routes to determine which teams, services, and escalation policies receive incoming alerts from your monitoring tools based on con…”
   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”

   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

   Rootly—none0/10

   Rootly's Workflows are described as an automation engine triggered by incident-related events and conditions (docs-16, docs-29, docs-41), but there is no evidence of a scheduling/cron-style trigger or recurring-job capability for workflows — 'schedules' in the docs refer only to on-call rotation schedules (docs-6, docs-26), not automation scheduling. Missing for 10: any documented scheduled/cron trigger type in the workflow trigger-events list, recurring workflow execution examples, or API/UI support for time-based recurring automation.

   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**... **…”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: Trigger events... Run co…”
   • [claimed-docs] “These schedules determine **who is on-call at any given time** and control the **rotation** of on-call duties across users or teams.”
   • [claimed-docs] “Create, manage, and maintain on-call schedules in Rootly with rotations, layers, overrides, restrictions, and previews to keep coverage clea…”

   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

   Rootly—none0/10

   Rootly's workflow automation engine is documented in detail (triggers, conditions, 152 action types) but nothing in the evidence pack describes version history, diff/review workflows, or rollback capability for automations. Missing for 10: any mention of workflow versioning, change review/approval process, or rollback/revert mechanism for automations.

   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**”
   • [claimed-docs] “Reference for all 152 Rootly workflow action types, grouped by category: Slack, Google Chat, Jira, on-call, AI, and incident operations.”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**... **…”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: Trigger events... Run co…”

   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

   Rootly~partialclaimed6/10

   Rootly's 'Workflows' engine is described as an automation system that runs structured actions automatically based on trigger events, run conditions, and actions — including creating incident channels, filing tickets, and updating stakeholders (rootly-docs-16, rootly-docs-17, rootly-docs-29, rootly-docs-34, rootly-docs-45). This closely maps to runbook-style automation attached to incidents, but the evidence never uses the term 'runbook' as a distinct attachable object, and doesn't explicitly show task assignment or diagnostic-running steps as workflow actions. Missing for 10: explicit runbook/incident attachment terminology, evidence of task-assignment actions, evidence of diagnostic-running actions, and independent/hands-on corroboration of workflow automation actually firing.

   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**”
   • [claimed-docs] “Reference for all 152 Rootly workflow action types, grouped by category: Slack, Google Chat, Jira, on-call, AI, and incident operations.”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**... **…”
   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”
   • [claimed-docs] “Create or manage an incident communication channel (Slack or Microsoft Teams)”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: Trigger events... Run co…”

   proof ↗⚑ flag

Workflows

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

   weight 2 · round to Rootly
   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

   Rootly✓fullclaimed8/10

   Rootly's Workflows engine is explicitly documented as a condition-based automation system with trigger events, run conditions, and actions (rootly-docs-16/29/41), used to update fields, send reminders, create channels, update stakeholders, file tickets, and start retros automatically on incident events (rootly-docs-34, rootly-docs-45). A 152-action reference (rootly-docs-17) shows breadth across Slack, Jira, on-call, and incident-ops actions, directly matching the 'updates, reminders, field changes' toil-automation story. Missing for 10: independent hands-on validation of the workflow engine specifically (community evidence only discusses general product value, not workflow conditions in depth) and no detailed walkthrough of condition-branching logic beyond docs.

   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**”
   • [claimed-docs] “Reference for all 152 Rootly workflow action types, grouped by category: Slack, Google Chat, Jira, on-call, AI, and incident operations.”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**... **…”
   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: Trigger events... Run co…”
   • [claimed-docs] “Create or manage an incident communication channel (Slack or Microsoft Teams)”

   proof ↗⚑ flag

Communications

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

   weight 1 · round to Rootly
   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

   Rootly✓fullclaimed7/10

   Rootly's private status pages are explicitly designed to give internal stakeholders structured incident health updates without needing to join the incident channel/war room, backed by automation that 'updates stakeholders' as part of workflows, plus AI summaries that can be pushed to Slack/Teams for those following along. missing for 10: explicit documentation of a stakeholder subscription/notification mechanism (e.g., email/RSS subscribe button) and independent confirmation that non-responders actually use status pages this way.

   • [claimed-docs] “Status pages allow you to quickly communicate information about the health of your services and applications to internal stakeholders and ex…”
   • [claimed-docs] “Rootly has two types of status pages available: public status pages and private status pages.”
   • [claimed-docs] “It only takes about a minute to set up a status page, so set one up soon after you've signed up.”
   • [claimed-docs] “Rootly exposes a public JSON API on your status page's custom domain, allowing you to programmatically retrieve current status and incident …”
   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”
   • [claimed-docs] “AI Summaries writes it for you, from what the incident already knows: metadata, alerts, timeline events, action items, and (when permitted) …”
   • [claimed-docs] “Run /rootly summary in the incident channel.”
   • [claimed-docs] “The summary, expanded and delivered privately to responders joining midstream. Only you see it.”

   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

   Rootly—none0/10

   The evidence pack covers incident timelines, workflows, escalation policies, and automated actions like channel creation and stakeholder updates, but nowhere explicitly describes assigning defined incident roles (e.g., commander, comms lead) or maintaining task checklists during an incident. missing for 10: explicit role assignment (commander/comms lead) documentation, task checklist feature, evidence of role-based coordination during response.

   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”
   • [claimed-docs] “Rootly lets you define multiple processes and route each incident to the right one based on severity, type, or team, so a SEV0 gets full for…”
   • [claimed-docs] “Workflows are Rootly's automation engine. They let you run structured actions automatically (or manually) based on: **Trigger events**”

   proof ↗⚑ 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 Rootly
   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

   Rootly✓fullclaimed8/10

   Docs explicitly describe declaring/running/resolving incidents from Slack, Google Chat, or Teams, with automated channel creation, escalation-policy/role assignment, and stakeholder updates (rootly-docs-1, rootly-docs-34, rootly-docs-45, rootly-docs-7, rootly-docs-39). No community evidence concretely contradicts the chat-declare workflow itself (general skepticism in rootly-comm-7 is about PD parity, not a functional failure). Missing for 10: independent hands-on confirmation of the actual Slack/Teams declare flow and any real-world walkthrough beyond vendor docs.

   • [claimed-docs] “Declare, run, and resolve an incident from Slack, Google Chat, and Microsoft Teams.”
   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”
   • [claimed-docs] “Create or manage an incident communication channel (Slack or Microsoft Teams)”
   • [claimed-docs] “Escalation Policies define **how Rootly notifies responders when an alert requires attention** and what happens if that alert is not acknowl…”
   • [claimed-docs] “Configure Rootly escalation policies with multi-step targets, time delays, and round robin to make sure on-call alerts get acknowledged and …”
   • [claimed-docs] “These schedules determine **who is on-call at any given time** and control the **rotation** of on-call duties across users or teams.”

   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 Rootly
   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

   Rootly✓fullclaimed8/10

   Docs explicitly describe the incident timeline as the 'authoritative record of what happened during an incident,' auto-populated from alerts, actions, Slack, and bridge-call data, and retrospectives support real-time collaborative editing/annotation via a rich text editor with live incident data. This covers automatic capture (alerts/actions/chat) plus post-hoc editing/annotation as described in the story. Missing for 10: independent/hands-on verification of timeline auto-capture accuracy and explicit UI evidence of inline timeline editing (only retrospective editing is directly documented).

   • [claimed-docs] “The incident timeline is the **authoritative record of what happened during an incident**.”
   • [claimed-docs] “The incident timeline is the authoritative record of what happened during an incident.”
   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “Rootly includes a rich text editor in retrospectives that supports live incident data and real-time collaboration - all without leaving the …”
   • [claimed-docs] “Real-time collaboration so multiple authors can wo”
   • [claimed-docs] “Incident metadata that resolves to actual values and stays in sync as you write... Real-time collaboration so multiple authors can wo”

   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

   Rootly—none0/10

   The evidence pack describes generic alert routing, deduplication, and a 'unified routing layer that works across all alert sources' but never names or documents specific setup for Datadog, Grafana, Prometheus, CloudWatch, or Sentry integrations. Without concrete first-party docs pointing to these specific observability tools, the story's requirement for named, documented integrations is unmet.

   • [claimed-docs] “Collapse repeat events from the same monitor into a single open Rootly alert using a stable identifier, so responders aren't paged twice.”
   • [claimed-docs] “Use Alert Routes to determine which teams, services, and escalation policies receive incoming alerts from your monitoring tools based on con…”
   • [claimed-docs] “Rootly provides a unified routing layer that works across all alert sources, enabling consistent on-call workflows.”

   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 Rootly
   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

   Rootly~partialclaimed6/10

   Docs show strong two-way integration with Slack, Microsoft Teams, and Google Chat (declare/resolve incidents from chat, create incident channels, /rootly summary commands) and a workflow action reference explicitly grouped by categories including Jira, alongside bidirectional automation (tickets filed, channels created, stakeholders updated). However, GitHub is never named as an integration, and Zoom is only implied via generic 'bridge-call transcripts'/'meeting transcripts' rather than a documented explicit Zoom integration. Missing for 10: explicit GitHub integration/state-sync evidence, explicit named Zoom integration (beyond generic call/meeting transcript mentions), and independent/hands-on confirmation that Jira ticket state actually syncs bidirectionally.

   • [claimed-docs] “Declare, run, and resolve an incident from Slack, Google Chat, and Microsoft Teams.”
   • [claimed-docs] “Reference for all 152 Rootly workflow action types, grouped by category: Slack, Google Chat, Jira, on-call, AI, and incident operations.”
   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”
   • [claimed-docs] “Create or manage an incident communication channel (Slack or Microsoft Teams)”
   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “Run `/rootly summary` in the incident channel.”

   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

   Rootly~partialclaimed3/10

   Docs confirm a native iOS/Android mobile app exists for on-call use (rootly-docs-43), but there is no detail confirming that acknowledge, escalate, and resolve actions are all available from the app, nor any hands-on/community validation of the mobile experience. missing for 10: documented list of mobile app actions (ack/escalate/resolve), UI/UX detail, independent user reviews of the app's reliability at odd hours.

   • [claimed-docs] “Rootly mobile app for iOS and Android on-ca”

   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

   Rootly—none0/10

   The evidence pack covers Rootly's on-call schedules, rotations, escalation policies, and even a mobile app, but nowhere mentions a calendar feed (iCal/ICS export) for syncing on-call shifts to a personal calendar. This is a standard capability for on-call scheduling tools and its absence here means no evidence supports it.

   • [claimed-docs] “These schedules determine **who is on-call at any given time** and control the **rotation** of on-call duties across users or teams.”
   • [claimed-docs] “Create, manage, and maintain on-call schedules in Rootly with rotations, layers, overrides, restrictions, and previews to keep coverage clea…”
   • [claimed-docs] “Rootly mobile app for iOS and Android on-ca”

   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 Rootly
   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

   Rootly✓fullclaimed8/10

   Rootly docs explicitly describe schedules with rotations and layers, plus multi-step escalation policies with round-robin support, directly matching the story's requirements, and migration docs confirm bringing existing schedules from PagerDuty/Opsgenie without rebuild. Time zone support is implied by 'previews to keep coverage clear' but not explicitly named, and there's no independent/hands-on validation beyond vendor docs. Missing for 10: explicit documentation of time-zone handling in schedule configuration, and independent/community verification of rotation/layer behavior in practice.

   • [claimed-docs] “These schedules determine **who is on-call at any given time** and control the **rotation** of on-call duties across users or teams.”
   • [claimed-docs] “Create, manage, and maintain on-call schedules in Rootly with rotations, layers, overrides, restrictions, and previews to keep coverage clea…”
   • [claimed-docs] “Configure Rootly escalation policies with multi-step targets, time delays, and round robin to make sure on-call alerts get acknowledged and …”
   • [claimed-docs] “Bring your schedules, escalation policies, and more without a rebuild.”
   • [claimed-docs] “Migrate from another tool Bring your schedules, escalation policies, and more without a rebuild.”

   proof ↗⚑ flag

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

   weight 2 · round to Rootly
   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

   Rootly~partialclaimed5/10

   Docs confirm schedules support overrides directly (rotations, layers, overrides, restrictions, previews) without needing a rebuild, which addresses the 'take an override' part of the story. However, there is no evidence of self-service shift-swap or coverage-request workflows for individual on-call engineers. missing for 10: explicit shift-swap capability, coverage-request workflow, and confirmation that engineers (not admins) can perform these actions directly.

   • [claimed-docs] “Create, manage, and maintain on-call schedules in Rootly with rotations, layers, overrides, restrictions, and previews to keep coverage clea…”
   • [claimed-docs] “These schedules determine **who is on-call at any given time** and control the **rotation** of on-call duties across users or teams.”
   • [claimed-docs] “Bring your schedules, escalation policies, and more without a rebuild.”

   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

   Rootly~partialprobed6/10

   Rootly documents a REST API for creating/managing incidents, API keys with scoped roles, a status-page public API, and an MCP server exposing 124 tools including 135 write paths for incidents, on-call, and alerts — indicating broad but not explicitly confirmed full parity with the UI. No official OpenAPI spec was discoverable (404s across candidate paths), and there's no explicit vendor claim that 100% of UI functionality (e.g., retrospectives editing, workflow builder, status page configuration) is API-accessible. Missing for 10: a published complete OpenAPI/API reference, explicit UI-API parity statement, and independent confirmation of full functional coverage beyond incidents/on-call/alerts.

   • [claimed-docs] “The Rootly API allows you to create incidents automatically from monitoring tools, CI/CD pipelines, internal services, or any external autom…”
   • [claimed-docs] “Rootly exposes a public JSON API on your status page's custom domain, allowing you to programmatically retrieve current status and incident …”
   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Global API Keys are assigned an On-Call and Incident Response role when they’re generated.”
   • [claimed-docs] “The Rootly MCP Server implements the Model Context Protocol to expose Rootly incident data and actions as tools that any MCP-compatible clie…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rootly.com/openapi.json, https://docs.rootly.com/swagger.json, https://docs.rootly.com/…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official rootly-mcp-server installed keylessly from pypi via uvx and started far enough to log its …”

   proof ↗⚑ flag

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

   weight 3 · round to PagerDuty
   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

   Rootly—none0/10

   Rootly's docs describe an API for creating/reading incident data and migration guides for importing from Opsgenie/PagerDuty, but there is no documented bulk data-export feature, open-format export of schedules/incidents/retrospectives, or account-portability/'leave the platform' capability. The API (rootly-docs-11, rootly-docs-24) hints at programmatic access but is not evidenced as a full data-export mechanism.

   • [claimed-docs] “The Rootly API allows you to create incidents automatically from monitoring tools, CI/CD pipelines, internal services, or any external autom…”
   • [claimed-docs] “To generate a new API key, navigate to: **Organization dropdown** > **Organization Settings** > **API Keys > Generate New API Key**.”
   • [claimed-docs] “Migrating from Opsgenie”
   • [claimed-docs] “Migrating from PagerDuty”
   • [claimed-docs] “Rootly exposes a public JSON API on your status page's custom domain, allowing you to programmatically retrieve current status and incident …”

   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

   Rootly~partialclaimed5/10

   Rootly's workflow automation supports Jira actions and can 'file tickets' as part of incident response automation, and AI summaries reference 'action items' captured during incidents, implying some link to follow-up tracking and ticket sync. However, there is no explicit documentation of a dedicated action-item/follow-up tracking system with completion status or two-way sync guarantees to an issue tracker. Missing for 10: a dedicated action-items/follow-up-tracking feature description, explicit two-way sync/status update with Jira or other trackers, and any evidence (docs or community) that follow-ups are tracked to completion rather than just ticket creation.

   • [claimed-docs] “Reference for all 152 Rootly workflow action types, grouped by category: Slack, Google Chat, Jira, on-call, AI, and incident operations.”
   • [claimed-docs] “Automation that runs your response: channels created, stakeholders updated, tickets filed, retros started, the same way every time.”
   • [claimed-docs] “AI Summaries writes it for you, from what the incident already knows: metadata, alerts, timeline events, action items, and (when permitted) …”

   proof ↗⚑ flag

Postmortems

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

   weight 3 · round to Rootly
   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

   Rootly✓fullclaimed8/10

   Rootly's retrospectives docs show a real workflow: multiple selectable process templates routed by severity/type/team (rootly-docs-14), auto-drafted sections (Summary, Impact, Root Cause, Mitigation, Resolution, Curated Timeline) generated from the authoritative incident timeline/Slack/transcripts (rootly-docs-12, rootly-docs-13, rootly-docs-27, rootly-docs-40), collaborative real-time editing for review by multiple authors (rootly-docs-15, rootly-docs-28, rootly-docs-42), and publication via status pages/communication channels (rootly-docs-18, rootly-docs-38, rootly-docs-45). This covers templates → draft-from-timeline → review → publish end-to-end. Missing for 10: independent/hands-on confirmation of the postmortem workflow specifically (community evidence is about on-call/pricing, not retrospectives) and explicit detail on an approval/sign-off publication step.

   • [claimed-docs] “The incident timeline is the **authoritative record of what happened during an incident**.”
   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “Rootly lets you define multiple processes and route each incident to the right one based on severity, type, or team, so a SEV0 gets full for…”
   • [claimed-docs] “Real-time collaboration so multiple authors can wo”
   • [claimed-docs] “sections like Summary, Impact, Root Cause, Mitigation, Resolution, and Curated Timeline get drafted automatically from the incident's data, …”
   • [claimed-docs] “Rootly includes a rich text editor in retrospectives that supports live incident data and real-time collaboration - all without leaving the …”
   • [claimed-docs] “Incident metadata that resolves to actual values and stays in sync as you write... Real-time collaboration so multiple authors can wo”
   • [claimed-docs] “Status pages allow you to quickly communicate information about the health of your services and applications to internal stakeholders and ex…”
   • [claimed-docs] “Create or manage an incident communication channel (Slack or Microsoft Teams)”

   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

   Rootly—none0/10

   No evidence in the pack addresses data residency, regional storage options, or compliance/data-location controls for Rootly. The docs cover incidents, on-call, workflows, retrospectives, and MCP integrations but never mention region selection or data residency guarantees. missing for 10: any mention of data residency/region selection, compliance certifications (e.g., SOC2/GDPR data localization), or configurable storage location.

   ⚑ 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

   Rootly—none0/10

   No evidence in the pack addresses AI training data usage, opt-out controls, or any privacy policy statement about model training; Rootly's docs focus on incident management, on-call, and AI features (summaries, MCP) but never mention data-training exclusion or opt-out mechanisms. missing for 10: any privacy policy or documentation stating customer data is excluded from AI model training, opt-out settings, or data processing agreements addressing this concern.

   ⚑ 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

   Rootly—none0/10

   No evidence pack items discuss data retention policies, data deletion controls, or export/purge mechanisms for AI-native users; the docs cover incident management, on-call, workflows, MCP server, and AI summaries but nothing about controlling retention or deletion of data. Missing for 10: any documentation of retention settings, deletion/purge APIs, data export controls, or privacy configuration options.

   ⚑ 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

   Rootly—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings, privacy controls, or data collection disclosures for Rootly; the docs focus entirely on incident management, on-call, and AI features. Missing for 10: any privacy policy or settings documentation on telemetry collection, any opt-out mechanism, or usage-tracking disclosure.

   ⚑ 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 Rootly
   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

   Rootly~partialclaimed6/10

   Docs explicitly state Rootly offers both public and private status pages, and describe status pages as communicating health info to both internal stakeholders and external customers, directly matching the story's core ask. However, there's no detail on granular access-control mechanisms (e.g., password protection, audience segmentation between customer-specific vs employee-only groups, SSO-gated access), so the depth of access control is unclear. missing for 10: documentation of specific access-control mechanisms (password/SSO gating, audience segmentation rules), independent/hands-on confirmation of private page functionality.

   • [claimed-docs] “Rootly has two types of status pages available: public status pages and private status pages.”
   • [claimed-docs] “Status pages allow you to quickly communicate information about the health of your services and applications to internal stakeholders and ex…”
   • [claimed-docs] “It only takes about a minute to set up a status page, so set one up soon after you've signed up.”
   • [claimed-docs] “Rootly exposes a public JSON API on your status page's custom domain, allowing you to programmatically retrieve current status and incident …”

   proof ↗⚑ flag

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

   weight 2 · round to Rootly
   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

   Rootly~partialclaimed6/10

   Docs confirm hosted public status pages with custom domains (public JSON API served on the custom domain) and quick setup, distinguishing public vs private status pages for external customers. However, there is no explicit documentation of subscriber notification features (email/SMS/webhook subscriptions) or an explicit description of how incident state automatically drives status page updates beyond general platform integration. missing for 10: subscriber notification mechanics, explicit incident-to-status-page state sync documentation, independent/hands-on confirmation of custom domain setup.

   • [claimed-docs] “It only takes about a minute to set up a status page, so set one up soon after you've signed up.”
   • [claimed-docs] “Rootly exposes a public JSON API on your status page's custom domain, allowing you to programmatically retrieve current status and incident …”
   • [claimed-docs] “Status pages allow you to quickly communicate information about the health of your services and applications to internal stakeholders and ex…”
   • [claimed-docs] “Rootly has two types of status pages available: public status pages and private status pages.”

   proof ↗⚑ flag