incident.io vs Rootly

Agent access

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullprobed9/10

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

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

   proof ↗⚑ flag

5. ai-native userUse an official CLI

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

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

   ⚑ flag

   Rootly—none0/10

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

   ⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialprobed5/10

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

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

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

   ⚑ flag

Agentic features

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullprobed7/10

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

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

   proof ↗⚑ flag

Api quality

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

   ⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Agent ops

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

Ai investigation

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

Ai summaries

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Escalation

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Noise reduction

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Paging

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

Routing

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed9/10

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

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

   proof ↗⚑ flag

Metrics

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

   ⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Runbooks

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

Workflows

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Communications

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Coordination

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

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

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

   ⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Declaration

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Timeline

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Alert sources

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Workflow tools

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

Mobile

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed3/10

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

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

   proof ↗⚑ flag

Quality of life

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

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

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

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

   proof ↗⚑ flag

   Rootly—none0/10

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

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

   proof ↗⚑ flag

Schedules

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

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

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   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

Follow ups

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed5/10

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

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

   proof ↗⚑ flag

Postmortems

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

   weight 3 · round to Rootly
   incident.io~partialclaimed7/10

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

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

   proof ↗⚑ flag

   Rootly✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

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

   ⚑ flag

   Rootly—none0/10

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

   ⚑ flag

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

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

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

   ⚑ flag

   Rootly—none0/10

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

   ⚑ flag

3. ai-native userControl data retention and deletion

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

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

   ⚑ flag

   Rootly—none0/10

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

   ⚑ flag

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

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

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

   ⚑ flag

   Rootly—none0/10

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

   ⚑ flag

Status pages

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

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

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

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

   proof ↗⚑ flag

   Rootly~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   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