FireHydrant vs Better Stack

Agent access

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

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

   Better Stack~partialprobed5/10

   A direct llms.txt probe returned 404, but Better Stack does serve a machine-readable docs.md endpoint (HTTP 200) that could be pointed at by an agent as an alternative agent-oriented doc source. There's no dedicated llms.txt or explicit agent-first documentation framework beyond this. Missing for 10: an actual llms.txt file, explicit agent-oriented documentation index, or first-party guidance recommending agents consume a specific machine-readable doc format.

   • [probe] “PROBE llms.txt: HTTP 404 at https://betterstack.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 200 at https://betterstack.com/docs.md # Getting started ![Screenshot from Better Stack](https://imagedelivery.net/xZXo…”

   proof ↗⚑ flag

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

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

   Better Stack~partialprobed5/10

   Better Stack exposes a documented, token-authenticated REST API (confirmed live via runtime probe returning 401 on unauthenticated request) that could be scripted in CI for monitor/incident management, and it offers an MCP server for LLM workflow integration. However, there is no evidence of a CLI tool, headless automation examples, CI/CD pipeline integration guides, or non-interactive batch usage patterns specifically for automation contexts. missing for 10: CLI or SDK for scripting, documented CI/CD integration examples, headless/non-interactive automation workflows beyond the generic API and MCP mentions.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “An Uptime API token is a team-scoped token for managing your Uptime resources.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”
   • [claimed-docs] “Robust MCP server Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Integrate your logs, metrics, traces, web events, and errors into your existing LLM workflows with a top tier MCP server.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   Better Stack ships its own MCP server so other agents (e.g. Claude Code) can call its tools, but there is no evidence that Better Stack itself can consume/plug in external MCP servers to use their tools — the AI SRE agent is described only as accessible via Slack, Teams, or LLM workflows, not as an MCP client that ingests other servers' tools.

   • [claimed-docs] “Integrate your logs, metrics, traces, web events, and errors into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Chat online, inside Slack and in Claude Code using the MCP”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”
   • [claimed-docs] “Robust MCP server Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed7/10

   Better Stack advertises a first-party MCP server that integrates logs, metrics, traces, and telemetry into LLM workflows, and explicitly mentions usage in Claude Code via MCP. Missing for 10: independent/hands-on corroboration of the MCP server's setup or reliability, and no dedicated docs page detailing MCP server configuration/auth beyond marketing claims.

   • [claimed-docs] “Integrate your logs, metrics, traces, web events, and errors into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Chat online, inside Slack and in Claude Code using the MCP”
   • [claimed-docs] “Robust MCP server Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   FireHydrant—none0/10

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

   ⚑ flag

   Better Stack—none0/10

   Evidence covers a REST API, MCP server, and Slack/Teams integrations, but there is no mention of an official CLI tool anywhere in the docs or probes.

   ⚑ flag

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

   weight 3 · round drawn
   FireHydrant✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Better Stack✓fullprobed8/10

   Better Stack documents a public API (global and team-scoped tokens, Bearer auth) with a getting-started guide, and a runtime probe confirms the Uptime API endpoint is live and correctly auth-gated, matching docs. It also offers an MCP server for LLM integration, directly supporting AI-native/agentic use. Missing for 10: a full OpenAPI/swagger spec discoverable at standard paths (probe found 404s) and broader API coverage documentation beyond Uptime.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “An Uptime API token is a team-scoped token for managing your Uptime resources.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”
   • [claimed-docs] “Robust MCP server Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Chat online, inside Slack and in Claude Code using the MCP”
   • [probe] “PROBE openapi: all candidate paths 404 (https://betterstack.com/openapi.json, https://betterstack.com/swagger.json, https://betterstack.com/…”

   proof ↗⚑ flag

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

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

   Better Stack~partialclaimed3/10

   Better Stack's API docs describe only two token tiers — a 'global' token valid across all teams and resources, and a team-scoped Uptime token — which offers coarse scoping but no evidence of fine-grained, per-agent or read/write-limited least-privilege credentials tailored for AI agents. Missing for 10: documented scopes/permissions (read-only, resource-specific), agent-specific credential issuance, expiring/rotatable tokens, and any MCP-server-specific auth scoping despite the product advertising an MCP server for LLM workflows.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “An Uptime API token is a team-scoped token for managing your Uptime resources.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “Robust MCP server Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   Evidence shows a documented REST API with bearer-token auth and an MCP server for LLM integration, but there is no mention of official client SDKs (e.g., Python, Node, Go libraries) for developers to build against.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://betterstack.com/openapi.json, https://betterstack.com/swagger.json, https://betterstack.com/…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to FireHydrant
   FireHydrant~partialclaimed3/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   Better Stack’s evidence pack covers Slack/Teams/email/SMS alerting, an API with bearer-token auth, and an MCP server for LLM workflows, but nowhere mentions webhooks as a subscription mechanism for events (incidents, monitor status changes, etc.). Since webhook support is a standard, plausible capability for a monitoring/incident platform, its absence from all docs and probes means this axis is unmet rather than inapplicable.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “An Uptime API token is a team-scoped token for managing your Uptime resources.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”
   • [claimed-docs] “This integration allows you to receive incident alerts directly in Slack.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to FireHydrant
   FireHydrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Better Stack✓fullclaimed7/10

   Better Stack's AI SRE feature explicitly offers natural-language querying of logs/charts, AI-generated post-mortems, AI-based incident fix suggestions with linked GitHub PRs, and AI-driven Linear ticket suggestions — directly matching the story of getting AI-generated insights from data. Missing for 10: independent/hands-on verification of these AI features' quality, and detail on what data sources power the natural-language insight generation beyond marketing copy.

   • [claimed-docs] “Get recent logs or chart visualizations by simply asking in natural language.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Downtime? Create Linear tickets to fix the root cause using AI-based suggestions with a single tap.”
   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”

   proof ↗⚑ flag

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

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

   Better Stack~partialclaimed6/10

   Better Stack's monitors, CRON/serverless job tracking, and escalation policies run continuously and autonomously in the background (docs-6, docs-16, docs-37, docs-39), and the AI SRE agent can autonomously investigate incidents, draft post-mortems, and open PRs/Linear tickets (docs-8, docs-9, docs-23, docs-33, docs-54). However, several AI SRE features appear to be invoked on-demand (e.g., tagging @betterstack in Slack, docs-55) rather than fully self-initiating, and there's no independent corroboration of true unattended autonomous operation. Missing for 10: independent/hands-on verification of unattended autonomous triggering, and clearer documentation of scheduled/agentic workflow configuration beyond monitoring and incident response.

   • [claimed-docs] “Track your CRON jobs and serverless workers and get alerted if they don't run correctly.”
   • [claimed-docs] “Never lose a database backup again. Track your CRON jobs and serverless workers and get alerted if they don't run correctly.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”
   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Downtime? Create Linear tickets to fix the root cause using AI-based suggestions with a single tap.”
   • [claimed-docs] “Discussing an incident in Slack? Call the AI SRE simply by tagging @betterstack.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed7/10

   Better Stack ships a built-in 'AI SRE' agent that investigates incidents, answers natural-language queries about logs/charts, drafts post-mortems, opens GitHub PRs and Linear tickets, and can be invoked directly from Slack/Teams by tagging @betterstack — this is a genuine in-product AI assistant users can delegate SRE tasks to, not just an external MCP integration. Missing for 10: independent/hands-on verification of the AI SRE's actual task outcomes and reliability, since all evidence is vendor-authored marketing/docs.

   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “Get recent logs or chart visualizations by simply asking in natural language.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”
   • [claimed-docs] “Discussing an incident in Slack? Call the AI SRE simply by tagging @betterstack.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”
   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Downtime? Create Linear tickets to fix the root cause using AI-based suggestions with a single tap.”

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed7/10

   Better Stack's AI SRE explicitly supports natural-language interaction: users can ask for logs/charts in plain language, tag @betterstack in Slack, or use the MCP server to query telemetry from LLM workflows like Claude Code. This is a genuine natural-language operation surface, not just chat-adjacent automation. Missing for 10: independent/hands-on verification of natural-language query accuracy, and broader coverage beyond logs/charts (e.g., natural-language incident management or monitor configuration).

   • [claimed-docs] “Get recent logs or chart visualizations by simply asking in natural language.”
   • [claimed-docs] “Chat online, inside Slack and in Claude Code using the MCP”
   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”
   • [claimed-docs] “Discussing an incident in Slack? Call the AI SRE simply by tagging @betterstack.”
   • [claimed-docs] “Integrate your logs, metrics, traces, web events, and errors into your existing LLM workflows with a top tier MCP server.”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   Better Stack has documented REST APIs (Uptime API with bearer token auth) but there is no evidence of an interactive API reference with runnable/try-it examples — OpenAPI/Swagger endpoint probes all returned 404, and no docs mention an interactive console or code sandbox.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “An Uptime API token is a team-scoped token for managing your Uptime resources.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://betterstack.com/openapi.json, https://betterstack.com/swagger.json, https://betterstack.com/…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   Better Stack has a documented REST API (Uptime API with bearer-token auth) confirmed live via runtime probe, so a machine-readable spec is a fair expectation, but explicit probes for OpenAPI/Swagger files at all standard paths returned 404 and no docs mention an OpenAPI spec or downloadable schema.

   • [probe] “PROBE openapi: all candidate paths 404 (https://betterstack.com/openapi.json, https://betterstack.com/swagger.json, https://betterstack.com/…”
   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   The evidence pack shows Better Stack has a documented, auth-gated Uptime API (bearer token, live endpoint) but contains no mention of API versioning scheme or any deprecation policy. Since this is a fair question for a SaaS product with a public API, absence of evidence means the story is not delivered.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “An Uptime API token is a team-scoped token for managing your Uptime resources.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://betterstack.com/openapi.json, https://betterstack.com/swagger.json, https://betterstack.com/…”

   proof ↗⚑ flag

Agent ops

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

   weight 3 · round drawn
   FireHydrant~partialprobed6/10

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

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

   proof ↗⚑ flag

   Better Stack~partialprobed6/10

   Better Stack offers a documented Uptime API (token-authenticated, verified live via runtime probe) and an MCP server for querying telemetry/logs/metrics, plus a Slack-native AI SRE agent that can investigate and act on incidents, giving agents multiple non-dashboard paths to interact with incidents. However, evidence shows acknowledge/escalate/resolve actions are documented primarily via Slack, phone-tap, and dashboard UI (docs-3, docs-11, docs-19, docs-38), not explicitly via the MCP or REST API, so full end-to-end incident lifecycle control (create+ack+escalate+resolve) purely through API/MCP without any dashboard/Slack UI step is not directly documented. missing for 10: explicit API/MCP endpoints or docs for acknowledging/escalating/resolving incidents programmatically, and confirmation that MCP tool calls (not just Slack chat) can perform these actions end-to-end.

   • [claimed-docs] “Integrate your logs, metrics, traces, web events, and errors into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Chat online, inside Slack and in Claude Code using the MCP”
   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”
   • [claimed-docs] “Create, acknowledge and resolve incidents directly from Slack”
   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”

   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 Better Stack
   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

   Better Stack✓fullclaimed7/10

   Better Stack's AI SRE agent explicitly investigates incidents using logs, metrics, traces, errors, and web events (docs-23), can be invoked proactively in Slack/Teams, and generates automated post-mortems from incident timelines plus AI-suggested fixes/PRs and tickets (docs-8, docs-9, docs-33, docs-54), matching the 'correlating changes, telemetry, and past incidents' framing. Missing for 10: independent/hands-on verification that it proactively investigates before a human asks (evidence shows it's invoked via tagging/chat, not fully autonomous), and no detail on how 'similar past incidents' correlation works technically.

   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Downtime? Create Linear tickets to fix the root cause using AI-based suggestions with a single tap.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”
   • [claimed-docs] “Discussing an incident in Slack? Call the AI SRE simply by tagging @betterstack.”

   proof ↗⚑ flag

Ai summaries

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

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

   Better Stack~partialclaimed6/10

   Better Stack explicitly claims an automated post-mortem feature 'based on the incident timeline and Slack' as part of its AI SRE offering, directly matching the story's core ask. However, the evidence is marketing copy only — no detail on contributing-factors analysis, follow-up generation, or human-review workflow, and no independent/hands-on confirmation of output quality. Missing for 10: detailed documentation of postmortem structure (contributing factors, follow-ups), independent verification of the feature working, and explicit human-review/approval workflow.

   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”
   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”

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

   Better Stack~partialclaimed5/10

   Better Stack's AI SRE agent investigates incidents via Slack and produces an automated post-mortem based on the incident timeline and Slack conversation, and can answer natural-language queries for logs/charts — but this is largely post-incident summarization plus Q&A, not live status update drafting or call-note scribing during the incident itself. Missing for 10: evidence of real-time drafted stakeholder updates while the incident is live, and any call/voice transcription or scribing feature.

   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”
   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “Get recent logs or chart visualizations by simply asking in natural language.”
   • [claimed-docs] “Discussing an incident in Slack? Call the AI SRE simply by tagging @betterstack.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”

   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 Better Stack
   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

   Better Stack✓fullclaimed9/10

   Docs explicitly describe escalation policies as custom rulesets defining who is alerted and in what order, continuing until acknowledged, with real examples (on-call person notified first, escalates to whole team after 3 minutes if unacknowledged), configurable complex rules based on time/team availability/incident origin, multi-region schedules, and phone/press-1 acknowledgment flows. Missing for 10: no independent/hands-on third-party corroboration of escalation behavior beyond vendor docs.

   • [claimed-docs] “It defines who will be alerted and in what order, continuing until the incident is acknowledged.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “Configure complex rules for escalating incidents based on time, team availability, and incident origin.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”
   • [claimed-docs] “If they don't acknowledge the incident (for example, after 3 minutes), it escalates and notifies everyone on the team.”
   • [claimed-docs] “When Uptime calls you, you are prompted to press 1 to acknowledge the incident.”
   • [claimed-docs] “First, create three schedules for **EU**, **US West**, and **Asia/Pacific** time zones to ensure 24/7 global coverage.”

   proof ↗⚑ flag

Noise reduction

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

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

   Better Stack—none0/10

   Evidence covers escalation policies, on-call scheduling, and notification cascades, but there is no mention of alert deduplication or incident grouping logic. In fact, docs-19/docs-53 describe '30 incidents created at the same time' with bulk one-tap acknowledgment as the mitigation — implying duplicates still spawn separate incidents rather than being merged into a single paged incident. No evidence of true dedup/grouping into one incident exists.

   • [claimed-docs] “30 incidents get created at the same time. Acknowledge them with a single tap and stop your phone from ringing.”
   • [claimed-docs] “10 incidents created at the same time? Acknowledge them with a single tap and keep your phone from ringing while fixing the issue.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”
   • [claimed-docs] “If they don't acknowledge the incident (for example, after 3 minutes), it escalates and notifies everyone on the team.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”

   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 Better Stack
   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

   Better Stack✓fullclaimed9/10

   Better Stack documents per-channel alerting (voice call, SMS, email, Slack, Teams, push) as part of its all-you-can-alert pricing, backed by escalation policy docs, phone-call acknowledgment (press 1), and Slack/Teams incident notifications, giving on-call engineers multi-channel reachability with configurable escalation rules. Missing for 10: no explicit documentation of independently configurable per-channel notification *rules* (e.g., choosing SMS vs push for specific severities) beyond escalation policy ordering, and no third-party/independent corroboration of reliability.

   • [claimed-docs] “Unlimited voice call alerts As well as SMS, e-mail, Slack, Teams, and push notifications with our all-you-can-alert pricing.”
   • [claimed-docs] “When Uptime calls you, you are prompted to press 1 to acknowledge the incident.”
   • [claimed-docs] “It defines who will be alerted and in what order, continuing until the incident is acknowledged.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”
   • [claimed-docs] “If they don't acknowledge the incident (for example, after 3 minutes), it escalates and notifies everyone on the team.”
   • [claimed-docs] “Configure complex rules for escalating incidents based on time, team availability, and incident origin.”

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

   Better Stack✓fullprobed8/10

   Better Stack documents ingestion from third-party monitoring/observability sources (Datadog, New Relic, Grafana, Prometheus, Zabbix, cloud providers) plus its own monitors, and provides escalation policies that route alerts to on-call teams based on custom rules (time, team availability, incident origin), with schedules, overrides, and multi-channel notification confirmed by docs and a live API probe. missing for 10: independent/third-party confirmation of routing accuracy at scale and more detail on condition-based routing logic beyond escalation policy docs.

   • [claimed-docs] “It defines who will be alerted and in what order, continuing until the incident is acknowledged.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “Plug in the services you already use including Datadog, New Relic, Grafana, Prometheus, Zabbix, Azure, AWS & Google Cloud.”
   • [claimed-docs] “Configure complex rules for escalating incidents based on time, team availability, and incident origin.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “First, create three schedules for EU, US West, and Asia/Pacific time zones to ensure 24/7 global coverage.”
   • [claimed-docs] “First, create three schedules for **EU**, **US West**, and **Asia/Pacific** time zones to ensure 24/7 global coverage.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”

   proof ↗⚑ flag

Metrics

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

   weight 2 · round to FireHydrant
   FireHydrant✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   The evidence pack covers incident creation, acknowledgment, escalation policies, on-call scheduling, and status pages, but contains no mention of MTTA/MTTR trend reporting, incident load analytics, or on-call health dashboards that would let a leader track improvement over time. This is a fair capability to expect from an incident/on-call platform, but no evidence shows it exists. Missing for 10: MTTA/MTTR trend metrics, incident load/volume analytics, on-call health/burnout reporting, any historical dashboard or exportable reliability report.

   ⚑ flag

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

   weight 2 · round drawn
   FireHydrant—none0/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   Better Stack exposes a REST API (bearer-token auth, global tokens) and an MCP server for AI workflows, but no evidence describes batch/bulk endpoints or MCP tools that let an AI agent act on many items (monitors, incidents, schedules) in a single call. The only 'bulk' mentions (docs-19, docs-53) refer to a human tapping to acknowledge multiple simultaneous incidents on a phone, not AI-driven bulk automation. Missing for 10: documented bulk-create/update/delete API endpoints, MCP tool support for multi-item operations, or any example of an AI agent performing bulk actions.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “30 incidents get created at the same time. Acknowledge them with a single tap and stop your phone from ringing.”
   • [claimed-docs] “10 incidents created at the same time? Acknowledge them with a single tap and keep your phone from ringing while fixing the issue.”
   • [claimed-docs] “Robust MCP server Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”

   proof ↗⚑ flag

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

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

   Better Stack~partialclaimed7/10

   Better Stack provides configurable escalation policies and monitors that automatically trigger incidents/alerts based on defined conditions (time, team availability, incident origin), plus AI-SRE actions like auto-creating Linear tickets or GitHub PRs on exceptions/downtime — a real rule-based automation layer tied to events. However, this is scoped to incident/monitoring events rather than a general-purpose custom rule engine for arbitrary triggers/actions across the platform. Missing for 10: evidence of a broader custom automation/rule-builder (e.g., webhooks-to-arbitrary-action mapping) beyond incident escalation and the specific AI-SRE actions listed, and independent verification of these automated actions working in practice.

   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “Configure complex rules for escalating incidents based on time, team availability, and incident origin.”
   • [claimed-docs] “An HTTP status code monitor checks your URLs every X seconds for an HTTP success status code (2XX). If the URL doesn't return this code, the…”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Downtime? Create Linear tickets to fix the root cause using AI-based suggestions with a single tap.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   FireHydrant—none0/10

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

   ⚑ flag

   Better Stack—none0/10

   Better Stack only monitors external CRON jobs and serverless workers for failures (docs-6, docs-16) and manages recurring on-call schedules for incident escalation (docs-12, docs-24, docs-46) — none of this is a mechanism for an AI-native user to define or schedule their own recurring automated jobs/workflows within the platform. No evidence of a workflow/job scheduling engine, automation triggers, or recurring task creation exists in the pack.

   • [claimed-docs] “Track your CRON jobs and serverless workers and get alerted if they don't run correctly.”
   • [claimed-docs] “Never lose a database backup again. Track your CRON jobs and serverless workers and get alerted if they don't run correctly.”
   • [claimed-docs] “First, create three schedules for EU, US West, and Asia/Pacific time zones to ensure 24/7 global coverage.”
   • [claimed-docs] “Leverage one of our standard rotation schedules to instantly pre-fill your on-call calendar.”

   proof ↗⚑ flag

Runbooks

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

   weight 2 · round to FireHydrant
   FireHydrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Better Stack~partialclaimed4/10

   Better Stack's AI SRE agent automates several incident-response actions (investigating incidents, generating post-mortems, creating Linear tickets, suggesting GitHub PR fixes) and escalation policies define automated notification chains, but there is no evidence of a structured 'runbook' object that attaches to incidents with discrete steps like auto-creating channels or assigning tasks. missing for 10: explicit runbook/playbook feature, automatic channel creation, task assignment automation, diagnostic step execution tied to a runbook template.

   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”

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

   Better Stack~partialclaimed6/10

   Better Stack ships condition-based automation tied to incident events: escalation policies that alert people in order until acknowledged (docs-13, docs-20, docs-28, docs-39/52), plus AI SRE automations that auto-create Linear tickets, suggest PRs, and generate post-mortems from the incident timeline (docs-33/54, docs-8, docs-9). This covers much of the 'toil automation' story but is a set of pre-built triggers rather than a general-purpose condition/workflow engine for arbitrary field changes or custom reminders. Missing for 10: a documented generic rules/workflow builder letting SREs define custom conditions (e.g., field-change triggers, custom reminders) beyond escalation and the fixed AI-SRE actions.

   • [claimed-docs] “It defines who will be alerted and in what order, continuing until the incident is acknowledged.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “Configure complex rules for escalating incidents based on time, team availability, and incident origin.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”
   • [claimed-docs] “If they don't acknowledge the incident (for example, after 3 minutes), it escalates and notifies everyone on the team.”
   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Downtime? Create Linear tickets to fix the root cause using AI-based suggestions with a single tap.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”

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

   Better Stack~partialclaimed6/10

   Better Stack's status pages let subscribers receive e-mail updates without contacting the team directly, and private/password-protected status pages could be used to give internal stakeholders a dedicated, non-public view of incident status — a plausible mechanism for 'structured updates without joining the war room.' However, the evidence frames this feature around customers, not internal stakeholders, and there's no dedicated internal-stakeholder digest, dashboard, or subscription flow distinct from the public status-page mechanism. Missing for 10: explicit internal-stakeholder subscription workflow, structured incident-update format (vs generic subscribe), and evidence the private status page is actually used for this purpose rather than external customers.

   • [claimed-docs] “Let your customers subscribe to e-mail updates removing the need to reach out to you individually.”
   • [claimed-docs] “To create a private status page, use the password protection to only allow chosen people to access it.”
   • [claimed-docs] “use the [password protection](/docs/uptime/password-protected-status-page/) to only allow chosen people to access it.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”

   proof ↗⚑ flag

Coordination

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

   weight 1 · round to FireHydrant
   FireHydrant✓fullclaimed9/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   Better Stack's incident management docs cover escalation policies, on-call scheduling, acknowledgment, and Slack/Teams integration, but nothing describes assigning structured incident roles (commander, comms lead) or task checklists for coordinated response. Escalation policies define notification order, not role-based incident command structure.

   • [claimed-docs] “It defines who will be alerted and in what order, continuing until the incident is acknowledged.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “Configure complex rules for escalating incidents based on time, team availability, and incident origin.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”

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

   Better Stack~partialclaimed6/10

   Better Stack documents creating, acknowledging, and resolving incidents directly from Slack, plus a Slack-native AI SRE agent invoked by tagging @betterstack, and escalation policies define on-call roles/order. Teams support is mentioned only for alert delivery, not for declaring/running incidents, and there's no explicit evidence of automatic incident-channel creation or full role/update automation in Teams. missing for 10: explicit incident channel auto-creation, Teams-side full incident declare/manage parity, independent hands-on confirmation.

   • [claimed-docs] “Create, acknowledge and resolve incidents directly from Slack”
   • [claimed-docs] “This integration allows you to receive incident alerts directly in Slack.”
   • [claimed-docs] “Discussing an incident in Slack? Call the AI SRE simply by tagging @betterstack.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”
   • [claimed-docs] “Unlimited voice call alerts As well as SMS, e-mail, Slack, Teams, and push notifications with our all-you-can-alert pricing.”
   • [claimed-docs] “It defines who will be alerted and in what order, continuing until the incident is acknowledged.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”

   proof ↗⚑ flag

Timeline

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

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

   Better Stack~partialclaimed5/10

   Better Stack automatically builds an incident timeline that includes alerts, on-call actions (ack/escalate), and Slack chat, and uses it to generate an automated post-mortem (docs-3, docs-9, docs-38, docs-23). However, there is no evidence describing the ability to manually edit or annotate the timeline after the fact. missing for 10: explicit editing/annotation UI or API for the incident timeline, evidence of manual timeline entry additions, independent confirmation of timeline accuracy/completeness.

   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”
   • [claimed-docs] “Create, acknowledge and resolve incidents directly from Slack”
   • [claimed-docs] “The incident alert message includes information about the monitor, as well as the options to acknowledge the incident or to view more detail…”
   • [claimed-docs] “Slack-native AI SRE agent that investigates incidents using your logs, metrics, traces, errors, and web events.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”

   proof ↗⚑ flag

Alert sources

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

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

   Better Stack~partialclaimed6/10

   Better Stack explicitly claims integration with Datadog, Grafana, Prometheus, AWS/CloudWatch, and mentions a Datadog migration path, plus a general MCP server for connecting telemetry data into LLM workflows. However, evidence is limited to marketing one-liners on the status-page/homepage listing tool names (e.g. 'Plug in the services you already use including Datadog, New Relic, Grafana, Prometheus') with no dedicated per-integration setup docs, no explicit mention of Sentry or CloudWatch by name, and no walkthroughs showing configuration steps for each. Missing for 10: named Sentry/CloudWatch integration docs, dedicated setup guides per integration, and independent/hands-on confirmation these integrations work as advertised.

   • [claimed-docs] “Plug in the services you already use including Datadog, New Relic, Grafana, Prometheus, Zabbix, Azure, AWS & Google Cloud.”
   • [claimed-docs] “Datadog bill too high? Migrate today, the rest of your contract is on us. Migration assistance and bespoke onboarding included.”
   • [claimed-docs] “Datadog bill too high? Migrate today, the rest of your contract is on us.”
   • [claimed-docs] “Robust MCP server Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”
   • [claimed-docs] “Integrate your telemetry data into your existing LLM workflows with a top tier MCP server.”

   proof ↗⚑ flag

Workflow tools

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

   weight 2 · round to FireHydrant
   FireHydrant~partialclaimed7/10

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

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

   proof ↗⚑ flag

   Better Stack~partialclaimed4/10

   Slack integration is well documented (create/ack/resolve incidents, alerts, AI SRE tagging via docs-3, docs-38, docs-48, docs-55), Teams appears only as an alert channel (docs-29, docs-32), and GitHub integration is one-directional (auto-generated PR with fix suggestion, docs-8) rather than bidirectional state sync. Jira and Zoom are not mentioned anywhere in the evidence pack; Linear (not Jira) is the ticketing tool referenced (docs-33, docs-54). missing for 10: any Jira integration, any Zoom integration, two-way (not just outbound) GitHub state sync, and deeper Teams bidirectional actions beyond alerting.

   • [claimed-docs] “Create, acknowledge and resolve incidents directly from Slack”
   • [claimed-docs] “The incident alert message includes information about the monitor, as well as the options to acknowledge the incident or to view more detail…”
   • [claimed-docs] “This integration allows you to receive incident alerts directly in Slack.”
   • [claimed-docs] “Discussing an incident in Slack? Call the AI SRE simply by tagging @betterstack.”
   • [claimed-docs] “Unlimited voice call alerts As well as SMS, e-mail, Slack, Teams, and push notifications with our all-you-can-alert pricing.”
   • [claimed-docs] “Call the AI SRE from Slack, MS Teams, or your existing LLM workflows.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Downtime? Create Linear tickets to fix the root cause using AI-based suggestions with a single tap.”

   proof ↗⚑ flag

Mobile

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

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

   Better Stack~partialclaimed5/10

   Evidence shows on-call alerting via phone call (press 1 to acknowledge), push notifications, and single-tap acknowledgment of multiple incidents, implying a mobile app exists for at least acknowledging incidents. However, there is no explicit documentation of escalating or resolving incidents from the mobile app, only acknowledgment is described. Missing for 10: explicit mobile app screenshots/docs showing escalate and resolve actions, confirmation of full incident management (not just ack) from the phone interface, and any independent user reports of the mobile app experience at odd hours.

   • [claimed-docs] “When Uptime calls you, you are prompted to press 1 to acknowledge the incident.”
   • [claimed-docs] “30 incidents get created at the same time. Acknowledge them with a single tap and stop your phone from ringing.”
   • [claimed-docs] “Unlimited voice call alerts As well as SMS, e-mail, Slack, Teams, and push notifications with our all-you-can-alert pricing.”
   • [claimed-docs] “10 incidents created at the same time? Acknowledge them with a single tap and keep your phone from ringing while fixing the issue.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”

   proof ↗⚑ flag

Quality of life

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

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

   Better Stack~partialclaimed6/10

   Better Stack documents calendar integration for on-call schedules, stating it can 'Integrate with Google & Outlook calendar' and that schedules can be kept in 'a shared Google calendar' instead of the built-in interface, supporting the core need to see on-call shifts in a personal calendar. However, there's no explicit mention of a subscribable iCal/ICS feed URL, sync frequency, or Outlook-specific feed mechanics. Missing for 10: explicit iCal/ICS feed link details, documentation of sync behavior/real-time updates, and independent/hands-on confirmation of the calendar sync working reliably.

   • [claimed-docs] “Integrate with Google & Outlook calendar”
   • [claimed-docs] “Manage on-call schedules from our built-in web interface or keep them in a shared Google calendar.”

   proof ↗⚑ flag

Schedules

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

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

   Better Stack~partialclaimed7/10

   Better Stack's docs show clear on-call scheduling primitives: multiple time-zone-based schedules for 24/7 coverage (betterstack-docs-12/46), standard rotation templates to pre-fill on-call calendars (betterstack-docs-24), overrides and cover requests (betterstack-docs-17/18), calendar integration (betterstack-docs-25/49), and escalation policies defining alert order (betterstack-docs-13/20/40/39/52). However, there is no explicit mention of 'layers' (multi-layer scheduling) or 'round-robin' rotation logic as distinct configurable concepts—only generic 'standard rotation schedules' are cited. Missing for 10: explicit layered scheduling support, explicit round-robin rotation mechanics, and independent/hands-on verification of complex rotation setups.

   • [claimed-docs] “First, create three schedules for EU, US West, and Asia/Pacific time zones to ensure 24/7 global coverage.”
   • [claimed-docs] “First, create three schedules for **EU**, **US West**, and **Asia/Pacific** time zones to ensure 24/7 global coverage.”
   • [claimed-docs] “Leverage one of our standard rotation schedules to instantly pre-fill your on-call calendar.”
   • [claimed-docs] “Ask a colleague to cover for you with a single click on the "Request cover" button.”
   • [claimed-docs] “Create overrides with a single click”
   • [claimed-docs] “Integrate with Google & Outlook calendar”
   • [claimed-docs] “Manage on-call schedules from our built-in web interface or keep them in a shared Google calendar.”
   • [claimed-docs] “It defines who will be alerted and in what order, continuing until the incident is acknowledged.”
   • [claimed-docs] “An escalation policy is a custom set of rules for incident alerting, ideal for creating advanced incident alerting processes. It defines who…”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”
   • [claimed-docs] “If they don't acknowledge the incident (for example, after 3 minutes), it escalates and notifies everyone on the team.”

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed8/10

   Better Stack explicitly supports one-click 'Request cover' and one-click override creation, plus escalation policies that continue notifying until acknowledgment, all without admin intervention to rebuild schedules. Shift swap isn't explicitly named, but overrides and cover requests directly address the core story need for self-service schedule changes. Missing for 10: explicit documentation of a distinct 'shift swap' workflow and independent/hands-on verification beyond vendor docs.

   • [claimed-docs] “Ask a colleague to cover for you with a single click on the “Request cover” button.”
   • [claimed-docs] “Ask a colleague to cover for you with a single click on the "Request cover" button.”
   • [claimed-docs] “Create overrides with a single click”
   • [claimed-docs] “It defines who will be alerted and in what order, continuing until the incident is acknowledged.”
   • [claimed-docs] “The current on-call person is notified first. If they don’t acknowledge the incident (for example, after 3 minutes), it escalates and notifi…”
   • [claimed-docs] “Leverage one of our standard rotation schedules to instantly pre-fill your on-call calendar.”

   proof ↗⚑ flag

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

   weight 2 · round to FireHydrant
   FireHydrant✓fullprobed7/10

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

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

   proof ↗⚑ flag

   Better Stack~partialprobed5/10

   Better Stack documents an Uptime API with global and team-scoped tokens explicitly described as usable 'for managing anything within Better Stack,' and a runtime probe confirms the API is live and properly auth-gated. However, there's no OpenAPI/swagger spec, no llms.txt, and no explicit evidence that incident management, status pages, or AI-SRE features are fully API-accessible beyond Uptime resources. Missing for 10: comprehensive API reference/OpenAPI spec, explicit API parity claims for non-Uptime features (incident management, status pages, on-call scheduling), and independent verification of full UI-to-API parity.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “An Uptime API token is a team-scoped token for managing your Uptime resources.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://betterstack.com/openapi.json, https://betterstack.com/swagger.json, https://betterstack.com/…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://betterstack.com/llms.txt”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   FireHydrant—none0/10

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

   ⚑ flag

   Better Stack—none0/10

   The evidence shows Better Stack offers APIs for managing monitors/incidents (e.g., Uptime API with bearer tokens) but nothing about bulk exporting logs, metrics, traces, or incident history in open formats, nor any stated data-portability policy for users who want to leave the platform. No docs, blog, or community evidence address full data export or open-format portability.

   • [claimed-docs] “A global API token is a token valid across all your teams, for managing anything within Better Stack.”
   • [claimed-docs] “Simply include an `Authorization: Bearer $TOKEN` header in your requests.”
   • [claimed-docs] “An Uptime API token is a team-scoped token for managing your Uptime resources.”
   • [probe] “PROBE runtime (recorded 2026-09-06): Better Stack's documented Uptime API is live and cleanly auth-gated — a keyless GET https://uptime.bett…”

   proof ↗⚑ flag

Follow ups

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

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

   Better Stack~partialclaimed5/10

   Better Stack's AI SRE creates Linear tickets and GitHub PRs from incidents/downtime, and generates automated post-mortems from the incident timeline, which supports the 'sync to issue tracker' half of the story. However, there's no evidence of a mechanism to track these follow-up items to completion (e.g., status sync back from Linear/GitHub, completion dashboards, or reporting on outstanding action items across incidents). missing for 10: tracking/closure verification of follow-up action items, broader issue-tracker support beyond Linear/GitHub, reporting on completion rates across incidents.

   • [claimed-docs] “Downtime? Create Linear tickets using AI‑based suggestions.”
   • [claimed-docs] “Downtime? Create Linear tickets to fix the root cause using AI-based suggestions with a single tap.”
   • [claimed-docs] “Got an exception? Get a pull request with a suggested fix waiting for you in GitHub.”
   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”

   proof ↗⚑ flag

Postmortems

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

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

   Better Stack~partialclaimed4/10

   Better Stack documents an AI-generated postmortem drawn from the incident timeline and Slack discussion (betterstack-docs-9), showing drafting-from-timeline exists, but there is no evidence of a template library, a structured review step, or a publication/sharing workflow for postmortems. missing for 10: postmortem templates, review/approval workflow, publication mechanism.

   • [claimed-docs] “Get an automated post-mortem based on the incident timeline and Slack.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   FireHydrant—none0/10

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

   ⚑ flag

   Better Stack—none0/10

   No evidence in the pack mentions data residency, region selection, or storage location controls for Better Stack; the evidence covers monitoring, incident management, and AI-SRE features only. This is an applicable axis for a SaaS platform storing customer telemetry data, so absence of evidence yields 'none'.

   ⚑ flag

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

   weight 3 · round to FireHydrant
   FireHydrant~partialclaimed3/10

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

   The evidence pack contains no mention of AI training data opt-out, data usage policies for model training, or any privacy controls specific to preventing AI training on customer data. Better Stack's evidence is focused on monitoring, incident management, and AI SRE features, with no documentation addressing this specific privacy-posture axis.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   FireHydrant—none0/10

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

   ⚑ flag

   Better Stack—none0/10

   The evidence pack covers uptime monitoring, incident management, status pages, and AI SRE features but contains no documentation about data retention policies, configurable retention periods, or data deletion controls for logs/metrics/telemetry data. No mention of GDPR/data deletion tooling, retention settings, or export/delete APIs specific to user data. missing for 10: retention period configuration, data deletion/export controls, documentation on how long logs/metrics/traces are stored or how to purge them.

   ⚑ flag

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

   weight 2 · round drawn
   FireHydrant—none0/10

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

   ⚑ flag

   Better Stack—none0/10

   No evidence in the pack addresses telemetry opt-out or usage-tracking controls for Better Stack itself; all citations describe monitoring/incident/AI-SRE features rather than privacy or telemetry settings.

   ⚑ 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 Better Stack
   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

   Better Stack✓fullclaimed7/10

   Better Stack's status page docs explicitly support restricting page access to select people via password protection, and marketing docs list SSO, password, and IP protection as security options for status pages — directly matching private/internal status page access control for engineering leaders. missing for 10: independent/hands-on corroboration beyond vendor docs, and explicit detail on segmenting audiences (e.g., separate customer-only vs employee-only pages) rather than a single access-gated page.

   • [claimed-docs] “To create a private status page, use the password protection to only allow chosen people to access it.”
   • [claimed-docs] “use the [password protection](/docs/uptime/password-protected-status-page/) to only allow chosen people to access it.”
   • [claimed-docs] “SSO, password, and IP protection”
   • [claimed-docs] “Host a branded status page on your own custom subdomain and build confidence in your brand.”

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed9/10

   Better Stack's status page product explicitly supports custom subdomains/branding, custom CSS, email subscriber notifications, password protection/SSO for private pages, and is driven from monitor/incident state (HTTP monitors auto-create incidents reflected on the page). This covers hosting, custom domain, subscriber notifications, and incident-driven state directly per docs. Missing for 10: independent/hands-on corroboration beyond vendor docs and no explicit mention of automatic custom SSL/domain verification flow details.

   • [claimed-docs] “Host a branded status page on your own custom subdomain and build confidence in your brand.”
   • [claimed-docs] “You can customize the design to match your product with a custom CSS.”
   • [claimed-docs] “Let your customers subscribe to e-mail updates removing the need to reach out to you individually.”
   • [claimed-docs] “SSO, password, and IP protection”
   • [claimed-docs] “To create a private status page, use the password protection to only allow chosen people to access it.”
   • [claimed-docs] “use the [password protection](/docs/uptime/password-protected-status-page/) to only allow chosen people to access it.”
   • [claimed-docs] “An HTTP status code monitor checks your URLs every X seconds for an HTTP success status code (2XX). If the URL doesn't return this code, the…”
   • [claimed-docs] “we will create a monitor based on an HTTP status code and set up basic alerting, in case there is an incident.”

   proof ↗⚑ flag