FireHydrant vs Rootly

Agent access

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

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

   Rootly✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

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

   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

   Rootly✓fullprobed9/10

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

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

   proof ↗⚑ flag

5. ai-native userUse an official CLI

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

   Rootly—none0/10

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

   ⚑ flag

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

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

   Rootly✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   Rootly~partialprobed5/10

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

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

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

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

   Rootly—none0/10

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

   ⚑ flag

Agentic features

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

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

   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

   Rootly✓fullprobed7/10

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

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

   proof ↗⚑ flag

Api quality

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

   Rootly—none0/10

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

   ⚑ flag

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Agent ops

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

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

   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

Ai investigation

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

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

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

Ai summaries

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Escalation

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Noise reduction

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Paging

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

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

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

Routing

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

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

   Rootly✓fullclaimed9/10

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

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

   proof ↗⚑ flag

Metrics

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

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

   Rootly—none0/10

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

   ⚑ flag

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Runbooks

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

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

   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

Workflows

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Communications

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

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

   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Coordination

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Declaration

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Timeline

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Alert sources

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Workflow tools

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

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

   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

Mobile

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

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

   Rootly~partialclaimed3/10

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

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

   proof ↗⚑ flag

Quality of life

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Schedules

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

   Rootly—none0/10

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

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

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   FireHydrant—none0/10

   FireHydrant is a closed, commercial SaaS incident-management platform; no evidence indicates its core product source is available under any open license. The GitHub repo found is only the separate MCP server client tool, not the product itself, so it doesn't establish open licensing of the platform.

   ⚑ flag

   Rootly—none0/10

   Rootly is a closed, commercial SaaS incident-management platform; no evidence indicates its core product source is published under an open license (only an MCP server client integration exists on GitHub, not the product itself). No open-source license, repo, or source availability for the core platform is mentioned anywhere in the evidence pack.

   ⚑ flag

Follow ups

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

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

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

Postmortems

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

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

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   Rootly—none0/10

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

   ⚑ flag

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

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

   Rootly—none0/10

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

   ⚑ flag

3. ai-native userControl data retention and deletion

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

   Rootly—none0/10

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

   ⚑ flag

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

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

   Rootly—none0/10

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

   ⚑ flag

Status pages

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

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

   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag