PagerDuty vs Better Stack

Agent access

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

   weight 2 · round to PagerDuty
   PagerDuty✓fullprobed8/10

   A live probe confirms PagerDuty serves an actual llms.txt at support.pagerduty.com/llms.txt (HTTP 200) with structured knowledge-base content, and PagerDuty separately documents an official MCP server (local and hosted, verified live via runtime probe) enabling agent-native integration. Missing for 10: llms.txt coverage of developer/API docs specifically (only support KB confirmed) and independent hands-on confirmation that agents parse it effectively.

   • [probe] “PROBE llms.txt: HTTP 200 at https://support.pagerduty.com/llms.txt # Knowledge Base Documentation > Get help with configuring your account …”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”

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

   PagerDuty exposes a fully headless REST API, async Events API v2, webhooks, and Incident Workflows, all confirmed live via runtime probes (400/401 structured responses), enabling CI/automation pipelines to trigger, manage, and orchestrate incidents without any UI. missing for 10: no first-party CLI tool explicitly marketed for CI pipelines, and no independent case study of running PagerDuty automation fully headless in a CI system.

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”

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

   All MCP-related evidence describes PagerDuty publishing its own MCP server (server role) so external AI clients can call PagerDuty's tools (pagerduty-docs-1, pagerduty-docs-14, pagerduty-docs-34, pagerduty-probe-2, pagerduty-probe-rt-1) — there is no evidence that PagerDuty itself, or its agentic features like PagerDuty Advance/SRE Agent, can act as an MCP client and plug in external MCP servers to use their tools. Since PagerDuty is a SaaS platform with agentic AI capabilities, this client-side capability is a fair question, but no evidence supports it.

   • [claimed-docs] “provides tools to interact with your PagerDuty account directly from your MCP-enabled client”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”

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

   PagerDuty ships an official documented MCP server (both local GitHub package and hosted remote endpoint at mcp.pagerduty.com), confirmed live via runtime probe returning expected OAuth/Bearer auth challenge, matching official docs. missing for 10: independent third-party hands-on review of the MCP server's tool coverage beyond vendor docs.

   • [claimed-docs] “provides tools to interact with your PagerDuty account directly from your MCP-enabled client”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”

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

   The evidence pack documents PagerDuty's REST API, Events API, webhooks, and an official MCP server, but no official CLI tool for AI-native workflows is mentioned anywhere in the docs or community sources.

   ⚑ 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 to PagerDuty
   PagerDuty✓fullprobed9/10

   PagerDuty publishes a well-documented REST API, Events API v2, V3 webhooks, and an official MCP server, all confirmed live via runtime probes (401 auth challenge on MCP endpoint, structured validation errors on Events API), demonstrating genuine programmatic access beyond marketing claims. missing for 10: independent third-party developer testimonials specifically praising API completeness/documentation quality beyond PagerDuty's own docs.

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”

   proof ↗⚑ flag

   Better Stack✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to PagerDuty
   PagerDuty~partialprobed4/10

   PagerDuty's official MCP server and REST API require API-token or OAuth authentication (pagerduty-probe-rt-1, pagerduty-docs-32/39/44), which implies some credential-based access control an agent could use, but the evidence never describes granular scopes, roles, or least-privilege permission tiers specifically for AI-agent credentials. Missing for 10: explicit documentation of scoped/role-based API keys or OAuth scopes for agent use, any read-only vs write-restricted key options, and confirmation these can be issued distinctly per-agent.

   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”

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

   PagerDuty provides multiple official developer surfaces — REST API, Events API v2, v3 webhooks, and an official (and now hosted/remote, OAuth-protected) MCP server — all documented on developer.pagerduty.com and confirmed live via runtime probes, which is exactly the kind of programmatic surface an AI-native builder would target. Missing for 10: explicit named official client-library SDKs in multiple languages (e.g., Python/Node SDK packages) beyond the REST/Events APIs, and independent hands-on developer corroboration of SDK ergonomics.

   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”

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

   PagerDuty's developer docs describe V3 webhooks as a first-class subscription mechanism for incident/priority/responder change events, and the Events API v2 (confirmed live via runtime probe) provides the complementary ingestion side, giving AI-native integrators a documented way to subscribe to and consume PagerDuty events. Missing for 10: independent/hands-on confirmation of webhook subscription setup and payload handling, and no direct linkage of webhooks specifically to AI-agent workflows.

   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks. When compared with previous versions, they provide additional event…”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”

   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 Better Stack
   PagerDuty~partialclaimed6/10

   PagerDuty Advance and its components (Scribe Agent for post-incident reviews, SRE Agent, Intelligent Alert Grouping via ML, AIOps insights claiming 91% alert reduction) provide AI-generated insights and suggestions embedded in the product, going beyond mere automation. However, evidence is largely first-party marketing copy with no independent/hands-on validation of insight quality, and community feedback is silent on these newer AI features (mostly discussing core paging/escalation). Missing for 10: independent verification of AI-generated insight quality, concrete examples of suggestions surfaced in-product, and community corroboration of the AI/Advance features specifically.

   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty AIOps slashes alerts by 91%, automates repetitive work, and accelerates resolution”
   • [claimed-docs] “Intelligent Alert Grouping automatically consolidates related alerts into a single, actionable incident, using machine learning to reduce al…”

   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 PagerDuty
   PagerDuty~partialcommunity7/10

   PagerDuty provides multiple background-automation mechanisms that run without manual triggering: Incident Workflows auto-fire on conditions (e.g., all P1/P2 incidents), Escalation Policies auto-escalate, Event Orchestration auto-dedupes/suppresses alerts, and PagerDuty Advance/SRE Agent is explicitly marketed as an agentic AI that 'handles incidents and fixes' autonomously while a human 'steps in when it matters.' This directly matches the ask of autonomous background automation. Missing for 10: independent/hands-on validation that the SRE Agent or Advance features actually operate unattended in production (community evidence is about legacy escalation/paging behavior, not the newer agentic AI layer), and no user testimonials confirming trust in fully autonomous incident resolution.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

   proof ↗⚑ flag

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Better Stack
   PagerDuty~partialclaimed6/10

   PagerDuty Advance embeds agentic AI directly in the product — the SRE Agent handles incidents/fixes and the Scribe Agent assists Post-Incident Reviews, both described as built-in assistants a user can delegate tasks to. However, this is marketing/first-party documentation only, with no independent or hands-on confirmation of how well delegation actually works in practice. Missing for 10: independent/hands-on validation of the SRE Agent or Scribe Agent in real use, and clarity on availability/tier restrictions for PagerDuty Advance.

   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”

   proof ↗⚑ flag

   Better Stack✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   PagerDuty✓fullprobed7/10

   PagerDuty ships an official local and hosted MCP server (verified live via probe returning correct auth challenge) that exposes PagerDuty's incident/on-call tools to any MCP-enabled client, letting AI-native users issue natural-language commands (e.g., via Slack, IDE, or LLM assistants) to trigger/ack/resolve incidents and manage on-call data. This is reinforced by PagerDuty Advance and SRE Agent messaging around agentic/generative AI operating the platform. Missing for 10: no first-party native chat/NL interface within the PagerDuty product itself (reliant on external MCP clients) and no independent hands-on account of a user issuing NL commands end-to-end.

   • [claimed-docs] “provides tools to interact with your PagerDuty account directly from your MCP-enabled client”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”

   proof ↗⚑ flag

   Better Stack✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   PagerDuty—none0/10

   Evidence shows PagerDuty publishes REST/Events API overviews and developer docs (e.g. pagerduty-docs-31/32/33/39), but nothing describes an interactive API reference with runnable/try-it examples akin to a Swagger/OpenAPI explorer or code sandbox. This is a fair axis for a product with a public developer API, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”

   proof ↗⚑ flag

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   PagerDuty—none0/10

   The evidence pack documents PagerDuty's REST API, Events API v2, and webhooks overviews, but none of the citations mention an OpenAPI/Swagger spec or any downloadable machine-readable API definition file. Missing for 10: explicit OpenAPI/Swagger spec file or reference, developer portal spec download link, schema versioning info.

   ⚑ 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 PagerDuty
   PagerDuty~partialcommunity5/10

   PagerDuty's developer docs show clear API versioning (REST API, Events API v2, webhooks v3) with dedicated overview pages, and probes confirm live, self-describing endpoints — but no evidence pack item states an explicit deprecation policy or sunset timeline for older versions. A dated community report also describes real confusion around distinguishing v1 vs v2 event API keys and an unhelpful support response, undercutting confidence that versioning transitions are cleanly documented in practice. Missing for 10: an explicit published deprecation/sunset policy document, and independent confirmation that version transitions are smooth rather than confusing.

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks. When compared with previous versions, they provide additional event…”
   • [community] “I run a service that integrates with pager duty... they have two versions of their event API, and keys for the v1 API don't work with v2 and…”

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

   PagerDuty ships an official local and hosted remote MCP server (verified live via runtime probe requiring only API-token/OAuth auth, no dashboard) plus a documented REST/Events API that lets integrations trigger, acknowledge, and resolve incidents, with escalation policies automating assignment without human/dashboard intervention. Independent probes confirm both the MCP endpoint and Events API v2 are functioning, self-describing endpoints, corroborating vendor docs claims. Missing for 10: explicit API/MCP documentation of an 'escalate' action being callable directly (escalation is largely policy-driven rather than an explicit agent-triggered API call), and no independent hands-on account of an agent performing the full ack→escalate→resolve loop end to end.

   • [claimed-docs] “provides tools to interact with your PagerDuty account directly from your MCP-enabled client”
   • [claimed-docs] “PagerDuty's official local MCP (Model Context Protocol) server which provides tools to interact with your PagerDuty account directly from yo…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [claimed-docs] “Trigger, acknowledge, and resolve incidents created by service integrations.”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”

   proof ↗⚑ flag

   Better Stack~partialprobed6/10

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

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

   proof ↗⚑ flag

Ai investigation

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

   weight 2 · round to Better Stack
   PagerDuty~partialclaimed5/10

   PagerDuty Advance and the SRE Agent are marketed as agentic AI that 'handles incidents and fixes' and Intelligent Alert Grouping/AIOps use ML to reduce noise, suggesting some proactive investigative capability, but the evidence never describes the agent correlating changes, telemetry, and similar past incidents into a probable-cause narrative before a human asks. Post-Incident Review's Scribe Agent builds narratives, but only after/during incident lifecycle, not as a proactive pre-emptive root-cause investigator. Missing for 10: concrete description of autonomous correlation of deploy/change events + telemetry + historical incident similarity, and evidence of it surfacing findings unprompted.

   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty AIOps slashes alerts by 91%, automates repetitive work, and accelerates resolution”
   • [claimed-docs] “Intelligent Alert Grouping automatically consolidates related alerts into a single, actionable incident, using machine learning to reduce al…”

   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 PagerDuty
   PagerDuty~partialclaimed7/10

   PagerDuty's Post-Incident Reviews feature explicitly integrates with the PagerDuty Advance Scribe Agent to auto-build chronological incident narratives, uncover systemic patterns, and coordinate preventative follow-up actions — matching the AI-drafted timeline/contributing-factors/follow-ups story closely. Missing for 10: explicit documentation of 'human review' framing/draft-approval workflow, explicit mention of 'contributing factors' as a distinct output field, and any independent/hands-on confirmation of the Scribe Agent's output quality.

   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”

   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 PagerDuty
   PagerDuty~partialclaimed7/10

   PagerDuty Advance's generative AI explicitly summarizes incidents and the Scribe Agent builds chronological incident narratives from Slack/incident data, directly matching 'AI writes the incident as it happens' and 'scribed call notes' (pagerduty-docs-23, pagerduty-docs-26, pagerduty-docs-38). However, the Scribe Agent is documented as tied to Post-Incident Reviews (after resolution) rather than clearly live/real-time during the call, and there's no explicit evidence of AI auto-drafting status-page updates in real time. Missing for 10: clear documentation that summaries/notes are generated live during an active incident (not just post-incident), and evidence of AI-drafted stakeholder updates during the incident itself.

   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “SRE Agent handles incidents and fixes. You step in when it matters.”

   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
   PagerDuty✓fullcommunity8/10

   Docs explicitly describe escalation policies that notify a single target until acknowledged, with multi-level steps connecting to schedules and users, and incidents escalating per the policy automatically; a first-hand community report confirms it works as designed in practice (notify app, then call after a delay if unacknowledged). missing for 10: no explicit documentation of repeating the full escalation cycle multiple times or granular fallback-responder configuration details beyond general escalation-level language.

   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “The incident escalates in accordance with the service's escalation policy.”
   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

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

   PagerDuty documents native dedup via `dedup_key` on Events API integrations, Event Orchestration to automatically deduplicate/suppress alerts, and Intelligent Alert Grouping using ML to consolidate related alerts into a single actionable incident specifically to reduce alert noise for SREs; escalation policies then notify a single target at a time until acknowledged, matching 'one incident pages one human.' Runtime probe confirms the Events API is live and enforces routing/event fields, corroborating the dedup mechanism is real and functioning. Missing for 10: independent/hands-on evidence quantifying grouping accuracy or false-negative rates beyond vendor claims.

   • [claimed-docs] “Services with Events API integrations deduplicate alerts with matching `dedup_key` values.”
   • [claimed-docs] “Intelligent Alert Grouping automatically consolidates related alerts into a single, actionable incident, using machine learning to reduce al…”
   • [claimed-docs] “Intelligent Alert Grouping automatically consolidates related alerts into a single, actionable incident, using machine learning to reduce al…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”

   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
   PagerDuty~partialcommunity6/10

   PagerDuty's docs confirm on-call notification rules and readiness reports tied to responder notification configurations, mobile app for push, and escalation policies with schedules controlling who is notified; a hands-on account also confirms app-then-phone-call escalation in practice. However, no evidence explicitly enumerates SMS, phone call, and email as configurable per-channel notification rule options together, so full breadth of channel choice isn't directly documented in this pack. Missing for 10: explicit documentation naming SMS/email/push/phone as selectable channels with per-channel ordering, and independent confirmation of all four channel types working.

   • [claimed-docs] “On-Call Readiness Reports help organizations improve incident response quality by ensuring responders have optimal notification rule configu…”
   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “The PagerDuty mobile app allows you to respond to incidents, view account objects, and manage settings on the go, wherever you are.”
   • [claimed-docs] “Every report provides a Team-filtered overview of each responder's on-call readiness status”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

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

   PagerDuty documents Events API v2 as a reliable, self-describing ingestion endpoint for monitoring alerts (confirmed live via runtime probe), plus Event Orchestration for condition-based routing/deduplication and Escalation Policies to route to the right team/individual per configurable rules. This directly matches the story of documented ingestion sources routed by defined conditions to the correct team. missing for 10: independent hands-on validation of complex routing/orchestration setups (community evidence only covers general escalation behavior and unrelated API versioning friction, not routing-condition failures).

   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “Trigger, acknowledge, and resolve incidents created by service integrations.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

   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 PagerDuty
   PagerDuty~partialclaimed4/10

   PagerDuty documents On-Call Readiness Reports (responder notification health) and Post-Incident Reviews (systemic pattern uncovering), which touch parts of 'on-call health' and post-incident learning, but no evidence explicitly describes MTTA/MTTR trend dashboards or incident-load analytics over time for leadership reporting. Missing for 10: explicit MTTA/MTTR trend reporting, incident load/volume analytics dashboards, and any leadership-facing 'are we improving' trend view.

   • [claimed-docs] “On-Call Readiness Reports help organizations improve incident response quality by ensuring responders have optimal notification rule configu…”
   • [claimed-docs] “On-Call Readiness Reports help organizations improve incident response quality by ensuring responders have optimal notification rule configu…”
   • [claimed-docs] “Every report provides a Team-filtered overview of each responder's on-call readiness status”
   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”
   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”

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

   PagerDuty exposes a REST API and MCP server that could be scripted to act on many items, and it explicitly supports bulk CSV user import, but there is no documented dedicated bulk-operations endpoint (e.g., bulk acknowledge/resolve many incidents in one call) or MCP tool description for batch actions across incidents/services. Missing for 10: explicit bulk incident/alert operation API or MCP tool documentation, and any hands-on evidence of performing large-scale bulk actions via AI-native tooling.

   • [claimed-docs] “Import Users from a CSV”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”

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

   PagerDuty's Incident Workflows and Event Orchestration explicitly support configurable 'if-this-then-that' triggers/actions on incidents and events (auto-trigger for P1/P2, dedup/suppress alerts, escalation policies notifying on-call chains), and this automation is exposed via Events API, REST API, webhooks, and an official MCP server for AI-agent integration. Community evidence corroborates escalation policies working reliably in practice (comm-1), though some report friction with configuration and API versioning (comm-4, comm-6). Missing for 10: independent hands-on validation specifically of Incident Workflow/Orchestration rule automation (vs. just escalation) and confirmation that AI agents can programmatically define these rules via MCP rather than just fetch/manage data.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”

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

   PagerDuty's automation features (Incident Workflows, escalation policies) are event-triggered by incident conditions, not time-based recurring job/workflow scheduling; the on-call 'Schedules' evidence (pagerduty-docs-12) covers staff rotation, not scheduled automation jobs. No evidence shows a mechanism for an AI-native user to schedule recurring automated workflows via API or MCP.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident... you can apply "if-this-then-that" logic to orchestrate the…”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”

   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 PagerDuty
   PagerDuty~partialclaimed7/10

   PagerDuty's Incident Workflows explicitly support automated, triggerable 'if-this-then-that' responses attached to incidents (e.g., auto-trigger for P1/P2 incidents), which functionally matches the runbook-automation story, and Advance/agentic features add AI-driven remediation. However, the evidence never uses the term 'runbook' nor cites concrete step examples like auto-creating chat channels or running diagnostics scripts as named actions. Missing for 10: explicit runbook terminology, named step types (channel creation, task assignment, diagnostics execution), and independent/hands-on confirmation of these specific triggered actions.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident... you can apply "if-this-then-that" logic to orchestrate the…”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”
   • [claimed-docs] “PagerDuty Advance is a set of generative and agentic AI capabilities embedded across the PagerDuty Operations Cloud that allows organization…”
   • [claimed-docs] “From AI agents handling well-understood tasks to generative AI for summarizing key information about an incident, PagerDuty Advance augments…”

   proof ↗⚑ flag

   Better Stack~partialclaimed4/10

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

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

   proof ↗⚑ flag

Workflows

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

   weight 2 · round to PagerDuty
   PagerDuty✓fullclaimed7/10

   PagerDuty Incident Workflows are explicitly documented as a condition-based automation engine using 'if-this-then-that' logic that triggers automated actions (e.g., field changes, notifications, reminders) based on incident event conditions like P1/P2 severity. Escalation policies and event orchestration further automate incident-response toil (assignment, deduplication, escalation) without manual intervention. Missing for 10: independent/hands-on corroboration of Incident Workflows specifically (community evidence discusses escalation and paging generally but not the workflow engine), and detailed examples of field-change/reminder automation beyond marketing-style docs.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident... you can apply "if-this-then-that" logic to orchestrate the…”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”
   • [claimed-docs] “The incident escalates in accordance with the service's escalation policy.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”

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

   PagerDuty Status Pages give stakeholders visual, real-time updates on incident status 'without context switching to other tools,' and Incident Workflows/Post-Incident Reviews can push structured summaries, all without requiring war-room participation. However, the evidence never explicitly confirms a subscription/notification mechanism for external stakeholders or a dedicated 'structured update' template feature. Missing for 10: explicit subscribe/follow functionality for status pages, dedicated stakeholder-update templates, and independent confirmation that non-responders actually use this instead of joining incident channels.

   • [claimed-docs] “PagerDuty Status Pages provide visual, real-time insights into an organization's operations, and the status of incident resolution.”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools, giving user…”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools.”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”

   proof ↗⚑ flag

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

Coordination

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

   weight 1 · round to PagerDuty
   PagerDuty~partialclaimed4/10

   PagerDuty's Incident Workflows and Escalation Policies show automated, rule-based assignment and orchestration of incident response tasks, which speaks to coordinated response, but no evidence explicitly describes named incident roles like 'commander' or 'comms lead' or human-facing task checklists for responders. missing for 10: explicit incident commander/communications lead role definitions, structured task checklists per role, and any hands-on validation that these roles function as intended under pressure.

   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident.”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams”
   • [claimed-docs] “Through highly-configurable triggers and actions, you can apply "if-this-then-that" logic to orchestrate the right response for your teams, …”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [claimed-docs] “Incident Workflows allow you to build an automated response for every incident. For example, you can configure one workflow that automatical…”

   proof ↗⚑ flag

   Better Stack—none0/10

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

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

   proof ↗⚑ flag

Declaration

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

   weight 3 · round to Better Stack
   PagerDuty~partialclaimed3/10

   PagerDuty's own marketing states you can 'manage incidents and coordinate response from Slack' (pagerduty-docs-2), and Post-Incident Reviews integrate with Slack data (pagerduty-docs-23/38), indicating some Slack tie-in, but there is no documented capability for declaring an incident directly from a Slack/Teams command with automatic channel creation, role assignment, and status updates. Missing for 10: explicit ChatOps slash-command/incident-declaration workflow docs, Teams support, evidence of auto-created channels and role assignment from chat, and any independent confirmation of this specific flow.

   • [claimed-docs] “Manage incidents and coordinate response from Slack or your IDE.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”

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

   PagerDuty's Post-Incident Reviews integrate with the incident lifecycle and Slack data (via the Scribe Agent) to automatically build 'chronological incident narratives,' which is evidence of automated timeline capture of alerts/actions/chat, and PIRs function as editable review documents. However, there's no explicit evidence of a dedicated incident timeline UI feature, nor documentation confirming that responders can directly edit or annotate the captured timeline entries after the fact. Missing for 10: explicit incident timeline/log feature docs, confirmation of manual editing/annotation of timeline entries, and independent corroboration of automatic chat-decision capture accuracy.

   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”

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

   The evidence pack documents generic integration mechanisms (Events API v2, REST API, webhooks, service integrations) but never names or links documented setup guides for the specific tools cited in the story—Datadog, Grafana, Prometheus, CloudWatch, or Sentry—so there is no evidence of first-party, per-tool documented integrations for this observability stack.

   • [claimed-docs] “Services with Events API integrations deduplicate alerts with matching `dedup_key` values.”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “Event Orchestration: Automatically deduplicate or suppress alerts.”

   proof ↗⚑ flag

   Better Stack~partialclaimed6/10

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

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

   proof ↗⚑ flag

Workflow tools

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

   weight 2 · round to PagerDuty
   PagerDuty~partialclaimed5/10

   PagerDuty documents strong two-way integration infrastructure (REST API, Events API, V3 webhooks, MCP server) and explicitly calls out Slack integration for incident response and Post-Incident Reviews pulling in Slack data, but the evidence pack never names Jira, Teams, Zoom, or GitHub as specific bidirectional integrations — only Slack is concretely evidenced. Missing for 10: explicit documented integrations/state-sync with Jira, Microsoft Teams, Zoom, and GitHub specifically, plus confirmation these flow both ways rather than just PagerDuty→tool notifications.

   • [claimed-docs] “Manage incidents and coordinate response from Slack or your IDE.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks. When compared with previous versions, they provide additional event…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”

   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 PagerDuty
   PagerDuty~partialcommunity6/10

   PagerDuty's mobile app docs confirm responding to incidents, viewing objects, and managing settings on the go, and community evidence confirms the app is used for acknowledging pages and is core to escalation flow. However, the evidence doesn't explicitly confirm resolve/escalate actions from the app specifically (only 'respond to incidents' generally) and one community comment notes engineers 'only use the app for ack'ing the page,' suggesting other actions may be underused or less central. missing for 10: explicit documentation/hands-on confirmation of resolving and manually escalating incidents (not just acknowledging) from the mobile app, and independent third-party mobile UX reviews.

   • [claimed-docs] “The PagerDuty mobile app allows you to respond to incidents, view account objects, and manage settings on the go, wherever you are.”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”
   • [community] “PagerDuty is super expensive. A lot of the bells and whistles they have aren't useful. Engineers never need to actually use the PagerDuty we…”

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

   The evidence pack covers schedules, escalation policies, and mobile app notifications but contains no mention of an iCal/calendar feed or personal calendar sync capability for on-call shifts.

   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [claimed-docs] “The PagerDuty mobile app allows you to respond to incidents, view account objects, and manage settings on the go, wherever you are.”

   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
   PagerDuty~partialcommunity4/10

   Docs confirm schedules exist to map coverage needs (pagerduty-docs-12) and escalation policies connect services to users/schedules (pagerduty-docs-7/37), but no evidence explicitly documents layers, rotations, round-robin coverage, or time-zone handling within schedules, and community feedback flags 'clunky calendar overrides' (pagerduty-comm-4) as a friction point. Missing for 10: explicit documentation of schedule layers, rotation types, round-robin distribution, and time-zone-aware scheduling, plus hands-on confirmation these work smoothly.

   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules. They are designed to notify a si…”
   • [community] “None of them have SCIM integration to make managing your teams automatic. All of them have clunky calendar overrides. For PagerDuty you need…”
   • [community] “Pagerduty handles escalation very well. If you have the app it will first try to notify through the app. If there is no ack within a couple …”

   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
   PagerDuty~partialcommunity3/10

   PagerDuty's schedule docs describe mapping coverage needs (docs-12) and escalation policies tied to schedules (docs-7), and a community comment confirms that calendar overrides exist in the product (comm-4), but no evidence details a self-service flow for taking an override, swapping a shift, or requesting coverage without admin involvement — the same community comment actually calls overrides 'clunky,' undercutting a smooth self-service experience. Missing for 10: first-party docs on override/shift-swap UI or API, evidence of coverage-request workflow, and confirmation these actions require no admin intervention.

   • [claimed-docs] “Use legacy schedules to map your coverage needs and determine who receives a notification when an incident triggers.”
   • [claimed-docs] “Escalation policies automate incident assignment and connect services to individual users and/or schedules.”
   • [community] “None of them have SCIM integration to make managing your teams automatic. All of them have clunky calendar overrides. For PagerDuty you need…”

   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 PagerDuty
   PagerDuty~partialprobed7/10

   PagerDuty documents a broad REST API for configuration/user/workflow management, an Events API v2, V3 webhooks, and an official MCP server (with a live hosted endpoint) letting AI clients trigger/manage incidents, confirming strong API-driven parity with UI actions. However, no evidence explicitly confirms 100% feature parity between API and UI, and community comments note at least one case (OIDC/Azure AD SSO config) requiring manual support intervention outside normal UI/API self-service, suggesting some settings aren't fully API/UI accessible. Missing for 10: an explicit parity statement or audit showing all UI functions are API-exposed, and independent verification beyond vendor docs.

   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [claimed-docs] “The Events API v2 is a highly reliable, highly available **asynchronous API** that ingests machine events from monitoring tools and other sy…”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”
   • [claimed-docs] “PagerDuty's MCP server allows you to fetch and manage information in your PagerDuty account.”
   • [probe] “official MCP server documented at https://developer.pagerduty.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): PagerDuty's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.pagerd…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the Events API v2 ingestion endpoint is live and self-describing — a keyless empty POST to https://even…”
   • [community] “None of them have SCIM integration to make managing your teams automatic. All of them have clunky calendar overrides. For PagerDuty you need…”

   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 PagerDuty
   PagerDuty~partialclaimed4/10

   PagerDuty's REST API exposes configuration and incident data programmatically (docs-32, docs-39, docs-44), which a technically capable user could use to pull out their data, but there is no documented bulk 'export all my data' feature, data-portability tool, or GDPR-style export mechanism in open formats. Missing for 10: an explicit account-wide export/backup feature, documentation of supported open export formats (CSV/JSON dump), and confirmation that all data types (incidents, schedules, users, workflows) can be fully extracted and are portable to another system.

   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “Using the REST API, you can do things like: - add and configure users on a PagerDuty account, including how they're notified by PagerDuty - …”
   • [claimed-docs] “add and configure users on a PagerDuty account, including how they're notified by PagerDuty - set up workflows for responding to incidents -…”
   • [claimed-docs] “Import Users from a CSV”

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

   Post-Incident Reviews explicitly state they 'coordinate preventative follow-up actions' and integrate with incident lifecycle data (docs-36, docs-38, docs-23), showing PagerDuty tracks follow-up items generated from postmortems. However, no evidence documents a native or documented sync of these action items into an external issue tracker (Jira, Linear, etc.) or shows tracking-to-completion status/reporting; REST API/webhooks (docs-32, docs-33) could technically enable such integration but this is not demonstrated for follow-up actions specifically. Missing for 10: explicit issue-tracker sync documentation for post-incident follow-up items, evidence of completion-status tracking/reporting on these actions.

   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “The REST API provides a way for third parties to connect to a PagerDuty account and access or manipulate configuration data on that account.”
   • [claimed-docs] “V3 webhooks provide the foundation for the future of PagerDuty webhooks... they provide additional event types to signal changes to incident…”

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

   PagerDuty's Post-Incident Reviews (formerly Jeli PIR) integrate with the incident lifecycle and Slack data, and the PagerDuty Advance Scribe Agent helps 'build chronological incident narratives' and 'coordinate preventative follow-up actions,' which covers timeline-based drafting and some learning workflow. However, there is no explicit documentation of templates, a distinct review/approval step, or a publication mechanism for postmortems. missing for 10: named postmortem templates, explicit review/approval workflow, publication/sharing step, and independent corroboration of the drafting experience.

   • [claimed-docs] “PagerDuty Post-Incident Reviews ... allow you to turn incidents into learning opportunities.”
   • [claimed-docs] “PagerDuty Post-Incident Reviews (formerly Jeli Post-Incident Reviews) allow you to turn incidents into learning opportunities.”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”
   • [claimed-docs] “Post-Incident Reviews... help your team uncover systemic patterns, build chronological incident narratives, and coordinate preventative foll…”
   • [claimed-docs] “Post-Incident Reviews integrate with your incident lifecycle, Slack data, and the PagerDuty Advance Scribe Agent to help your team uncover s…”

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

   No evidence in the pack addresses data residency, regional data storage, or the ability to choose where account/data is hosted for PagerDuty. Missing for 10: any mention of regional data centers, EU/US data residency options, or configurable data-storage location.

   ⚑ flag

   Better Stack—none0/10

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

   ⚑ flag

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

   weight 3 · round drawn
   PagerDuty—none0/10

   No evidence pack item addresses AI training data usage, opt-out controls, or any privacy policy statement about model training on customer data; PagerDuty Advance and MCP references describe AI features, not data-training privacy 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
   PagerDuty—none0/10

   The evidence pack covers MCP server access, incident workflows, alert grouping, and AI features (PagerDuty Advance), but contains no documentation on data retention policies, deletion controls, or data lifecycle management for AI-native users. Missing for 10: any retention policy documentation, data deletion/export mechanisms, or configurable retention windows relevant to AI-ingested incident data.

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

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings for PagerDuty or its AI features (MCP server, Advance); this is an applicable privacy-posture axis for an AI-native user but no documentation or community evidence confirms such a control exists. Missing for 10: any privacy policy or settings page describing telemetry collection and an opt-out mechanism.

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

   PagerDuty Status Pages are documented as a general capability for real-time operational updates, but no evidence describes private/internal-only pages, audience-specific access control, or separate customer vs employee-only views.

   • [claimed-docs] “PagerDuty Status Pages provide visual, real-time insights into an organization's operations, and the status of incident resolution.”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools, giving user…”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools.”

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

   PagerDuty ships a dedicated Status Pages product that is explicitly driven from incident state and lets teams communicate real-time operational updates without leaving PagerDuty (pagerduty-docs-10, pagerduty-docs-17, pagerduty-docs-24). However, the evidence never confirms custom-domain hosting or subscriber notification/opt-in mechanics for the status page. Missing for 10: explicit documentation of custom domain support, subscriber sign-up/notification delivery, and any independent/hands-on confirmation of these specific features.

   • [claimed-docs] “PagerDuty Status Pages provide visual, real-time insights into an organization's operations, and the status of incident resolution.”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools, giving user…”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools”
   • [claimed-docs] “PagerDuty users can proactively and securely communicate real-time operational updates without context switching to other tools.”

   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