Rootly vs Better Stack

Agent access

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

   weight 2 · round to Rootly
   Rootly✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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 to Rootly
   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

   ⚑ flag

   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
   Rootly✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly~partialprobed5/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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 drawn
   Rootly—none0/10

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

   ⚑ flag

   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 drawn
   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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 to Rootly
   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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
   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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 drawn
   Rootly✓fullprobed7/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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
   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

   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
   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 to Rootly
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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 to Rootly
   Rootly✓fullclaimed9/10

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

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

   proof ↗⚑ flag

   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 drawn
   Rootly—none0/10

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

   ⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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 drawn
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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 to Rootly
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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
   Rootly~partialclaimed3/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

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

   proof ↗⚑ flag

   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
   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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 Rootly
   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Rootly—none0/10

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

   ⚑ flag

   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 drawn
   Rootly—none0/10

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

   ⚑ flag

   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
   Rootly—none0/10

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

   ⚑ flag

   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
   Rootly—none0/10

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

   ⚑ flag

   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
   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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
   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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