PagerDuty vs FireHydrant

Agent access

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

   weight 2 · round drawn
   PagerDuty✓fullprobed8/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullprobed8/10

   A probe confirms FireHydrant hosts a live llms.txt at docs.firehydrant.com/llms.txt returning HTTP 200 with structured documentation content, directly satisfying the ability to point an agent at agent-oriented docs. This is corroborated by an official MCP server that also exposes tool schemas for agent consumption. Missing for 10: no independent third-party report of an agent actually consuming llms.txt successfully, and no explicit docs page describing llms.txt as an intentional agent-facing feature.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.firehydrant.com/llms.txt # FireHydrant Documentation Documentation > FireHydrant is a complete ale…”
   • [probe] “official MCP server documented at https://github.com/firehydrant/firehydrant-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): FireHydrant's official MCP server (npm firehydrant-mcp 0.0.4, maintained by fh-eng) completed a FULL ke…”

   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

   FireHydrant~partialprobed5/10

   FireHydrant exposes a full REST API with token-based auth for configuring integrations, incidents, and webhooks, plus an official MCP server that supports headless/CI-style automation. However, this is an incident-management platform, not a CI-runnable tool itself — there's no evidence of a CLI, Docker image, or documented CI pipeline usage pattern. Missing for 10: dedicated CLI for automation, explicit CI/CD pipeline examples or integrations (e.g., GitHub Actions), and independent confirmation of headless API/MCP use in production automation workflows.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”
   • [claimed-docs] “FireHydrant allows you to access the API with an API key using token-based authentication.”
   • [claimed-docs] “An API key can perform actions like any other user, and by default, it will have Owner permissions.”
   • [claimed-docs] “Official FireHydrant MCP server”
   • [probe] “PROBE runtime (recorded 2026-09-06): FireHydrant's official MCP server (npm firehydrant-mcp 0.0.4, maintained by fh-eng) completed a FULL ke…”

   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

   FireHydrant—none0/10

   Evidence shows FireHydrant ships an official MCP server so external AI agents can call FireHydrant's tools (docs-49, probe-3, probe-rt-1), but this is the reverse (server) role — there is no evidence FireHydrant itself can plug in third-party MCP servers to consume their tools within its own AI features (Copilot, AI summaries, retrospectives). Missing for 10: any documentation of FireHydrant acting as an MCP client, configuration for adding external MCP servers, or AI features that invoke external MCP tools.

   • [claimed-docs] “Official FireHydrant MCP server”
   • [probe] “official MCP server documented at https://github.com/firehydrant/firehydrant-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): FireHydrant's official MCP server (npm firehydrant-mcp 0.0.4, maintained by fh-eng) completed a FULL ke…”

   proof ↗⚑ flag

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

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

   FireHydrant✓fullprobed8/10

   FireHydrant maintains an official MCP server (firehydrant/firehydrant-mcp) confirmed via docs reference and a runtime probe showing a successful stdio initialize handshake advertising tools/prompts capabilities. Missing for 10: independent third-party adoption reports or richer documentation of tool coverage beyond the handshake confirmation.

   • [claimed-docs] “Official FireHydrant MCP server”
   • [probe] “official MCP server documented at https://github.com/firehydrant/firehydrant-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): FireHydrant's official MCP server (npm firehydrant-mcp 0.0.4, maintained by fh-eng) completed a FULL ke…”

   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

   FireHydrant—none0/10

   No evidence pack item references an official FireHydrant CLI tool; only an API (docs-18/21/48), an MCP server (docs-49, probe-3), and web/Slack integrations are documented. The axis is plausible for a platform like this, but absence of any CLI documentation means it is not evidenced.

   ⚑ 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

   FireHydrant✓fullprobed8/10

   FireHydrant documents a full public REST API with token-based key auth ('anything you can do on the FireHydrant UI'), and API key management docs describe permission scoping, plus an official MCP server exists and was verified to run a full handshake, further supporting programmatic/agentic access. missing for 10: a publicly discoverable OpenAPI/swagger spec (all probed paths 404'd) and independent third-party corroboration of API robustness.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”
   • [claimed-docs] “Copy the API key and record it somewhere safe, as it grants access to the FireHydrant API on behalf of your organization.”
   • [claimed-docs] “An API key can perform actions like any other user, and by default, it will have Owner permissions.”
   • [claimed-docs] “FireHydrant allows you to access the API with an API key using token-based authentication.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.firehydrant.com/openapi.json, https://docs.firehydrant.com/swagger.json, https://docs.f…”
   • [probe] “official MCP server documented at https://github.com/firehydrant/firehydrant-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): FireHydrant's official MCP server (npm firehydrant-mcp 0.0.4, maintained by fh-eng) completed a FULL ke…”

   proof ↗⚑ flag

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

   weight 2 · round to PagerDuty
   PagerDuty~partialprobed4/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

   FireHydrant's docs describe API keys but explicitly state they grant Owner permissions by default with no mention of scoped or least-privilege roles for API keys or agent credentials (firehydrant-docs-33, firehydrant-docs-18, firehydrant-docs-48). No evidence of a mechanism to issue restricted-scope tokens specifically for AI agents.

   • [claimed-docs] “An API key can perform actions like any other user, and by default, it will have Owner permissions.”
   • [claimed-docs] “Copy the API key and record it somewhere safe, as it grants access to the FireHydrant API on behalf of your organization.”
   • [claimed-docs] “FireHydrant allows you to access the API with an API key using token-based authentication.”

   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

   FireHydrant—none0/10

   Evidence shows a general REST API (docs-21, docs-48, docs-18, docs-33) and an official MCP server (docs-49), but there is no mention of official client SDKs (e.g., Python, JS, Go libraries) for developers to build against, and probes for an OpenAPI spec (firehydrant-probe-2) all returned 404s, suggesting no generated SDK tooling. Missing for 10: any documented official SDK/library in a specific language, package registry listings, or SDK usage examples.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”
   • [claimed-docs] “FireHydrant allows you to access the API with an API key using token-based authentication.”
   • [claimed-docs] “An API key can perform actions like any other user, and by default, it will have Owner permissions.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.firehydrant.com/openapi.json, https://docs.firehydrant.com/swagger.json, https://docs.f…”

   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

   FireHydrant~partialclaimed3/10

   The only evidence is a single line noting the FireHydrant API can be used to "set up webhooks--anything you can do on the FireHydrant UI," implying webhook subscription is possible, but there's no dedicated documentation on webhook event types, payload structure, or subscription management shown in the pack. Missing for 10: dedicated webhooks documentation, list of subscribable event types, payload schema, and any hands-on/independent confirmation that webhook subscriptions work as described.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”

   proof ↗⚑ flag

Agentic features

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

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

   FireHydrant✓fullclaimed8/10

   FireHydrant ships multiple AI-generated insight features inside the product: AI-generated incident summaries created automatically on declaration, AI-drafted retrospectives that produce timelines/impacts/lessons-learned, and a Copilot that proactively compares ongoing incidents to past ones and suggests actions in Command Center/Slack. Missing for 10: independent/hands-on validation of output quality and no detail on the underlying model or accuracy benchmarks.

   • [claimed-docs] “Dive into incidents with AI-generated summaries that provide a clear, concise overview of the situation. Perfect for bringing new responders…”
   • [claimed-docs] “When you click "Draft with AI" next to any question in your retrospective template, FireHydrant will: Analyze the incident's t”
   • [claimed-docs] “FireHydrant's Copilot proactively compares ongoing incidents to your existing and previous incidents and makes suggestions in the Command Ce…”
   • [claimed-docs] “AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, timelines, impacts, and prelim…”
   • [claimed-docs] “Upon incident resolution, AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, time…”
   • [claimed-docs] “Summaries are created as soon as an incident is declared, providing key information right from the start.”

   proof ↗⚑ flag

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

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

   FireHydrant~partialclaimed6/10

   FireHydrant's Runbooks are explicitly described as an automation engine that runs workflows of steps/actions automatically based on conditions (e.g., default runbook auto-attaches to every incident, auto-assigns roles, auto-creates Slack channels/Jira tickets), and Signals/Alert Rules auto-route events into alerts and incidents without human intervention — this is genuine autonomous background automation. However, these are reactive/triggered automations tied to incident events rather than fully agentic, self-initiating background processes, and there's no evidence of scheduled/proactive AI-driven automation beyond incident-triggered workflows. Missing for 10: evidence of autonomous scheduling or proactive (non-incident-triggered) automation, independent/hands-on confirmation that Runbooks run reliably unattended, and detail on how failures/edge-cases in autonomous execution are handled.

   • [claimed-docs] “Runbooks are FireHydrant's automation engine. They define and automate a workflow of steps and actions according to specified conditions.”
   • [claimed-docs] “When you first sign up for an account, FireHydrant builds a Default Runbook for you that always attaches to every incident.”
   • [claimed-docs] “The default Runbook will always have two default steps: * **Assign a Role**: Assigns whoever opened the incident to the Commander role.”
   • [claimed-docs] “The default Runbook will always have two default steps: Assign a Role... Add Task List”
   • [claimed-docs] “when a Rule matches, the Event is turned into an Alert and routed to the relevant party via Escalation Policies and On-Call Schedules”
   • [claimed-docs] “Teams configure Alert Triggers (see next section) to describe which events should alert and whom, and when a Rule matches, the Event is turn…”
   • [claimed-docs] “Automate manual tasks such as creating incident Slack channels, Jira tickets, meeting bridges, and more”
   • [claimed-docs] “Integrate with alerting and monitoring integrations to automatically create incidents from alerts”

   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

   FireHydrant~partialclaimed5/10

   FireHydrant ships several AI-powered features—AI incident summaries, AI-drafted retrospectives ('Draft with AI'), and a 'Copilot' that proactively suggests related incidents in Command Center/Slack—which act as an embedded AI assistant for specific incident-management tasks. However, these are narrow, feature-specific AI actions (summarization, drafting, suggestions) rather than a general-purpose assistant to which a user can freely delegate open-ended tasks. Missing for 10: evidence of a conversational/chat-based assistant interface, ability to delegate arbitrary multi-step tasks beyond the predefined AI features, and independent user reports confirming assistant reliability.

   • [claimed-docs] “Dive into incidents with AI-generated summaries that provide a clear, concise overview of the situation. Perfect for bringing new responders…”
   • [claimed-docs] “When you click "Draft with AI" next to any question in your retrospective template, FireHydrant will: Analyze the incident's t”
   • [claimed-docs] “FireHydrant's Copilot proactively compares ongoing incidents to your existing and previous incidents and makes suggestions in the Command Ce…”
   • [claimed-docs] “AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, timelines, impacts, and prelim…”
   • [claimed-docs] “Summaries are created as soon as an incident is declared, providing key information right from the start.”

   proof ↗⚑ flag

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

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

   FireHydrant~partialprobed6/10

   FireHydrant ships an official MCP server (confirmed via live handshake exposing tools and prompts) that would let AI agents issue natural-language-driven commands against the platform, and Slack integration (/fh) offers some command-style interaction, but there's no evidence of a native in-app NL/chat interface for direct human natural-language operation—AI features documented are mostly summarization/drafting rather than command execution. Missing for 10: documented list of MCP tool commands, evidence of a native conversational command interface within the FireHydrant UI itself, and independent hands-on confirmation of NL command execution.

   • [claimed-docs] “Official FireHydrant MCP server”
   • [probe] “PROBE runtime (recorded 2026-09-06): FireHydrant's official MCP server (npm firehydrant-mcp 0.0.4, maintained by fh-eng) completed a FULL ke…”
   • [claimed-docs] “From Slack, inside an incident channel, you can browse the list of triggered Runbooks for this by executing `/fh`.”
   • [claimed-docs] “FireHydrant's Copilot proactively compares ongoing incidents to your existing and previous incidents and makes suggestions in the Command Ce…”

   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

   FireHydrant—none0/10

   FireHydrant documents a REST API and API keys but there's no evidence of an interactive API reference with runnable examples; a probe explicitly found no OpenAPI/Swagger spec exposed (all candidate paths 404), suggesting no interactive API explorer exists.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”
   • [claimed-docs] “Copy the API key and record it somewhere safe, as it grants access to the FireHydrant API on behalf of your organization.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.firehydrant.com/openapi.json, https://docs.firehydrant.com/swagger.json, https://docs.f…”

   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

   FireHydrant—none0/10

   FireHydrant has an API reference (docs-21, docs-48) but explicit probes for standard OpenAPI spec locations (openapi.json, swagger.json, etc.) all returned 404, and no evidence of a downloadable machine-readable spec anywhere else in the pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.firehydrant.com/openapi.json, https://docs.firehydrant.com/swagger.json, https://docs.f…”
   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”

   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

   FireHydrant—none0/10

   FireHydrant is an incident-management platform; no evidence describes a sandbox/staging environment, test mode, or data isolation feature for testing workflows without touching production data. The MCP server evidence covers agent connectivity, not sandbox testing. Missing for 10: any mention of a sandbox/test environment, non-production API mode, or data segregation guarantees.

   ⚑ 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

   FireHydrant—none0/10

   There is a documented REST API (docs-18, docs-21, docs-48) and even a probe attempt for an OpenAPI spec, but that probe returned 404s for all candidate OpenAPI/versioning endpoints, and no evidence anywhere mentions API versioning scheme or a deprecation policy. Missing for 10: any documentation of API version numbers, a changelog, or a stated deprecation/EOL policy for the API.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”
   • [claimed-docs] “Copy the API key and record it somewhere safe, as it grants access to the FireHydrant API on behalf of your organization.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.firehydrant.com/openapi.json, https://docs.firehydrant.com/swagger.json, https://docs.f…”

   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

   FireHydrant~partialprobed6/10

   FireHydrant ships a documented REST API described as able to do 'anything you can do on the FireHydrant UI' (docs-21, docs-48) and has a confirmed official MCP server that completes a full keyless handshake and advertises tools/prompts capabilities (docs-49, probe-3, probe-rt-1), enabling agent-driven incident workflows without a dashboard. However, the evidence never enumerates the specific MCP tool set (e.g., explicit 'acknowledge alert', 'escalate', 'resolve incident' endpoints/tools), so full end-to-end coverage of acknowledge→escalate→resolve purely via API/MCP is inferred rather than directly documented. Missing for 10: explicit MCP tool list showing acknowledge/escalate/resolve actions, and a hands-on example of an agent completing a full incident lifecycle via API/MCP.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”
   • [claimed-docs] “FireHydrant allows you to access the API with an API key using token-based authentication.”
   • [claimed-docs] “Official FireHydrant MCP server”
   • [probe] “official MCP server documented at https://github.com/firehydrant/firehydrant-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): FireHydrant's official MCP server (npm firehydrant-mcp 0.0.4, maintained by fh-eng) completed a FULL ke…”
   • [claimed-docs] “Escalation policies define how notifications from an Alert are sent to various team members, either as part of an on-call schedule or as an …”
   • [claimed-docs] “when a Rule matches, the Event is turned into an Alert and routed to the relevant party via Escalation Policies and On-Call Schedules”

   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

   FireHydrant~partialclaimed5/10

   FireHydrant's AI Copilot proactively compares ongoing incidents to similar past incidents and surfaces suggestions in Command Center/Slack (firehydrant-docs-30), and AI-generated summaries appear as soon as an incident is declared (firehydrant-docs-52), giving some 'before a human asks' correlation. However, there's no documented evidence of correlating code/config changes or live telemetry data as part of this investigative process — it's limited to incident-text similarity and summarization, not a full root-cause 'investigator' pulling from deploys/metrics. Missing for 10: evidence of correlating infrastructure/code changes, telemetry/metrics ingestion into the AI analysis, and an autonomous 'investigation' output beyond summaries and incident-similarity suggestions.

   • [claimed-docs] “FireHydrant's Copilot proactively compares ongoing incidents to your existing and previous incidents and makes suggestions in the Command Ce…”
   • [claimed-docs] “Summaries are created as soon as an incident is declared, providing key information right from the start.”
   • [claimed-docs] “Dive into incidents with AI-generated summaries that provide a clear, concise overview of the situation. Perfect for bringing new responders…”
   • [claimed-docs] “AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, timelines, impacts, and prelim…”

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

   FireHydrant✓fullclaimed8/10

   FireHydrant's AI-Drafted Retrospectives feature explicitly generates a comprehensive draft from the incident record including timelines, impacts, contributing-factor-style analysis, and preliminary Lessons Learned, triggered via a 'Draft with AI' button per retrospective question, clearly positioned for human review/editing. This directly matches the story's ask for AI-drafted postmortems with timeline/contributing factors/follow-ups ready for human review. Missing for 10: no independent/hands-on verification of output quality or explicit mention of 'follow-ups' as a distinct drafted section (only 'Lessons Learned' and impacts are named).

   • [claimed-docs] “When you click "Draft with AI" next to any question in your retrospective template, FireHydrant will: Analyze the incident's t”
   • [claimed-docs] “AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, timelines, impacts, and prelim…”
   • [claimed-docs] “Upon incident resolution, AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, time…”
   • [claimed-docs] “Create and manage multiple templates to standardize your post-incident review process across different types of incidents or teams.”

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

   FireHydrant~partialclaimed6/10

   FireHydrant offers AI-generated incident summaries at declaration, AI-drafted retrospectives, and Zoom chat capture during calls, which cover live summaries and scribed call notes; however 'drafted updates' (e.g., AI-written status page/stakeholder updates during the incident) are not evidenced, and coverage is Slack/Zoom-centric with no mention of other call platforms or fully autonomous update drafting during the incident lifecycle. missing for 10: evidence of AI-drafted live status/stakeholder updates during an active incident, support for scribing calls outside Zoom, and independent/hands-on validation of accuracy of these AI features.

   • [claimed-docs] “Dive into incidents with AI-generated summaries that provide a clear, concise overview of the situation. Perfect for bringing new responders…”
   • [claimed-docs] “Available to everyone in your Slack workspace, they don’t need a FireHydrant account.”
   • [claimed-docs] “Never miss a beat, even if you join late. Our AI captures essential Zoom chat insights, ensuring you're always in the loop.”
   • [claimed-docs] “FireHydrant's Copilot proactively compares ongoing incidents to your existing and previous incidents and makes suggestions in the Command Ce…”
   • [claimed-docs] “AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, timelines, impacts, and prelim…”
   • [claimed-docs] “Summaries are created as soon as an incident is declared, providing key information right from the start.”

   proof ↗⚑ flag

Escalation

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

   weight 3 · round to PagerDuty
   PagerDuty✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed5/10

   FireHydrant's Signals product explicitly ships escalation policies that route alert notifications to on-call team members or individuals, with direct user/Slack notification options (docs-4, docs-34, docs-40). However, the evidence never details the specific mechanics of multi-step delays, fallback responders, or repeated escalation rounds until acknowledgment that the story asks about. missing for 10: explicit documentation of configurable delay timers between escalation steps, fallback/backup responder chains, and repeat-round behavior on non-acknowledgment.

   • [claimed-docs] “Escalation policies define how notifications from an Alert are sent to various team members, either as part of an on-call schedule or as an …”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”
   • [claimed-docs] “FireHydrant also allows directly notifying specific users and Slack channels.”
   • [claimed-docs] “Schedules: These are a collection of rotations that is associated to a team.”

   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

   FireHydrant—none0/10

   The evidence describes Alert Rules turning events into Alerts and routing them via Escalation Policies/Schedules, and an Alerting Analytics page showing how many alerts turn into incidents, but nothing describes deduplication or grouping of duplicate/related alerts into a single incident so only one person is paged. Missing for 10: explicit alert deduplication/grouping logic, evidence of noise reduction, and any documentation of merging correlated alerts into one incident.

   • [claimed-docs] “when a Rule matches, the Event is turned into an Alert and routed to the relevant party via Escalation Policies and On-Call Schedules”
   • [claimed-docs] “Use our new Alerting Analytics page to understand how incoming events are turning into Alerts, how many alerts are being acknowledged, and h…”
   • [claimed-docs] “Teams configure Alert Triggers (see next section) to describe which events should alert and whom, and when a Rule matches, the Event is turn…”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”

   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

   FireHydrant~partialclaimed3/10

   FireHydrant's Signals docs mention a 'complete alerting solution' with 'multi-platform notifications' and direct notification of 'specific users and Slack channels,' implying some multi-channel delivery, but no evidence enumerates push, SMS, phone call, or email specifically, nor describes per-channel notification rule configuration. missing for 10: explicit documentation of SMS/phone/email/push channel options, per-channel rule configuration UI, and any hands-on confirmation of channel delivery.

   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”
   • [claimed-docs] “FireHydrant also allows directly notifying specific users and Slack channels.”
   • [claimed-docs] “Escalation policies define how notifications from an Alert are sent to various team members, either as part of an on-call schedule or as an …”

   proof ↗⚑ flag

Routing

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

   weight 3 · round drawn
   PagerDuty✓fullprobed8/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullclaimed8/10

   FireHydrant's Signals feature documents ingesting alerts from any monitoring tool via Alert Rules (with CEL-based conditions/backtesting), routing to teams through Escalation Policies and On-Call Schedules, with multi-platform notifications and a migrator from PagerDuty/Opsgenie confirming this is a documented, mature ingestion+routing pipeline. Missing for 10: independent/hands-on validation of routing accuracy at scale and broader detail on the full catalog of supported monitoring source integrations beyond generic claims.

   • [claimed-docs] “when a Rule matches, the Event is turned into an Alert and routed to the relevant party via Escalation Policies and On-Call Schedules”
   • [claimed-docs] “Teams configure Alert Triggers (see next section) to describe which events should alert and whom, and when a Rule matches, the Event is turn…”
   • [claimed-docs] “Escalation policies define how notifications from an Alert are sent to various team members, either as part of an on-call schedule or as an …”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”
   • [claimed-docs] “you can quickly run a backtest of events by running a CEL query in the page's filter builder”
   • [claimed-docs] “On the Alert Rules page, you can quickly run a backtest of events by running a CEL query in the page's filter builder.”
   • [claimed-docs] “FireHydrant also allows directly notifying specific users and Slack channels.”
   • [claimed-docs] “New Signals Migrator: Migrate your PagerDuty or Opsgenie config in minutes”
   • [claimed-docs] “Integrate with alerting and monitoring integrations to automatically create incidents from alerts”

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

   FireHydrant✓fullclaimed7/10

   FireHydrant's Analytics page explicitly provides MTTx (MTTA/MTTR) metrics with grouping/filtering by team, service, severity, etc., letting leaders see overall health and trends, and a separate Alerting Analytics page tracks alert-to-incident conversion and acknowledgment rates relevant to on-call health. Missing for 10: independent/hands-on validation of the analytics UI, and no explicit dedicated 'on-call health' dashboard beyond alerting analytics and schedules.

   • [claimed-docs] “FireHydrant's analytics offer the ability to filter and group by various aspects... Service, Environment, Functionality, Team, Severity, Use…”
   • [claimed-docs] “FireHydrant's analytics offer the ability to filter and group by various aspects: ... Service, Environment, Functionality, Team, Severity, U…”
   • [claimed-docs] “FireHydrant's analytics offer the ability to filter and group by various aspects”
   • [claimed-docs] “This Analytics page groups and visualizes these metrics so you can understand overall health by entities like teams, impacted services, and …”
   • [claimed-docs] “Use our new Alerting Analytics page to understand how incoming events are turning into Alerts, how many alerts are being acknowledged, and h…”

   proof ↗⚑ flag

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

   weight 2 · round to PagerDuty
   PagerDuty~partialprobed5/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

   FireHydrant's evidence describes a general REST API and MCP server but nowhere documents batch/bulk endpoints or bulk-update workflows (e.g., bulk-close incidents, bulk-edit alerts/schedules) that an AI agent could invoke across many items at once. Absence of any bulk-operation feature or API pattern means this applicable automation-depth axis is unmet.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”
   • [claimed-docs] “FireHydrant allows you to access the API with an API key using token-based authentication.”
   • [claimed-docs] “Official FireHydrant MCP server”

   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

   FireHydrant✓fullclaimed8/10

   FireHydrant's Signals Alert Rules use CEL queries to match events and automatically route them into Alerts via Escalation Policies/On-Call Schedules, with a backtest tool to validate rule matches, and Runbooks serve as a full automation engine that triggers workflow steps based on specified conditions. This directly satisfies rule-based, event-triggered automation across both alerting and incident workflows. missing for 10: independent/hands-on validation of rule complexity or edge cases, and clearer detail on conditional branching logic within Runbooks beyond default templates

   • [claimed-docs] “when a Rule matches, the Event is turned into an Alert and routed to the relevant party via Escalation Policies and On-Call Schedules”
   • [claimed-docs] “Teams configure Alert Triggers (see next section) to describe which events should alert and whom, and when a Rule matches, the Event is turn…”
   • [claimed-docs] “you can quickly run a backtest of events by running a CEL query in the page's filter builder”
   • [claimed-docs] “On the Alert Rules page, you can quickly run a backtest of events by running a CEL query in the page's filter builder.”
   • [claimed-docs] “Runbooks are FireHydrant's automation engine. They define and automate a workflow of steps and actions according to specified conditions.”
   • [claimed-docs] “Integrate with alerting and monitoring integrations to automatically create incidents from alerts”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”

   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

   FireHydrant—none0/10

   FireHydrant's 'Schedules' feature (docs-3, 25, 39) is for on-call rotation staffing, not recurring automated job/workflow execution, and Runbooks (docs-43) are event/condition-triggered automation rather than time-based recurring jobs. No evidence shows a cron-like or interval-based scheduler for workflows.

   ⚑ 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

   FireHydrant—none0/10

   FireHydrant's Runbooks are its automation engine, and audit logs track 'Runbook modifications' for audit purposes, but there is no documented capability to version, review-approve changes, or roll back a Runbook/automation to a prior state. missing for 10: version history UI for Runbooks, diff/review workflow before automation changes go live, and an explicit rollback/restore mechanism.

   • [claimed-docs] “From Runbook modifications to incident declarations, logins, and more, you can find a full history and detailed trail of events for security…”
   • [claimed-docs] “Runbooks are FireHydrant's automation engine. They define and automate a workflow of steps and actions according to specified conditions.”
   • [claimed-docs] “Audit logs give organizations transparency and visibility into the events happening on the FireHydrant platform.”

   proof ↗⚑ flag

Runbooks

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

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

   FireHydrant✓fullclaimed8/10

   Docs describe Runbooks as FireHydrant's automation engine that attach to incidents (default Runbook auto-attaches to every incident) and execute steps like assigning roles, creating Slack channels/Jira tickets, task lists, and running diagnostics-type actions, with triggers via Slack (/fh) and API. This directly matches the SRE story of runbooks attaching to incidents and auto-triggering steps. Missing for 10: independent/hands-on verification of runbook execution reliability and broader diagnostic-step examples beyond docs.

   • [claimed-docs] “Runbooks are FireHydrant's automation engine. They define and automate a workflow of steps and actions according to specified conditions.”
   • [claimed-docs] “When you first sign up for an account, FireHydrant builds a Default Runbook for you that always attaches to every incident.”
   • [claimed-docs] “The default Runbook will always have two default steps: * **Assign a Role**: Assigns whoever opened the incident to the Commander role.”
   • [claimed-docs] “The default Runbook will always have two default steps: Assign a Role... Add Task List”
   • [claimed-docs] “Automate manual tasks such as creating incident Slack channels, Jira tickets, meeting bridges, and more”
   • [claimed-docs] “From Slack, inside an incident channel, you can browse the list of triggered Runbooks for this by executing `/fh`.”
   • [claimed-docs] “Standardize processes and tailor them for different situations, product areas, and teams, among other criteria”

   proof ↗⚑ flag

Workflows

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

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

   FireHydrant✓fullclaimed7/10

   FireHydrant's Runbooks are explicitly documented as a condition-based automation engine that defines workflows of steps/actions triggered by incident events (role assignment, task lists, Slack/Jira automation, reminders), with default runbooks auto-attached to every incident and manual/automatic triggering options. Alert Rules similarly use conditional matching (CEL queries) to route events into incidents/escalations, reinforcing the condition-based automation theme. missing for 10: independent/hands-on validation of runbook conditional logic in production use, and detail on field-update/reminder step types beyond role assignment and task lists.

   • [claimed-docs] “Runbooks are FireHydrant's automation engine. They define and automate a workflow of steps and actions according to specified conditions.”
   • [claimed-docs] “The default Runbook will always have two default steps: * **Assign a Role**: Assigns whoever opened the incident to the Commander role.”
   • [claimed-docs] “The default Runbook will always have two default steps: Assign a Role... Add Task List”
   • [claimed-docs] “When you first sign up for an account, FireHydrant builds a Default Runbook for you that always attaches to every incident.”
   • [claimed-docs] “From Slack, inside an incident channel, you can browse the list of triggered Runbooks for this by executing `/fh`.”
   • [claimed-docs] “when a Rule matches, the Event is turned into an Alert and routed to the relevant party via Escalation Policies and On-Call Schedules”
   • [claimed-docs] “Teams configure Alert Triggers (see next section) to describe which events should alert and whom, and when a Rule matches, the Event is turn…”
   • [claimed-docs] “Automate manual tasks such as creating incident Slack channels, Jira tickets, meeting bridges, and more”

   proof ↗⚑ flag

Communications

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

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

   FireHydrant~partialclaimed7/10

   FireHydrant's internal status pages give stakeholders a no-login, no-license view of structured incident summaries without joining the incident channel/war room, and external status pages extend this further, which directly serves the 'update stakeholders without joining' need. However, the evidence never describes a subscribe/notify mechanism (e.g., email/SMS alerts on status changes) for stakeholders, only that pages exist to view. Missing for 10: explicit subscription/notification feature for internal status page updates, and independent/hands-on validation of stakeholder usage.

   • [claimed-docs] “For public (to your organization) incidents, these internal status pages do not require auth or a FireHydrant license to view.”
   • [claimed-docs] “The FireHydrant platform offers both internal status pages... as well as external status pages (Atlassian and FireHydrant-hosted).”
   • [claimed-docs] “each incident on FireHydrant will have a dedicated ephemeral status page that summarizes high-level details and includes key links”
   • [claimed-docs] “each incident on FireHydrant will have a dedicated ephemeral status page that summarizes high-level details and includes key links.”
   • [claimed-docs] “The FireHydrant platform offers both internal status pages, which are meant for the internal team only and require no setup, as well as exte…”

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

   FireHydrant✓fullclaimed9/10

   FireHydrant's default Runbook explicitly assigns a Commander role and attaches a task list on incident creation, with Runbooks acting as a customizable automation/checklist engine tied to teams and product areas, and Signals/escalation policies route comms to the right responders. Missing for 10: no explicit documented 'comms lead' named role (only Commander is default-named) and no independent/hands-on case study confirming role-based coordination in live incidents.

   • [claimed-docs] “The default Runbook will always have two default steps: * **Assign a Role**: Assigns whoever opened the incident to the Commander role.”
   • [claimed-docs] “The default Runbook will always have two default steps: Assign a Role... Add Task List”
   • [claimed-docs] “When you first sign up for an account, FireHydrant builds a Default Runbook for you that always attaches to every incident.”
   • [claimed-docs] “Runbooks are FireHydrant's automation engine. They define and automate a workflow of steps and actions according to specified conditions.”
   • [claimed-docs] “Standardize processes and tailor them for different situations, product areas, and teams, among other criteria”
   • [claimed-docs] “From Slack, inside an incident channel, you can browse the list of triggered Runbooks for this by executing `/fh`.”

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

   FireHydrant~partialclaimed6/10

   Docs show strong Slack-native incident declaration: automatic incident Slack channels (docs-2), default Runbook assigning Commander role (docs-7, docs-28, docs-41), Slack slash-command control (docs-8), and AI-generated incident summaries posted to Slack usable by anyone in the workspace (docs-11, docs-12, docs-44, docs-52). However, all evidence is Slack-specific; there is no mention of Microsoft Teams support for declaring incidents, creating channels, or assigning roles, and 'multi-platform notifications' (docs-34) refers to alerting, not chat-based incident declaration. Missing for 10: explicit Teams incident-declaration support, Teams channel/role automation, and any hands-on/independent confirmation of the chat-first workflow.

   • [claimed-docs] “Automate manual tasks such as creating incident Slack channels, Jira tickets, meeting bridges, and more”
   • [claimed-docs] “The default Runbook will always have two default steps: * **Assign a Role**: Assigns whoever opened the incident to the Commander role.”
   • [claimed-docs] “From Slack, inside an incident channel, you can browse the list of triggered Runbooks for this by executing `/fh`.”
   • [claimed-docs] “Dive into incidents with AI-generated summaries that provide a clear, concise overview of the situation. Perfect for bringing new responders…”
   • [claimed-docs] “Available to everyone in your Slack workspace, they don’t need a FireHydrant account.”
   • [claimed-docs] “When you first sign up for an account, FireHydrant builds a Default Runbook for you that always attaches to every incident.”
   • [claimed-docs] “The default Runbook will always have two default steps: Assign a Role... Add Task List”
   • [claimed-docs] “Universal Access: Available to everyone in your Slack workspace, they don't need a FireHydrant account.”
   • [claimed-docs] “Summaries are created as soon as an incident is declared, providing key information right from the start.”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”

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

   FireHydrant~partialclaimed6/10

   FireHydrant automatically creates incidents from alerts, runs Runbooks/automation, and captures Zoom/Slack chat insights via AI (docs-24, docs-29, docs-30, docs-43), and AI-drafted retrospectives generate timelines and summaries (docs-35, docs-45) which implies some automatic timeline construction. However, there is no explicit documentation of a unified, editable incident timeline UI where SREs can annotate or edit captured events after the fact — the evidence shows summary/retrospective generation and audit logs (docs-19, docs-54) but not a dedicated timeline edit/annotate feature. Missing for 10: explicit documentation of a dedicated incident timeline view, evidence of manual editing/annotation of auto-captured timeline entries, and independent/hands-on confirmation that alerts+actions+chat are merged into one editable record.

   • [claimed-docs] “Integrate with alerting and monitoring integrations to automatically create incidents from alerts”
   • [claimed-docs] “Never miss a beat, even if you join late. Our AI captures essential Zoom chat insights, ensuring you're always in the loop.”
   • [claimed-docs] “FireHydrant's Copilot proactively compares ongoing incidents to your existing and previous incidents and makes suggestions in the Command Ce…”
   • [claimed-docs] “AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, timelines, impacts, and prelim…”
   • [claimed-docs] “Upon incident resolution, AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, time…”
   • [claimed-docs] “From Runbook modifications to incident declarations, logins, and more, you can find a full history and detailed trail of events for security…”
   • [claimed-docs] “Audit logs give organizations transparency and visibility into the events happening on the FireHydrant platform.”

   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

   FireHydrant—none0/10

   Evidence only shows generic claims like alerting from 'any monitoring tool' or 'alerting and monitoring integrations' without naming Datadog, Grafana, Prometheus, CloudWatch, or Sentry, and no documented setup guides for any of these specific tools appear in the pack. Missing for 10: named integration pages/setup docs for Datadog, Grafana, Prometheus, CloudWatch, and Sentry.

   • [claimed-docs] “Alert and page your responders about events coming from any monitoring tool”
   • [claimed-docs] “Integrate with alerting and monitoring integrations to automatically create incidents from alerts”

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

   FireHydrant~partialclaimed7/10

   Docs show strong two-way integration evidence for Slack (incident channels, /fh runbook commands, AI summaries usable without FH account), Jira (auto-created tickets), and Zoom (chat insights, meeting bridges), plus a general API/webhook layer for building custom integrations. However, GitHub and Microsoft Teams are never explicitly named as integrations — only generic 'multi-platform notifications' is mentioned — so state-flow for those specific tools is unevidenced. Missing for 10: explicit GitHub integration details, explicit Teams integration details, and independent/hands-on confirmation of bidirectional sync beyond FireHydrant's own docs.

   • [claimed-docs] “Automate manual tasks such as creating incident Slack channels, Jira tickets, meeting bridges, and more”
   • [claimed-docs] “From Slack, inside an incident channel, you can browse the list of triggered Runbooks for this by executing `/fh`.”
   • [claimed-docs] “Available to everyone in your Slack workspace, they don’t need a FireHydrant account.”
   • [claimed-docs] “Never miss a beat, even if you join late. Our AI captures essential Zoom chat insights, ensuring you're always in the loop.”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”
   • [claimed-docs] “FireHydrant also allows directly notifying specific users and Slack channels.”
   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”

   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

   FireHydrant—none0/10

   The evidence pack covers on-call schedules, escalation policies, Slack/API integrations, and AI summaries, but contains no mention of a native mobile app for acknowledging, escalating, or resolving incidents. Mobile app support is a fair axis for an incident-management/on-call platform, but no evidence confirms FireHydrant ships one.

   ⚑ 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

   FireHydrant—none0/10

   The evidence pack documents FireHydrant's Signals on-call schedules, rotations, and escalation policies, but nowhere mentions an iCal/calendar feed or personal calendar subscription for on-call shifts. Since on-call calendar sync is a standard, plausible capability for an on-call scheduling product, its absence in the evidence means the axis applies but is unsupported.

   • [claimed-docs] “Creating a schedule To create an On-Call Schedule for a team”
   • [claimed-docs] “Schedules: These are a collection of rotations that is associated to a team.”
   • [claimed-docs] “Create schedules with rotation to manage your team's on-call”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”

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

   FireHydrant~partialclaimed6/10

   FireHydrant's Signals product documents on-call Schedules built from Rotations tied to teams, plus Escalation Policies for notifying via schedules or individuals, and multi-platform notifications — the core building blocks an SRE needs. However, the evidence never explicitly mentions layered/multi-tier rotations, time zone handling, or round-robin coverage patterns by name, so it's unclear whether these specific nuanced scheduling patterns are supported as described. Missing for 10: explicit documentation of scheduling layers, time zone-aware rotations, and round-robin distribution logic, plus independent/hands-on confirmation of these specifics.

   • [claimed-docs] “Schedules: These are a collection of rotations that is associated to a team.”
   • [claimed-docs] “Create schedules with rotation to manage your team's on-call”
   • [claimed-docs] “Creating a schedule To create an On-Call Schedule for a team”
   • [claimed-docs] “Escalation policies define how notifications from an Alert are sent to various team members, either as part of an on-call schedule or as an …”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”
   • [claimed-docs] “FireHydrant also allows directly notifying specific users and Slack channels.”

   proof ↗⚑ flag

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

   weight 2 · round to PagerDuty
   PagerDuty~partialcommunity3/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

   FireHydrant's Signals product documents creating schedules, rotations, and escalation policies (docs-3, docs-25, docs-39, docs-34), but no evidence describes an on-call engineer independently taking an override, swapping a shift, or requesting coverage without admin involvement.

   • [claimed-docs] “Creating a schedule To create an On-Call Schedule for a team”
   • [claimed-docs] “Schedules: These are a collection of rotations that is associated to a team.”
   • [claimed-docs] “Create schedules with rotation to manage your team's on-call”
   • [claimed-docs] “Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team …”

   proof ↗⚑ flag

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

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

   FireHydrant✓fullprobed7/10

   FireHydrant's own API docs explicitly state 'you can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI,' directly claiming full UI/API parity, and API keys default to Owner permissions enabling full account-level actions (docs-21, docs-33, docs-48). Missing for 10: independent/hands-on verification of parity, a discoverable public OpenAPI/swagger spec (probe found only 404s), and confirmation that newer UI features (e.g., AI retrospectives, analytics dashboards) are all exposed via API.

   • [claimed-docs] “You can use the FireHydrant API to configure integrations, define incidents, and set up webhooks--anything you can do on the FireHydrant UI.”
   • [claimed-docs] “An API key can perform actions like any other user, and by default, it will have Owner permissions.”
   • [claimed-docs] “FireHydrant allows you to access the API with an API key using token-based authentication.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.firehydrant.com/openapi.json, https://docs.firehydrant.com/swagger.json, https://docs.f…”

   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

   FireHydrant—none0/10

   There is no evidence of a bulk data export feature or open-format export/portability tool for FireHydrant; the API (docs-18,21,48) allows programmatic access but no documented full-data export/leave capability is described.

   ⚑ 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

   FireHydrant~partialclaimed5/10

   FireHydrant's Runbooks can automate creating Jira tickets and include an 'Add Task List' step, implying some ability to generate and sync follow-up items to an issue tracker, but the evidence never describes a dedicated action-item/follow-up tracking feature with completion status or reporting back from Jira. Missing for 10: explicit follow-up/action-item tracking UI, completion status sync from Jira back to FireHydrant, and any analytics on follow-up closure rates.

   • [claimed-docs] “Automate manual tasks such as creating incident Slack channels, Jira tickets, meeting bridges, and more”
   • [claimed-docs] “The default Runbook will always have two default steps: Assign a Role... Add Task List”
   • [claimed-docs] “Runbooks are FireHydrant's automation engine. They define and automate a workflow of steps and actions according to specified conditions.”
   • [claimed-docs] “Create and manage multiple templates to standardize your post-incident review process across different types of incidents or teams.”

   proof ↗⚑ flag

Postmortems

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

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

   FireHydrant~partialclaimed7/10

   FireHydrant's docs show a real postmortem workflow: standardized templates for post-incident reviews (firehydrant-docs-9), AI-drafted retrospectives generated from the incident's timeline (firehydrant-docs-13, firehydrant-docs-35, firehydrant-docs-45), and live collaborative review (multiple viewers, cursors) on retrospective documents (firehydrant-docs-10). However, there is no explicit documentation of a distinct 'publication' step (e.g., sharing/exporting the finished retrospective externally or to stakeholders) beyond internal collaboration. Missing for 10: explicit publish/export/sharing step for finished retrospectives, and independent/hands-on corroboration of the end-to-end workflow.

   • [claimed-docs] “Create and manage multiple templates to standardize your post-incident review process across different types of incidents or teams.”
   • [claimed-docs] “Enterprise customers have access to the collaboration features in FireHydrant's Retrospectives, which include seeing who's on the document l…”
   • [claimed-docs] “When you click "Draft with AI" next to any question in your retrospective template, FireHydrant will: Analyze the incident's t”
   • [claimed-docs] “AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, timelines, impacts, and prelim…”
   • [claimed-docs] “Upon incident resolution, AI-Drafted Retrospectives generate a comprehensive draft that includes a structured overview of the incident, time…”

   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

   FireHydrant—none0/10

   No evidence pack items mention data residency, regional storage options, or geographic data controls for FireHydrant; this is an applicable axis for a SaaS incident-management platform but no documentation addresses it.

   ⚑ flag

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

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

   FireHydrant~partialclaimed3/10

   FireHydrant's AI security practices docs mention tenant-level control over which AI features are enabled, implying some data-governance control, but there is no explicit statement that customer data is excluded from model training. Missing for 10: an explicit no-training-on-customer-data policy, opt-out mechanism specific to model training, and independent verification of this claim.

   • [claimed-docs] “You will additionally have control over whether AI is available in your tenant, and for which features.”

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

   FireHydrant—none0/10

   The evidence pack has one line about controlling whether AI is available per tenant/feature (firehydrant-docs-14), but nothing about data retention policies, deletion of incident data, AI-generated content, or logs. No documentation of retention periods, deletion controls, or data lifecycle management is present, so this AI-native privacy-posture story is unsupported.

   ⚑ 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

   FireHydrant—none0/10

   No evidence pack item discusses telemetry, usage tracking, or opt-out controls for FireHydrant itself (docs focus on AI feature toggles, SSO, audit logs, etc.). This is a fair question for a SaaS incident management platform, so absence of evidence yields 'none'. Missing for 10: any documentation of telemetry/usage-data collection practices, an opt-out mechanism, or privacy settings addressing tracking.

   ⚑ flag

Status pages

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

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

   FireHydrant—none0/10

   FireHydrant offers internal status pages (org-only) and external status pages, but its own docs state internal status pages 'do not require auth or a FireHydrant license to view' — indicating no granular access control layer for customer-specific vs employee-only audiences. There is no evidence of role-based or audience-segmented private status pages beyond the binary internal/external split.

   • [claimed-docs] “For public (to your organization) incidents, these internal status pages do not require auth or a FireHydrant license to view.”
   • [claimed-docs] “The FireHydrant platform offers both internal status pages, which are meant for the internal team only and require no setup, as well as exte…”
   • [claimed-docs] “The FireHydrant platform offers both internal status pages... as well as external status pages (Atlassian and FireHydrant-hosted).”

   proof ↗⚑ flag

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

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

   FireHydrant~partialclaimed5/10

   Docs confirm FireHydrant offers external, FireHydrant-hosted status pages (in addition to Atlassian-hosted) driven from incident state, distinct from internal ephemeral status pages. However, the evidence never mentions custom domain support or subscriber notification functionality for these external pages. Missing for 10: custom domain configuration, subscriber/notification mechanics, and any independent confirmation of hosted page setup.

   • [claimed-docs] “The FireHydrant platform offers both internal status pages... as well as external status pages (Atlassian and FireHydrant-hosted).”
   • [claimed-docs] “organizations use status pages for these updates... as well as external status pages (Atlassian and FireHydrant-hosted)”
   • [claimed-docs] “as well as external status pages (Atlassian and FireHydrant-hosted)”
   • [claimed-docs] “The FireHydrant platform offers both internal status pages, which are meant for the internal team only and require no setup, as well as exte…”
   • [claimed-docs] “as well as external status pages (Atlassian and FireHydrant-hosted).”
   • [claimed-docs] “each incident on FireHydrant will have a dedicated ephemeral status page that summarizes high-level details and includes key links”

   proof ↗⚑ flag