incident.io vs FireHydrant

Agent access

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

   weight 2 · round drawn
   incident.io✓fullprobed8/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   FireHydrant~partialprobed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   incident.io—none0/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to incident.io
   incident.io✓fullprobed9/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullprobed8/10

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

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

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   incident.io—none0/10

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

   ⚑ flag

   FireHydrant—none0/10

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

   ⚑ flag

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

   weight 3 · round drawn
   incident.io✓fullprobed8/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to incident.io
   incident.io~partialprobed3/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to incident.io
   incident.io~partialprobed4/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to incident.io
   incident.io✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed3/10

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

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

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   incident.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to incident.io
   incident.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to incident.io
   incident.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to incident.io
   incident.io✓fullprobed8/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialprobed6/10

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

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

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to incident.io
   incident.io~partialprobed4/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to incident.io
   incident.io✓fullprobed9/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

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

   weight 1 · round to incident.io
   incident.io~partialprobed3/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

   ⚑ flag

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

   weight 2 · round to incident.io
   incident.io~partialprobed3/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

Agent ops

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

   weight 3 · round to incident.io
   incident.io~partialprobed7/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialprobed6/10

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

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

   proof ↗⚑ flag

Ai investigation

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

   weight 2 · round to incident.io
   incident.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed5/10

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

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

   proof ↗⚑ flag

Ai summaries

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

   weight 2 · round drawn
   incident.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to incident.io
   incident.io✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed6/10

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

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

   proof ↗⚑ flag

Escalation

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

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

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed5/10

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

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

   proof ↗⚑ flag

Noise reduction

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

   weight 2 · round to incident.io
   incident.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

Paging

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

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

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed3/10

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

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

   proof ↗⚑ flag

Routing

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

   weight 3 · round drawn
   incident.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Metrics

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

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

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

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

   proof ↗⚑ flag

   FireHydrant✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   incident.io—none0/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   FireHydrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   incident.io—none0/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

   ⚑ flag

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

   weight 1 · round drawn
   incident.io—none0/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

Runbooks

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

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

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

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

   proof ↗⚑ flag

   FireHydrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Workflows

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

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

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

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

   proof ↗⚑ flag

   FireHydrant✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Communications

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

   weight 1 · round to FireHydrant
   incident.io~partialclaimed5/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed7/10

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

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

   proof ↗⚑ flag

Coordination

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

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

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

   ⚑ flag

   FireHydrant✓fullclaimed9/10

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

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

   proof ↗⚑ flag

Declaration

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

   weight 3 · round to incident.io
   incident.io✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed6/10

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

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

   proof ↗⚑ flag

Timeline

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

   weight 2 · round to incident.io
   incident.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed6/10

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

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

   proof ↗⚑ flag

Alert sources

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

   weight 3 · round drawn
   incident.io—none0/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

Workflow tools

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

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

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed7/10

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

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

   proof ↗⚑ flag

Mobile

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

   weight 2 · round drawn
   incident.io—none0/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

   ⚑ flag

Quality of life

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

   weight 1 · round drawn
   incident.io—none0/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

Schedules

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

   weight 3 · round drawn
   incident.io~partialclaimed6/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   incident.io—none0/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to FireHydrant
   incident.io~partialprobed6/10

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

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

   proof ↗⚑ flag

   FireHydrant✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to incident.io
   incident.io~partialprobed4/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

   ⚑ flag

Follow ups

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

   weight 2 · round drawn
   incident.io~partialclaimed5/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed5/10

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

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

   proof ↗⚑ flag

Postmortems

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

   weight 3 · round drawn
   incident.io~partialclaimed7/10

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

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

   proof ↗⚑ flag

   FireHydrant~partialclaimed7/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   incident.io—none0/10

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

   ⚑ flag

   FireHydrant—none0/10

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

   ⚑ flag

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

   weight 3 · round to FireHydrant
   incident.io—none0/10

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

   ⚑ flag

   FireHydrant~partialclaimed3/10

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

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

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   incident.io—none0/10

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

   ⚑ flag

   FireHydrant—none0/10

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

   ⚑ flag

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

   weight 2 · round drawn
   incident.io—none0/10

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

   ⚑ flag

   FireHydrant—none0/10

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

   ⚑ flag

Status pages

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

   weight 1 · round to incident.io
   incident.io~partialclaimed6/10

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

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

   proof ↗⚑ flag

   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   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