incident.io vs Better Stack

Agent access

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

   weight 2 · round to incident.io
   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

   Better Stack~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Better Stack✓fullclaimed7/10

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

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

   proof ↗⚑ flag

5. ai-native userUse an official CLI

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

   Better Stack—none0/10

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

   ⚑ flag

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

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

   Better Stack✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack~partialclaimed3/10

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

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

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

Agentic features

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

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

   Better Stack✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Api quality

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

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

Agent ops

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

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

   Better Stack~partialprobed6/10

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

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

   proof ↗⚑ flag

Ai investigation

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

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

   Better Stack✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Ai summaries

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

   weight 2 · round to incident.io
   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

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Better Stack~partialclaimed5/10

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

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

   proof ↗⚑ flag

Escalation

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

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

   Better Stack✓fullclaimed9/10

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

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

   proof ↗⚑ flag

Noise reduction

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

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

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

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

   proof ↗⚑ flag

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

Paging

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

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

   Better Stack✓fullclaimed9/10

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

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

   proof ↗⚑ flag

Routing

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

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

   Better Stack✓fullprobed8/10

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

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

   proof ↗⚑ flag

Metrics

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

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

   Better Stack—none0/10

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

   ⚑ flag

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

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack~partialclaimed7/10

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

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

Runbooks

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

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

   Better Stack~partialclaimed4/10

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

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

   proof ↗⚑ flag

Workflows

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

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

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

Communications

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

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

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

Coordination

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

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

Declaration

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

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

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

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

   proof ↗⚑ flag

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

Timeline

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

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

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

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

   proof ↗⚑ flag

   Better Stack~partialclaimed5/10

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

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

   proof ↗⚑ flag

Alert sources

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

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

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

Workflow tools

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

   weight 2 · round to incident.io
   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

   Better Stack~partialclaimed4/10

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

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

   proof ↗⚑ flag

Mobile

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

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

   Better Stack~partialclaimed5/10

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

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

   proof ↗⚑ flag

Quality of life

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

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

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

Schedules

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

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

   Better Stack~partialclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to incident.io
   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

   Better Stack~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

Follow ups

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

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

   Better Stack~partialclaimed5/10

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

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

   proof ↗⚑ flag

Postmortems

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

   weight 3 · round to incident.io
   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

   Better Stack~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack—none0/10

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

   ⚑ flag

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

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

   Better Stack—none0/10

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

   ⚑ flag

3. ai-native userControl data retention and deletion

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

   Better Stack—none0/10

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

   ⚑ flag

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

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

   Better Stack—none0/10

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

   ⚑ flag

Status pages

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

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

   Better Stack✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Better Stack✓fullclaimed9/10

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

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

   proof ↗⚑ flag