Honeybadger vs Raygun

Agent access

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

   weight 2 · round to Honeybadger
   Honeybadger✓fullprobed8/10

   Honeybadger has a confirmed llms.txt endpoint (HTTP 200) plus dedicated _llms-txt reference docs (product-reference.txt, insights-reference.txt, other-reference.txt) that an agent can be pointed at, and also offers a documented MCP server as an agent-facing integration. missing for 10: independent/hands-on confirmation that an agent actually consumes llms.txt successfully, and no discoverable machine-readable OpenAPI spec to complement it.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.honeybadger.io/llms.txt # Honeybadger.io > Honeybadger provides error tracking, uptime monitoring,…”
   • [claimed-docs] “You can create additional accounts and switch between accounts using the dropdown in the navigation bar.”
   • [claimed-docs] “With it you can specify which fields you want to see, filter the kinds of events that should be returned, perform aggregations and calculati…”
   • [claimed-docs] “Report errors using our [exceptions API](/api/reporting-exceptions/)”
   • [probe] “official MCP server documented at https://docs.honeybadger.io/resources/mcp/”

   proof ↗⚑ flag

   Raygun—none0/10

   A direct probe confirms llms.txt returns 404, and no evidence mentions agent-oriented documentation formats for Raygun; the only agent-related evidence is an MCP server, which is a separate axis.

   • [probe] “PROBE llms.txt: HTTP 404 at https://raygun.com/llms.txt”

   proof ↗⚑ flag

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

   weight 2 · round to Honeybadger
   Honeybadger✓fullprobed6/10

   Honeybadger ships a CLI and REST API (e.g., `honeybadger deploy`, exceptions/deployments/source-map endpoints) explicitly designed for scripted, non-interactive use, which is exactly what's needed to invoke it headlessly from CI pipelines, and error/deploy tracking runs automatically once configured. Missing for 10: explicit CI/CD integration examples (e.g., GitHub Actions/GitLab CI snippets) and independent hands-on confirmation of CI usage.

   • [claimed-docs] “The Honeybadger CLI provides a Command Line Interface for various Honeybadger-related programs and utilities.”
   • [claimed-docs] “`honeybadger deploy` Notify Honeybadger of deployment”
   • [claimed-docs] “Use this endpoint to notify Honeybadger when a deploy occurs.”
   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “Once our client library is installed and configured, errors thrown by your application are automatically sent to our API.”
   • [probe] “official CLI documented at https://docs.honeybadger.io/lib/ruby/gem-reference/cli/”

   proof ↗⚑ flag

   Raygun~partialprobed4/10

   Raygun exposes an external access token used by CI/CD pipelines for the Deployments API, dSYM/ProGuard/JS source map uploads, which supports some headless automation in build pipelines, and an export API for CSV data. However there is no documented CLI, no evidence of a general headless SDK/runner for CI-based testing, and API/OpenAPI probes returned 404s. missing for 10: dedicated CLI or SDK for full headless CI operation, documented API reference beyond token-based uploads, independent evidence of CI usage.

   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “You'll need your external access token for the following services:”
   • [claimed-docs] “The Raygun Crash Reporting export feature allows customers to export all error groups or selected errors groups from within the Crash Report…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”

   proof ↗⚑ flag

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

   weight 3 · round to Honeybadger
   Honeybadger✓fullprobed9/10

   Honeybadger ships an official hosted MCP server (docs.honeybadger.io/resources/mcp/) that lets an AI assistant connect and gain project management, error investigation, and Insights/BadgerQL query capabilities, with OAuth-based connection flow documented in the changelog. This is first-party documentation of exactly the described capability, though missing for 10: independent/hands-on verification of the MCP server working in practice.

   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “Our hosted MCP server supports OAuth, so you can connect an agent by approving access in your browser instead of copying and pasting a crede…”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”
   • [probe] “official MCP server documented at https://docs.honeybadger.io/resources/mcp/”

   proof ↗⚑ flag

   Raygun~partialprobed5/10

   There is evidence of an official MCP server repo (MindscapeHQ/mcp-server-raygun) enabling agent connection, but no first-party documentation, setup guide, or independent corroboration confirming its official status or maturity. Missing for 10: first-party docs referencing the MCP server, usage/setup documentation, independent hands-on validation.

   • [probe] “official MCP server documented at https://github.com/MindscapeHQ/mcp-server-raygun”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Honeybadger
   Honeybadger✓fullprobed6/10

   Honeybadger ships an official CLI (Ruby gem) documented with commands like `honeybadger deploy` for notifying deployments and other utilities, confirmed by docs and probe. It exists as a first-party tool a script or AI agent could invoke, though it is narrow in scope (deployment notification, limited to Ruby ecosystem) and not marketed as AI-native. Missing for 10: broader multi-language CLI coverage, AI-specific CLI features/flags, and independent/hands-on confirmation of agentic usage.

   • [claimed-docs] “The Honeybadger CLI provides a Command Line Interface for various Honeybadger-related programs and utilities.”
   • [claimed-docs] “`honeybadger deploy` Notify Honeybadger of deployment”
   • [probe] “official CLI documented at https://docs.honeybadger.io/lib/ruby/gem-reference/cli/”

   proof ↗⚑ flag

   Raygun—none0/10

   No evidence of an official Raygun CLI tool for AI-native workflows; docs only mention API tokens, dashboard exports, and integrations, and probes show no CLI or openapi/llms.txt artifacts confirming CLI presence.

   ⚑ flag

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

   weight 3 · round to Honeybadger
   Honeybadger✓fullprobed8/10

   Honeybadger exposes a well-documented public REST API for reporting exceptions, source maps, deployments, and querying faults (docs-15,16,17,19,36), plus a CLI (docs-18,31) and MCP server (docs-13,30) enabling AI agents to interact with it programmatically. No formal OpenAPI/Swagger spec was found via probe, slightly limiting machine-readable discoverability. Missing for 10: a discoverable OpenAPI/Swagger spec and independent third-party confirmation of API robustness.

   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files. Use the Source Map …”
   • [claimed-docs] “Use this endpoint to notify Honeybadger when a deploy occurs.”
   • [claimed-docs] “Returns a list of faults or a single fault for the given project”
   • [claimed-docs] “The Honeybadger CLI provides a Command Line Interface for various Honeybadger-related programs and utilities.”
   • [claimed-docs] “`honeybadger deploy` Notify Honeybadger of deployment”
   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.honeybadger.io/openapi.json, https://docs.honeybadger.io/swagger.json, https://docs.hon…”
   • [probe] “official MCP server documented at https://docs.honeybadger.io/resources/mcp/”
   • [probe] “official CLI documented at https://docs.honeybadger.io/lib/ruby/gem-reference/cli/”

   proof ↗⚑ flag

   Raygun~partialprobed4/10

   Raygun docs reference a public API (Deployments API, JS source-map upload API, external access tokens for various services) implying programmatic access exists, and a third-party MCP server exists for tool integration. However, no dedicated API reference or OpenAPI/Swagger spec was found (probes for openapi.json/llms.txt returned 404s), so the API's documentation depth for AI-native automation is unclear. Missing for 10: a full public API reference/spec, first-party API docs page, and confirmation of comprehensive endpoint coverage beyond token-based uploads.

   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “If the automatic option does not work for your application you can also manually upload source maps either through our website using the `JS…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”
   • [probe] “official MCP server documented at https://github.com/MindscapeHQ/mcp-server-raygun”

   proof ↗⚑ flag

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

   weight 2 · round to Honeybadger
   Honeybadger~partialprobed3/10

   Honeybadger's hosted MCP server supports OAuth-based approval flows for connecting an agent, which implies some access-control mechanism, but there is no documentation of issuing scoped or least-privilege API keys (e.g., read-only, project-restricted) specifically for agent use. missing for 10: explicit scoped/least-privilege API key creation, granular permission levels for agent credentials, documentation of restricting MCP/agent access to specific resources.

   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “Our hosted MCP server supports OAuth, so you can connect an agent by approving access in your browser instead of copying and pasting a crede…”
   • [probe] “official MCP server documented at https://docs.honeybadger.io/resources/mcp/”

   proof ↗⚑ flag

   Raygun—none0/10

   Raygun documents a single 'external access token' for various API uses (raygun-docs-8, raygun-docs-23) but no evidence of scoped, least-privilege, or agent-specific API credentials/roles. No mention of granular permission scopes for the MCP server (raygun-probe-3) or API keys either.

   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “You'll need your external access token for the following services:”
   • [probe] “official MCP server documented at https://github.com/MindscapeHQ/mcp-server-raygun”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Honeybadger
   Honeybadger~partialprobed6/10

   Honeybadger documents official client libraries/SDKs for multiple languages (Ruby, JS, Elixir/Oban) plus a public reporting/exceptions API, source-map API, and a Ruby CLI, giving AI-native builders concrete integration points (honeybadger-docs-1, -16, -24, -33, -18, -36). However there's no formal OpenAPI/swagger spec (404s on all candidate paths, honeybadger-probe-2) and no consolidated multi-language SDK catalog or independent hands-on confirmation of building against these SDKs. Missing for 10: a machine-readable API spec (OpenAPI), broader documented SDK coverage across major languages, and independent/community validation of SDK integration quality.

   • [claimed-docs] “Once our client library is installed and configured, errors thrown by your application are automatically sent to our API.”
   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files. Use the Source Map …”
   • [claimed-docs] “The Honeybadger CLI provides a Command Line Interface for various Honeybadger-related programs and utilities.”
   • [claimed-docs] “Honeybadger now integrates with Oban (the Python port of the Elixir background job library). With this release you can report unhandled work…”
   • [claimed-docs] “Capture HTTP requests with automatic instrumentation and take advantage of new configuration options for event correlation, event context, h…”
   • [claimed-docs] “Report errors using our [exceptions API](/api/reporting-exceptions/)”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.honeybadger.io/openapi.json, https://docs.honeybadger.io/swagger.json, https://docs.hon…”

   proof ↗⚑ flag

   Raygun~partialcommunity4/10

   Evidence shows Raygun has language-specific integrations (JavaScript source maps, .NET client per community reports) and an external API access token for various services, implying SDKs exist, but there is no dedicated, comprehensive official SDK documentation set, package repository links, or coverage across multiple languages presented in the evidence pack. Missing for 10: explicit official SDK reference docs, GitHub/npm/nuget package listings, multi-language coverage details, and independent verification of SDK completeness.

   • [claimed-docs] “If your source maps are publicly available on your website Raygun will fetch them automatically without you having to do anything.”
   • [claimed-docs] “If the automatic option does not work for your application you can also manually upload source maps either through our website using the `JS…”
   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [community] “I've been using the product since Alpha, needless to say I love it... Their .NET support is awesome... WinRT support is GREAT! Picked up a f…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Honeybadger
   Honeybadger~partialclaimed3/10

   Evidence confirms Honeybadger sends webhook requests (docs-25 mentions 'web hooks' alongside source maps and uptime checks with a secret token header), implying a webhook subscription mechanism exists, but no documentation details how to configure webhook endpoints, which events trigger them, or payload formats. Missing for 10: dedicated webhook setup/configuration docs, list of subscribable event types, payload schema examples, and independent confirmation of reliability.

   • [claimed-docs] “Requests sent from Honeybadger servers for source maps, web hooks, and uptime checks include the header Honeybadger-Token which is a secret …”

   proof ↗⚑ flag

   Raygun—none0/10

   Raygun's evidence shows integrations with Slack and PagerDuty for alerting (raygun-docs-16, raygun-docs-17), but there is no documentation of a general-purpose webhook subscription mechanism that would let an AI-native user programmatically subscribe to events. No API/webhook docs, no OpenAPI spec (raygun-probe-2 shows 404s), and no llms.txt (raygun-probe-1) to indicate agent-friendly event subscription.

   • [claimed-docs] “Select the Slack channel you would like APM trace messages to be sent to and click "Authorize".”
   • [claimed-docs] “Now when an issue is triggered from this rule, a PagerDuty incident will be created and your incident team will be notified by PagerDuty.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://raygun.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   Honeybadger~partialprobed6/10

   Honeybadger offers AI-adjacent capabilities: natural-language-to-query search ('Describe your search' panel), anomaly detection against learned baselines, and an MCP server that lets an external AI assistant query BadgerQL/Insights data and help investigate issues. However, these are either query-assist/statistical alerting features rather than generative insight/suggestion output embedded directly in the product UI, or they require connecting an external AI agent via MCP rather than native in-product AI-generated insights. missing for 10: evidence of in-app AI-generated summaries/root-cause suggestions surfaced directly in the Honeybadger UI (not via external MCP client), and independent/hands-on validation of the natural-language search or anomaly detection quality.

   • [claimed-docs] “You can search for errors without writing the query yourself. Click the lightbulb icon next to the search box to open the “Describe your sea…”
   • [claimed-docs] “Anomaly detection alerts you when a project’s total error volume deviates from its learned baseline... notifies you when the current rate is…”
   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”
   • [probe] “official MCP server documented at https://docs.honeybadger.io/resources/mcp/”

   proof ↗⚑ flag

   Raygun~partialclaimed6/10

   Raygun's AI Resolution feature (raygun-docs-4, raygun-docs-5, raygun-docs-27) provides AI-powered suggestions on root cause and fixes for errors directly inside the crash reporting product, powered by OpenAI/Azure OpenAI. However, this is scoped narrowly to crash/error resolution rather than broad AI-generated insights across all data (APM, RUM, etc.), and there's no independent/hands-on corroboration of its effectiveness. Missing for 10: evidence of AI insights across other Raygun modules (APM, RUM), independent user validation of AI suggestion quality.

   • [claimed-docs] “Resolve issues with unprecedented speed and accuracy using AI-powered suggestions on the root cause of errors and how to fix them.”
   • [claimed-docs] “You can chat with this tool collaboratively. Typing indicators are shown whenever teammates are typing, so it's always clear who is using th…”
   • [claimed-docs] “This feature allows you to identify and tackle errors swiftly with just a click, using advanced AI technology powered by OpenAI and Azure Op…”

   proof ↗⚑ flag

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

   weight 2 · round to Honeybadger
   Honeybadger~partialclaimed5/10

   Honeybadger ships several always-on background automations — Alarms (BadgerQL query + threshold triggers), anomaly detection against a learned baseline, check-ins for cron/scheduled jobs, and uptime monitoring — that run autonomously once configured. However, these are traditional monitoring rules rather than AI-agent-driven automations, and the MCP integration is scoped to investigation/query capabilities rather than configuring or running autonomous background workflows. Missing for 10: evidence that an AI agent can itself create/manage these background automations (e.g. via MCP or API), and any AI-specific autonomous workflow/task runner beyond monitoring alerts.

   • [claimed-docs] “Alarms combine a BadgerQL query (“count all slow requests in the past five minutes”) with a threshold (“when count is > 2”) and trigger aler…”
   • [claimed-docs] “Anomaly detection alerts you when a project’s total error volume deviates from its learned baseline... notifies you when the current rate is…”
   • [claimed-docs] “Check-ins Tracking pings from scheduled tasks and cron jobs”
   • [claimed-docs] “Uptime monitoring Get notified when your API and website are unresponsive”
   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”

   proof ↗⚑ flag

   Raygun—none0/10

   Raygun is a monitoring/error-tracking product with alerting rules (ignore conditions, notification integrations) and an AI-assisted resolution chat, but there is no evidence of autonomous background automations/agents that run tasks independently—AI resolution appears to be an interactive chat tool, not an autonomous agent. Missing for 10: evidence of scheduled/triggered autonomous workflows, agentic task execution without human prompting, or any 'automation' feature beyond notification rules.

   • [claimed-docs] “Resolve issues with unprecedented speed and accuracy using AI-powered suggestions on the root cause of errors and how to fix them.”
   • [claimed-docs] “You can chat with this tool collaboratively. Typing indicators are shown whenever teammates are typing, so it's always clear who is using th…”
   • [claimed-docs] “This feature allows you to identify and tackle errors swiftly with just a click, using advanced AI technology powered by OpenAI and Azure Op…”
   • [claimed-docs] “We provide three types of conditions: Ignore for a specific time period ... Ignore for a specific number of occurrences ... Ignore by rule”
   • [claimed-docs] “Now when an issue is triggered from this rule, a PagerDuty incident will be created and your incident team will be notified by PagerDuty.”

   proof ↗⚑ flag

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

   weight 3 · round to Raygun
   Honeybadger~partialclaimed3/10

   Honeybadger offers a narrow built-in AI feature — a 'Describe your search' panel that turns natural-language descriptions into BadgerQL queries — but this is a single-purpose assistant, not a general-purpose in-product AI agent you can delegate broader tasks to. The more prominent AI story here (MCP server, docs-13/30) is the reverse direction: it lets an external AI assistant (e.g., Claude) connect to Honeybadger, not a built-in assistant inside Honeybadger itself. Missing for 10: a general-purpose in-app AI assistant capable of multi-step task delegation, evidence of broader assistant capabilities beyond search-query generation, and independent/hands-on corroboration of this feature's usefulness.

   • [claimed-docs] “You can search for errors without writing the query yourself. Click the lightbulb icon next to the search box to open the “Describe your sea…”
   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”

   proof ↗⚑ flag

   Raygun~partialclaimed6/10

   Raygun ships a built-in 'AI Resolution' chat assistant (powered by OpenAI/Azure OpenAI) that users can converse with to diagnose root causes and get fix suggestions for crash errors, with collaborative chat and comment-linking features. However, this AI delegation is scoped narrowly to crash/error resolution rather than general task delegation across the product, and there's no independent/hands-on verification of its effectiveness. Missing for 10: evidence of AI assistant use beyond crash resolution (e.g., APM, RUM), independent user reports validating its usefulness.

   • [claimed-docs] “Resolve issues with unprecedented speed and accuracy using AI-powered suggestions on the root cause of errors and how to fix them.”
   • [claimed-docs] “You can chat with this tool collaboratively. Typing indicators are shown whenever teammates are typing, so it's always clear who is using th…”
   • [claimed-docs] “Simply press the comment button in the AI chat, and it will create a link back to your conversation to be posted into the comments section.”
   • [claimed-docs] “This feature allows you to identify and tackle errors swiftly with just a click, using advanced AI technology powered by OpenAI and Azure Op…”

   proof ↗⚑ flag

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

   weight 2 · round to Honeybadger
   Honeybadger~partialprobed6/10

   Honeybadger supports natural-language search via a 'Describe your search' panel that translates plain-language descriptions into BadgerQL queries, and its MCP server lets a connected AI assistant fetch data, run BadgerQL queries, and investigate issues conversationally. However, most core operations (deployments, alarms, integrations, CLI) still rely on structured queries/commands rather than direct natural-language control, and there's no independent evidence of how robust the NL search feature is in practice. Missing for 10: broader native NL command support across all product areas, independent/hands-on validation of NL search accuracy.

   • [claimed-docs] “You can search for errors without writing the query yourself. Click the lightbulb icon next to the search box to open the “Describe your sea…”
   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”
   • [probe] “official MCP server documented at https://docs.honeybadger.io/resources/mcp/”

   proof ↗⚑ flag

   Raygun~partialprobed4/10

   Raygun ships an official MCP server (raygun-probe-3) which would let AI agents interact with Raygun data via natural-language-driven tool calls, and it has an AI chat feature for error resolution (raygun-docs-4/5/27) where users converse in natural language about a specific error. However, there is no evidence of natural-language commands for broader product operation (e.g., managing settings, triaging errors, running queries) beyond this narrow AI-resolution chat and the MCP server's undocumented scope. Missing for 10: documented list of MCP tools/actions, evidence of natural-language control over core workflows (search, filtering, ignoring, exporting), and any independent/hands-on confirmation.

   • [claimed-docs] “Resolve issues with unprecedented speed and accuracy using AI-powered suggestions on the root cause of errors and how to fix them.”
   • [claimed-docs] “You can chat with this tool collaboratively. Typing indicators are shown whenever teammates are typing, so it's always clear who is using th…”
   • [claimed-docs] “This feature allows you to identify and tackle errors swiftly with just a click, using advanced AI technology powered by OpenAI and Azure Op…”
   • [probe] “official MCP server documented at https://github.com/MindscapeHQ/mcp-server-raygun”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Honeybadger—none0/10

   Docs describe static API endpoints (reporting-exceptions, faults, source maps) but there is no evidence of an interactive, runnable API reference/explorer; a probe explicitly found no OpenAPI/Swagger spec at any candidate URL (404s), indicating no such interactive documentation exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.honeybadger.io/openapi.json, https://docs.honeybadger.io/swagger.json, https://docs.hon…”
   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “Returns a list of faults or a single fault for the given project”

   proof ↗⚑ flag

   Raygun—none0/10

   No evidence of an interactive API reference or runnable examples; probes explicitly show no OpenAPI/swagger spec is exposed and no llms.txt, and none of the docs mention an interactive/try-it API console. Missing for 10: interactive API explorer UI, runnable code examples, OpenAPI/swagger spec.

   • [probe] “PROBE llms.txt: HTTP 404 at https://raygun.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Honeybadger—none0/10

   The API is documented in prose (endpoints for reporting exceptions, faults, deployments, source maps), but a direct probe for machine-readable OpenAPI/Swagger specs at standard locations returned 404 across all candidates, and no evidence pack item links to a downloadable spec file. missing for 10: an actual OpenAPI/Swagger JSON or YAML file, any documented spec download link, or generator tooling.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.honeybadger.io/openapi.json, https://docs.honeybadger.io/swagger.json, https://docs.hon…”
   • [claimed-docs] “Returns a list of faults or a single fault for the given project”
   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”

   proof ↗⚑ flag

   Raygun—none0/10

   Direct probes for OpenAPI/swagger spec files all returned 404, and no documentation evidence references a downloadable machine-readable API spec; only an MCP server exists, which is a different capability.

   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://raygun.com/llms.txt”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Honeybadger—none0/10

   Evidence shows a documented REST API (v1/notices, faults, source maps, deployments) but no mention of API versioning scheme or a deprecation policy; the openapi.json probe returned 404s, suggesting no formal API spec is published. No evidence of version headers, changelog of breaking API changes, or deprecation timelines.

   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “Returns a list of faults or a single fault for the given project”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.honeybadger.io/openapi.json, https://docs.honeybadger.io/swagger.json, https://docs.hon…”

   proof ↗⚑ flag

   Raygun—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; probes for OpenAPI/spec files return 404s and no changelog entries discuss API versioning or deprecation.

   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”
   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”

   proof ↗⚑ flag

Autofix

1. ai-native userThe platform's AI can draft a code fix for an error and open a pull request against my repo for human review

   weight 2 · round drawn
   Honeybadger—none0/10

   Honeybadger's MCP and integrations let an AI assistant investigate errors and query data, but there is no evidence of it drafting a code fix or opening a pull request against a repo. Missing for 10: any capability or documentation of AI-generated code fixes, automated PR creation, or git-write integration.

   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”
   • [claimed-docs] “We now support detailed issue exports to third-party managers. When enabled, your issue exports to GitHub or GitLab will contain the full ma…”

   proof ↗⚑ flag

   Raygun—none0/10

   Raygun's AI Resolution feature only chats/suggests root-cause fixes within its dashboard (raygun-docs-4, raygun-docs-5, raygun-docs-27); there is no evidence it drafts code changes or opens a pull request against a connected repo despite repo integrations existing for source maps (raygun-docs-2).

   • [claimed-docs] “Resolve issues with unprecedented speed and accuracy using AI-powered suggestions on the root cause of errors and how to fix them.”
   • [claimed-docs] “You can chat with this tool collaboratively. Typing indicators are shown whenever teammates are typing, so it's always clear who is using th…”
   • [claimed-docs] “This feature allows you to identify and tackle errors swiftly with just a click, using advanced AI technology powered by OpenAI and Azure Op…”
   • [claimed-docs] “Connect to your repo through native integrations with GitHub, Bitbucket, and GitLab, with support for source map decoding.”

   proof ↗⚑ flag

Root cause

1. ai-native userThe platform's AI analyzes an issue — stack trace, breadcrumbs, related commits — and proposes a root cause I can act on

   weight 3 · round to Raygun
   Honeybadger~partialprobed4/10

   Honeybadger's MCP server lets a connected AI assistant fetch error data, run BadgerQL queries, and 'analyze patterns to help investigate production issues' (docs-13, docs-30), which comes close to AI-driven root-cause analysis. However, this requires the user's own external AI client via MCP rather than a built-in platform AI that automatically correlates stack traces, breadcrumbs, and commits into a proposed root cause — no evidence of an integrated automatic root-cause feature exists. Missing for 10: evidence of a first-party AI feature (not just MCP data access) that ingests stack trace + breadcrumbs + commit history and outputs a concrete root-cause hypothesis, and any hands-on/independent validation of accuracy.

   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”
   • [probe] “official MCP server documented at https://docs.honeybadger.io/resources/mcp/”

   proof ↗⚑ flag

   Raygun~partialclaimed7/10

   Raygun's 'AI Resolution' feature explicitly uses AI (OpenAI/Azure OpenAI) to suggest root causes and fixes for errors, working from stack trace/class name/error data, and integrates with repos (GitHub/Bitbucket/GitLab) for source context, matching the core of this story. However, evidence doesn't explicitly confirm the AI ingests breadcrumbs or correlates specific commits as part of its reasoning, and there's no independent/hands-on validation of the suggestion quality. Missing for 10: explicit evidence of breadcrumb/commit-level correlation feeding the AI analysis, and independent corroboration of real-world root-cause accuracy.

   • [claimed-docs] “Resolve issues with unprecedented speed and accuracy using AI-powered suggestions on the root cause of errors and how to fix them.”
   • [claimed-docs] “This feature allows you to identify and tackle errors swiftly with just a click, using advanced AI technology powered by OpenAI and Azure Op…”
   • [claimed-docs] “You can chat with this tool collaboratively. Typing indicators are shown whenever teammates are typing, so it's always clear who is using th…”
   • [claimed-docs] “Connect to your repo through native integrations with GitHub, Bitbucket, and GitLab, with support for source map decoding.”
   • [claimed-docs] “see the full stack trace, environment, browser, version, class name, host, and more”

   proof ↗⚑ flag

Alert routing

1. sreRoute alerts by project, environment, and severity to Slack, PagerDuty, or email with per-rule thresholds — new issue, frequency spike, affected-user count

   weight 3 · round to Honeybadger
   Honeybadger~partialclaimed6/10

   Honeybadger docs show Slack and PagerDuty integrations, plus 'Alarms' that combine a BadgerQL query with a threshold (e.g., count > N) and anomaly detection for volume spikes, which covers frequency-spike-style alerting and routing to chat/on-call tools. However, there's no evidence of explicit per-project/per-environment routing rules, no documented email alert channel, and no dedicated 'affected-user count' threshold type distinct from generic query-based alarms — missing for 10: environment-based routing rules, email as a routing target, explicit affected-user-count threshold configuration, and severity-tiered rule matrices.

   • [claimed-docs] “Alarms combine a BadgerQL query (“count all slow requests in the past five minutes”) with a threshold (“when count is > 2”) and trigger aler…”
   • [claimed-docs] “Anomaly detection alerts you when a project’s total error volume deviates from its learned baseline... notifies you when the current rate is…”
   • [claimed-docs] “Messages about errors include a button to resolve or reopen the error”
   • [claimed-docs] “You can generate an integration key for Honeybadger by logging in to PagerDuty then clicking on “Add New Service” and choosing “Honeybadger”…”

   proof ↗⚑ flag

   Raygun~partialclaimed5/10

   Raygun documents Slack and PagerDuty integrations tied to alert rules (raygun-docs-16, raygun-docs-17), and error grouping/prioritization by occurrence and affected users (raygun-docs-3, raygun-docs-7) supports frequency-spike and affected-user alerting concepts, but there's no evidence of unified rule configuration combining project, environment, and severity dimensions, no documented email routing, and no explicit per-rule threshold UI for new-issue vs frequency-spike vs affected-user-count conditions. missing for 10: documented per-rule threshold configuration (new issue, frequency spike, affected-user count) in one place, email alert routing, environment/severity-based routing logic, and independent confirmation of noise-reduction effectiveness.

   • [claimed-docs] “Select the Slack channel you would like APM trace messages to be sent to and click "Authorize".”
   • [claimed-docs] “Now when an issue is triggered from this rule, a PagerDuty incident will be created and your incident team will be notified by PagerDuty.”
   • [claimed-docs] “Order and prioritize errors based on users affected and the number of occurrences, and use smart filters to segment errors by date, location…”
   • [claimed-docs] “Raygun groups errors based on the `exception type`, `class name`, `method name`, and the location within the `stack trace`.”

   proof ↗⚑ flag

Noise control

1. sreFight alert fatigue with spike protection, per-key rate limits, and mute/ignore rules so one bad deploy doesn't page the whole team all night

   weight 2 · round drawn
   Honeybadger~partialclaimed4/10

   Honeybadger has real alert-fatigue tooling—error deduping/grouping, anomaly detection against a learned baseline, BadgerQL-based alarms with thresholds, and auto-resolve on deploy plus Slack resolve/reopen—but none of the evidence names the specific mechanisms in the story: spike protection, per-key rate limiting, or explicit mute/ignore/snooze rules for notifications. missing for 10: explicit spike-protection throttling, per-key/per-error rate limits, and a documented mute/ignore/snooze feature for alerts.

   • [claimed-docs] “Honeybadger groups identical errors together. Using our navigation bar, you can still navigate between each individual occurrence (or notice…”
   • [claimed-docs] “Alarms combine a BadgerQL query (“count all slow requests in the past five minutes”) with a threshold (“when count is > 2”) and trigger aler…”
   • [claimed-docs] “Anomaly detection alerts you when a project’s total error volume deviates from its learned baseline... notifies you when the current rate is…”
   • [claimed-docs] “Messages about errors include a button to resolve or reopen the error”
   • [claimed-docs] “By default, all unresolved errors are automatically marked as resolved when a deployment is recorded, which helps keep your error list clean…”
   • [claimed-docs] “Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When yo…”

   proof ↗⚑ flag

   Raygun~partialclaimed4/10

   Raygun offers ignore/mute rules (by time period, occurrence count, or custom rule) and PagerDuty/Slack alert integrations, which help reduce noise, but there's no evidence of spike protection or per-key rate limiting specifically designed to suppress alert floods during a bad deploy. missing for 10: spike/anomaly-based alert suppression, per-key or per-service rate limiting on alert volume, deploy-aware noise suppression, and any hands-on/independent confirmation these mute rules actually prevent night-long paging.

   • [claimed-docs] “We provide three types of conditions: Ignore for a specific time period ... Ignore for a specific number of occurrences ... Ignore by rule”
   • [claimed-docs] “When you ignore an error group you can specify the condition you would like the error group to be ignored for.”
   • [claimed-docs] “Error statuses provides a workflow for triaging and managing your error inbox in Crash Reporting.”
   • [claimed-docs] “Now when an issue is triggered from this rule, a PagerDuty incident will be created and your incident team will be notified by PagerDuty.”
   • [claimed-docs] “Select the Slack channel you would like APM trace messages to be sent to and click "Authorize".”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Honeybadger~partialclaimed4/10

   There's some evidence of bulk-like operations: deployments automatically mark all unresolved errors as resolved at once (docs-6, docs-29), and BadgerQL/Insights let users run aggregations and calculations across many events (docs-35, docs-8). However, there's no documented UI or API feature for explicit multi-select bulk actions (e.g., bulk resolve/delete/tag many errors at once) beyond the automatic deploy-triggered resolution. Missing for 10: explicit bulk-select UI/API endpoints for mass error management, documented batch operations beyond auto-resolve-on-deploy, independent confirmation of bulk workflows.

   • [claimed-docs] “By default, all unresolved errors are automatically marked as resolved when a deployment is recorded, which helps keep your error list clean…”
   • [claimed-docs] “Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When yo…”
   • [claimed-docs] “With it you can specify which fields you want to see, filter the kinds of events that should be returned, perform aggregations and calculati…”
   • [claimed-docs] “Alarms combine a BadgerQL query (“count all slow requests in the past five minutes”) with a threshold (“when count is > 2”) and trigger aler…”

   proof ↗⚑ flag

   Raygun~partialclaimed4/10

   Raygun's Crash Reporting export feature lets users export all or selected error groups at once, and 'ignore by rule' can suppress errors matching a condition across many occurrences, indicating some set-level operations exist. However, there's no evidence of AI-driven or programmatic bulk actions (e.g., bulk resolve, bulk tag, bulk delete via API/MCP) that an AI-native user could invoke across many items. missing for 10: bulk resolve/update actions, API or MCP-driven bulk operation examples, independent confirmation of bulk workflows at scale.

   • [claimed-docs] “The Raygun Crash Reporting export feature allows customers to export all error groups or selected errors groups from within the Crash Report…”
   • [claimed-docs] “We provide three types of conditions: Ignore for a specific time period ... Ignore for a specific number of occurrences ... Ignore by rule”
   • [claimed-docs] “When you ignore an error group you can specify the condition you would like the error group to be ignored for.”

   proof ↗⚑ flag

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

   weight 3 · round to Honeybadger
   Honeybadger~partialclaimed6/10

   Honeybadger supports rule-like automation: Alarms combine a BadgerQL query with a threshold to trigger alerts automatically (docs-8), anomaly detection triggers alerts when error volume deviates from baseline (docs-9), and deployments automatically resolve open errors and notify teams (docs-6, docs-29). These qualify as user-defined rules triggering automatic actions on events, but there's no evidence of a general-purpose automation/workflow engine (e.g., custom actions beyond alert/resolve/notify) or that AI-native users can programmatically create these rules via API/CLI/MCP. missing for 10: broader custom-action rule engine, API/CLI/MCP support for creating or managing alarms/anomaly rules, independent verification of rule automation working in practice.

   • [claimed-docs] “Alarms combine a BadgerQL query (“count all slow requests in the past five minutes”) with a threshold (“when count is > 2”) and trigger aler…”
   • [claimed-docs] “Anomaly detection alerts you when a project’s total error volume deviates from its learned baseline... notifies you when the current rate is…”
   • [claimed-docs] “By default, all unresolved errors are automatically marked as resolved when a deployment is recorded, which helps keep your error list clean…”
   • [claimed-docs] “Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When yo…”

   proof ↗⚑ flag

   Raygun~partialclaimed5/10

   Raygun supports rule-based triggers for alerting integrations — e.g. PagerDuty incidents created 'when an issue is triggered from this rule' and Slack channel notifications for APM traces — plus 'ignore by rule' conditions for error handling, showing some automated event-to-action capability. However, this is limited to notification/ignore rules rather than a general-purpose automation engine for arbitrary actions on arbitrary events. Missing for 10: evidence of a broader rule/condition engine (e.g. custom triggers, multi-step workflows, webhooks-as-actions beyond third-party integrations), and independent confirmation of reliability.

   • [claimed-docs] “Now when an issue is triggered from this rule, a PagerDuty incident will be created and your incident team will be notified by PagerDuty.”
   • [claimed-docs] “Select the Slack channel you would like APM trace messages to be sent to and click "Authorize".”
   • [claimed-docs] “We provide three types of conditions: Ignore for a specific time period ... Ignore for a specific number of occurrences ... Ignore by rule”
   • [claimed-docs] “When you ignore an error group you can specify the condition you would like the error group to be ignored for.”

   proof ↗⚑ flag

Pii scrubbing

1. sreScrub PII from error events — server-side scrubbing rules plus SDK-level filtering — before sensitive payloads ever persist

   weight 2 · round to Raygun
   Honeybadger—none0/10

   No evidence pack items mention PII scrubbing, data filtering, or SDK-level/server-side redaction rules — none of the docs, changelog, or community items reference this capability at all. missing for 10: server-side scrubbing rule configuration, SDK filter_keys/params filtering, any mention of PII/sensitive data handling before persistence.

   ⚑ flag

   Raygun~partialclaimed6/10

   Raygun docs confirm SDK-level filtering of sensitive data before it's sent (client-side scrubbing) and an IP-address suppression toggle, which addresses part of the story. However, there is no evidence of server-side scrubbing rules applied after ingestion, no mention of PII-specific pattern rules (e.g., regex-based field scrubbing), and no confirmation that filtered data never persists server-side. missing for 10: server-side scrubbing rule engine, documented PII-pattern/regex filtering, confirmation of non-persistence guarantees, independent verification of scrubbing efficacy.

   • [claimed-docs] “You can filter out sensitive information from error data, meaning before errors are sent to Raygun. This enables you to remove sensitive dat…”
   • [claimed-docs] “To stop the storage of IP addresses you can go to your "Application settings" page in Raygun and then enabling the "Disable IP address stora…”
   • [claimed-docs] “You can filter out sensitive information from error data, meaning before errors are sent to Raygun.”

   proof ↗⚑ flag

Agent access

1. ai-native userAn agent can pull my top production issues with stack traces via API or MCP, triage them, and file the real bugs into my tracker

   weight 3 · round to Honeybadger
   Honeybadger~partialprobed6/10

   Honeybadger offers a documented API for fault listing (with stack traces implied via faults/notices) and an official hosted MCP server that lets an AI assistant fetch errors, run BadgerQL queries, and manage projects, which supports pulling and triaging top issues. However, filing bugs into an external tracker is only evidenced via manual GitHub/GitLab/Jira issue export features, not shown as an MCP/agent-driven action, and there's no hands-on/independent proof of the full pull-triage-file workflow via API or MCP. missing for 10: evidence of MCP or API directly creating/filing tickets into external trackers, independent/hands-on confirmation of the end-to-end agent workflow.

   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [claimed-docs] “Returns a list of faults or a single fault for the given project”
   • [claimed-docs] “your AI assistant can fetch Honeybadger data, analyze patterns, and help investigate production issues within your existing workflow.”
   • [claimed-docs] “We now support detailed issue exports to third-party managers. When enabled, your issue exports to GitHub or GitLab will contain the full ma…”
   • [probe] “official MCP server documented at https://docs.honeybadger.io/resources/mcp/”

   proof ↗⚑ flag

   Raygun~partialprobed5/10

   Raygun does have an official MCP server (raygun-probe-3) and docs describe rich stack-trace/error data (raygun-docs-1) plus a triage workflow via error statuses (raygun-docs-25, raygun-docs-10) and repo integrations (raygun-docs-2), but there is no evidence of an actual 'file bug into external tracker' action via API/MCP, and the lack of a public OpenAPI spec or llms.txt (raygun-probe-1, raygun-probe-2) undercuts confidence in a full agent-friendly API surface. missing for 10: evidence of automated ticket creation in external trackers via API/MCP, a documented OpenAPI/agent-facing API spec, and hands-on proof the MCP server can retrieve top production issues end-to-end.

   • [probe] “official MCP server documented at https://github.com/MindscapeHQ/mcp-server-raygun”
   • [claimed-docs] “see the full stack trace, environment, browser, version, class name, host, and more”
   • [claimed-docs] “Error statuses provides a workflow for triaging and managing your error inbox in Crash Reporting.”
   • [claimed-docs] “Connect to your repo through native integrations with GitHub, Bitbucket, and GitLab, with support for source map decoding.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://raygun.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”

   proof ↗⚑ flag

Api access

1. developerList, query, and update issues and fetch raw events through a documented REST API with scoped tokens

   weight 3 · round to Honeybadger
   Honeybadger~partialclaimed5/10

   Honeybadger documents a REST API for faults (issues) with list/single-fault retrieval and search-style querying (docs-19, docs-4), plus a reporting API for creating notices, but there is no evidence of an update-issue endpoint, a raw-events fetch endpoint, or explicit scoped-token support (only a generic API key/Honeybadger-Token is mentioned). missing for 10: documented issue-update endpoint, raw event retrieval endpoint, explicit scoped/read-only token documentation.

   • [claimed-docs] “Returns a list of faults or a single fault for the given project”
   • [claimed-docs] “Example query: `john class:UserError -tag:wip -tag:pending component:"UsersController" action:'update'`.”
   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “Requests sent from Honeybadger servers for source maps, web hooks, and uptime checks include the header Honeybadger-Token which is a secret …”

   proof ↗⚑ flag

   Raygun—none0/10

   Docs mention an external access token used for uploads (source maps, dSYM, ProGuard) and a Deployments API, but there is no evidence of a documented REST API for listing, querying, or updating issues or fetching raw error events, and probes for OpenAPI/swagger specs and llms.txt all returned 404s.

   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “You'll need your external access token for the following services:”
   • [probe] “PROBE llms.txt: HTTP 404 at https://raygun.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”

   proof ↗⚑ flag

Ingest protocol

1. developerThe event-ingestion protocol is documented and open enough that custom clients and compatible SDKs can send events without an official SDK

   weight 2 · round to Honeybadger
   Honeybadger✓fullprobed7/10

   Honeybadger documents a plain REST endpoint (POST JSON to https://api.honeybadger.io/v1/notices) for reporting exceptions, plus related endpoints for source maps and deployments, meaning any custom client can integrate without the official SDK. However, there's no formal OpenAPI/schema spec (probe confirms 404s) and no independent evidence of third-party/community SDKs actually built against this raw API. Missing for 10: published OpenAPI/schema definition, independent examples of non-official clients successfully using the ingestion endpoint.

   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “Report errors using our [exceptions API](/api/reporting-exceptions/)”
   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files. Use the Source Map …”
   • [claimed-docs] “Use this endpoint to notify Honeybadger when a deploy occurs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.honeybadger.io/openapi.json, https://docs.honeybadger.io/swagger.json, https://docs.hon…”

   proof ↗⚑ flag

   Raygun—none0/10

   No evidence of a documented open ingestion protocol/API spec for sending events; probes show no OpenAPI/llms.txt spec published, and docs only reference official SDKs and an external access token for specific upload services, not a general custom-client ingestion protocol. Missing for 10: public API/protocol reference for event ingestion, evidence of third-party or community-built compatible clients.

   • [probe] “PROBE llms.txt: HTTP 404 at https://raygun.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”
   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”

   proof ↗⚑ flag

Grouping

1. developerThe platform groups thousands of duplicate events into one issue via stack-trace fingerprinting, and I can customize the grouping when it gets it wrong

   weight 3 · round to Honeybadger
   Honeybadger✓fullcommunity8/10

   Docs confirm automatic grouping of identical errors into a single issue with navigation between occurrences, and explicit customization via error class, component, stack trace, or custom fingerprint; community feedback corroborates satisfaction with deduping. Missing for 10: independent/hands-on evidence of the fingerprinting algorithm's accuracy at scale (thousands of events) and real-world examples of re-grouping mistakes being fixed.

   • [claimed-docs] “You can customize the grouping for each exception by changing the error class name, component, or stack trace—or by sending a custom fingerp…”
   • [claimed-docs] “Honeybadger groups identical errors together. Using our navigation bar, you can still navigate between each individual occurrence (or notice…”
   • [community] “Honeybadger so far. Working well enough. Love the deduping.”

   proof ↗⚑ flag

   Raygun~partialclaimed5/10

   Raygun documents stack-trace fingerprinting grouping by exception type, class name, method name, and stack trace location [raygun-docs-7], which covers the core deduplication claim. However, there is no evidence of a mechanism to customize or override grouping when it misfires (e.g., manual merge/split of error groups); only unrelated workflow controls like ignore rules and resolved statuses are documented [raygun-docs-11][raygun-docs-26][raygun-docs-10]. Missing for 10: documented ability to manually re-group, split, or merge error groups when fingerprinting is wrong, and any independent/hands-on confirmation of grouping accuracy or customization.

   • [claimed-docs] “Raygun groups errors based on the `exception type`, `class name`, `method name`, and the location within the `stack trace`.”
   • [claimed-docs] “We provide three types of conditions: Ignore for a specific time period ... Ignore for a specific number of occurrences ... Ignore by rule”
   • [claimed-docs] “When you ignore an error group you can specify the condition you would like the error group to be ignored for.”
   • [claimed-docs] “Once you've fixed a particular error, you can mark an it as 'Resolved'.”

   proof ↗⚑ flag

Triage

1. sreTriage issues — assign an owner, resolve, ignore, or snooze — and the platform reopens a resolved issue automatically when it regresses

   weight 3 · round to Raygun
   Honeybadger~partialclaimed5/10

   Honeybadger documents resolving and reopening errors (via Slack integration button) and auto-resolving errors on deploy, plus fault listing via API, which covers part of the triage workflow. However, there's no direct evidence of 'assign an owner', 'ignore', or 'snooze' actions, nor confirmation that a resolved issue is automatically reopened when it regresses (only manual reopen via Slack is shown). missing for 10: assign-owner action, ignore action, snooze action, automatic reopening on regression evidence.

   • [claimed-docs] “Messages about errors include a button to resolve or reopen the error”
   • [claimed-docs] “By default, all unresolved errors are automatically marked as resolved when a deployment is recorded, which helps keep your error list clean…”
   • [claimed-docs] “Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When yo…”
   • [claimed-docs] “Returns a list of faults or a single fault for the given project”

   proof ↗⚑ flag

   Raygun~partialclaimed6/10

   Raygun documents resolve/ignore (with time/occurrence/rule conditions) as part of an explicit error-status triage workflow, but evidence never mentions assigning an owner, a snooze action, or automatic reopening of resolved issues upon regression. missing for 10: owner assignment, explicit snooze action, automatic reopen-on-regression behavior, independent confirmation of these workflows.

   • [claimed-docs] “Once you've fixed a particular error, you can mark an it as 'Resolved'.”
   • [claimed-docs] “We provide three types of conditions: Ignore for a specific time period ... Ignore for a specific number of occurrences ... Ignore by rule”
   • [claimed-docs] “Error statuses provides a workflow for triaging and managing your error inbox in Crash Reporting.”
   • [claimed-docs] “When you ignore an error group you can specify the condition you would like the error group to be ignored for.”

   proof ↗⚑ flag

2. developerMerge issues that are really the same bug and split ones the fingerprinter wrongly collapsed

   weight 1 · round to Honeybadger
   Honeybadger~partialclaimed5/10

   Honeybadger documents customizable grouping via custom fingerprints, error class, component, or stack trace, which lets developers effectively split incorrectly-collapsed errors into distinct issues [honeybadger-docs-2][honeybadger-docs-3]. However, there is no documented UI or API action for merging two separately-grouped issues back into one bug — the evidence only covers grouping-at-ingestion via fingerprint customization, not a manual merge workflow. Missing for 10: explicit merge-issues feature/API, evidence of an UI 'merge' action, and independent confirmation that fingerprint changes retroactively re-group existing occurrences.

   • [claimed-docs] “You can customize the grouping for each exception by changing the error class name, component, or stack trace—or by sending a custom fingerp…”
   • [claimed-docs] “Honeybadger groups identical errors together. Using our navigation bar, you can still navigate between each individual occurrence (or notice…”
   • [claimed-docs] “Honeybadger provides powerful search features that let you easily find previously-occurred errors by type, location, meta-data and many othe…”

   proof ↗⚑ flag

   Raygun—none0/10

   Docs describe automatic grouping logic (exception type, class name, method, stack trace location) and error statuses (resolved/ignored) but there is no evidence of a manual merge-issues or split-issues feature to correct fingerprinting mistakes.

   • [claimed-docs] “Raygun groups errors based on the `exception type`, `class name`, `method name`, and the location within the `stack trace`.”
   • [claimed-docs] “Error statuses provides a workflow for triaging and managing your error inbox in Crash Reporting.”
   • [claimed-docs] “Once you've fixed a particular error, you can mark an it as 'Resolved'.”
   • [claimed-docs] “We provide three types of conditions: Ignore for a specific time period ... Ignore for a specific number of occurrences ... Ignore by rule”

   proof ↗⚑ flag

User feedback

1. developerCollect user feedback — a crash-report dialog or feedback widget — attached to the exact error event the user hit

   weight 1 · round drawn
   Honeybadger—none0/10

   Honeybadger's evidence covers automatic error capture, grouping, search, deployments, and integrations, but there is no mention of a user-facing crash-report dialog or feedback widget that lets end-users submit feedback tied to a specific error occurrence.

   ⚑ flag

   Raygun—none0/10

   The evidence pack covers Raygun's crash reporting stack traces, AI resolution, error grouping, source maps, and integrations, but contains no mention of a crash-report dialog or feedback widget that lets end users submit feedback tied to a specific error event — a capability common in comparable crash-reporting tools.

   ⚑ flag

User impact

1. sreEvery issue quantifies real impact — how many users and sessions are affected — so I prioritize by blast radius, not raw event counts

   weight 2 · round to Raygun
   Honeybadger—none0/10

   Evidence covers error grouping, search, deployments, alarms, and anomaly detection on error volume/rate, but nowhere quantifies user or session impact (e.g., affected-user counts) for prioritization by blast radius. missing for 10: any mention of unique users/sessions affected metric, user-impact scoring, or blast-radius prioritization feature.

   ⚑ flag

   Raygun~partialclaimed5/10

   Raygun explicitly supports ordering/prioritizing errors by 'users affected' and occurrence counts, which directly maps to blast-radius prioritization rather than raw event counts (raygun-docs-3). However, there's no evidence of session-level impact quantification, percentage-of-userbase metrics, or dedicated 'impact score' analytics beyond simple affected-user counts. Missing for 10: session-affected metrics, quantified blast-radius scoring/percentage-of-users, independent corroboration of this prioritization workflow in practice.

   • [claimed-docs] “Order and prioritize errors based on users affected and the number of occurrences, and use smart filters to segment errors by date, location…”

   proof ↗⚑ flag

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

   weight 2 · round to Honeybadger
   Honeybadger~partialprobed5/10

   Honeybadger exposes a documented REST API for core actions—reporting exceptions, deployments, source maps, and listing faults (honeybadger-docs-15,17,19,28)—plus a CLI and MCP server for agent access (honeybadger-docs-18,13,31). However, the probe found no OpenAPI/swagger spec (honeybadger-probe-2), and many UI-only capabilities (resolving/reopening errors, BadgerQL alarm configuration, team/SAML management, account switching) are not shown to have API equivalents. Missing for 10: comprehensive API parity for error resolution, alarms, account/team management, and a published OpenAPI spec confirming full coverage.

   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “Use this endpoint to notify Honeybadger when a deploy occurs.”
   • [claimed-docs] “Returns a list of faults or a single fault for the given project”
   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files.”
   • [claimed-docs] “The Honeybadger CLI provides a Command Line Interface for various Honeybadger-related programs and utilities.”
   • [claimed-docs] “Once connected, your AI assistant gains the following capabilities: Project management... Error investigation... Insights: Run BadgerQL quer…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.honeybadger.io/openapi.json, https://docs.honeybadger.io/swagger.json, https://docs.hon…”
   • [claimed-docs] “You can create additional accounts and switch between accounts using the dropdown in the navigation bar.”

   proof ↗⚑ flag

   Raygun~partialprobed3/10

   Docs reference specific API endpoints (Deployments API, external access token for uploads, source map API) showing some functionality is exposed via API, but there is no evidence of comprehensive API parity with the UI, and probes show no discoverable OpenAPI spec or llms.txt (404s), suggesting the API surface is not fully documented or complete. missing for 10: evidence of full CRUD/API coverage for error management, AI resolution chat, exports, and dashboards equivalent to UI; a published OpenAPI/swagger spec confirming parity.

   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “If the automatic option does not work for your application you can also manually upload source maps either through our website using the `JS…”
   • [claimed-docs] “The Raygun Crash Reporting export feature allows customers to export all error groups or selected errors groups from within the Crash Report…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://raygun.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Honeybadger~partialclaimed3/10

   Honeybadger exposes a REST API (e.g. list/get faults, reporting exceptions) that returns data in JSON, which could be used to script an export of error data, but there is no documented bulk 'export all your account data' feature, no GDPR-style data-portability tool, and no mention of full account deletion/export workflow. missing for 10: dedicated full-account data export feature, documented open-format bulk export tool, evidence of complete data portability/leave workflow.

   • [claimed-docs] “Returns a list of faults or a single fault for the given project”
   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “We now support detailed issue exports to third-party managers. When enabled, your issue exports to GitHub or GitLab will contain the full ma…”

   proof ↗⚑ flag

   Raygun~partialprobed3/10

   Raygun documents a Crash Reporting export feature (export all or selected error groups) and CSV exports aligned with filters, showing some data portability, but there is no evidence of a full account-wide export covering APM, RUM, and other modules in open formats, and no documented API/OpenAPI spec (probes return 404) that would enable complete self-service data extraction. missing for 10: full-account data export beyond error groups, documented open API/schema for export, evidence of exporting APM/RUM/user data, independent confirmation of format openness.

   • [claimed-docs] “The Raygun Crash Reporting export feature allows customers to export all error groups or selected errors groups from within the Crash Report…”
   • [claimed-docs] “Aligned **CSV exports** with applied top-level filters. Exported data now matches filtered views for: Most Requested Pages, Tags, Country co…”
   • [claimed-docs] “Exported data now matches filtered views for:”
   • [probe] “PROBE openapi: all candidate paths 404 (https://raygun.com/openapi.json, https://raygun.com/swagger.json, https://raygun.com/api/openapi.jso…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Honeybadger—none0/10

   Honeybadger is a closed, commercial SaaS product; no evidence in the pack indicates its source code is published under an open license (client libraries being open-source is not addressed, and the core service is proprietary). Missing for 10: any mention of an open-source license, public source repository, or licensing terms.

   ⚑ flag

   Raygun—none0/10

   Raygun is a closed, commercial SaaS product with no evidence of an open-license source code repository for the core product; evidence only shows a separate MCP server integration and docs, not open-sourced product source.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Honeybadger—none0/10

   Honeybadger is presented as a hosted SaaS product (api.honeybadger.io) with no evidence of an open-source self-hosted core, on-premise deployment option, or Docker/self-host installation guide anywhere in the evidence pack.

   ⚑ flag

   Raygun—none0/10

   Raygun is offered as a hosted SaaS monitoring platform; no evidence in the pack mentions a self-hosted deployment option, on-prem package, or Docker image. Absence of evidence for an applicable capability yields none. missing for 10: any self-hosting/on-prem documentation, deployment instructions, or licensing for self-managed instances.

   ⚑ flag

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

   weight 2 · round drawn
   Honeybadger—none0/10

   No evidence in the pack addresses data residency, regional hosting options, or ability to choose where data is stored; only data retention (Insights replication) and security token handling are mentioned. missing for 10: any mention of region selection, EU/US hosting options, or data residency controls.

   ⚑ flag

   Raygun—none0/10

   No evidence in the pack mentions data residency, region selection, or where Raygun stores customer data; only sensitive-data filtering and IP-storage disabling are documented, which are data-scrubbing controls, not region/residency choice.

   ⚑ flag

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

   weight 3 · round drawn
   Honeybadger—none0/10

   No evidence in the pack addresses AI training data usage or opt-out policies for Honeybadger's data; the product is an error-tracking/monitoring tool and this axis is plausible (e.g., a privacy policy statement about AI training) but nothing documents it. Missing for 10: any privacy policy statement on AI training data usage, opt-out mechanism, or data processing terms addressing AI model training.

   ⚑ flag

   Raygun—none0/10

   Raygun uses OpenAI/Azure OpenAI for its AI-powered error resolution feature (raygun-docs-27), but there is no evidence of any opt-out mechanism, data usage policy, or AI training exclusion controls for customer data. Evidence covers sensitive data filtering for error reports (docs-12, docs-13) but not AI training opt-out specifically.

   • [claimed-docs] “This feature allows you to identify and tackle errors swiftly with just a click, using advanced AI technology powered by OpenAI and Azure Op…”
   • [claimed-docs] “You can filter out sensitive information from error data, meaning before errors are sent to Raygun. This enables you to remove sensitive dat…”
   • [claimed-docs] “To stop the storage of IP addresses you can go to your "Application settings" page in Raygun and then enabling the "Disable IP address stora…”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Raygun
   Honeybadger—none0/10

   Evidence only hints that Business/Enterprise accounts can replicate Insights data for longer retention (docs-22), but there is no mention of any user-facing control to configure retention windows, purge/delete data on demand, or comply with deletion requests. Missing for 10: documented retention settings, a data-deletion API/UI, and any GDPR-style erasure mechanism.

   • [claimed-docs] “If you need to keep your Insights data longer than Honeybadger stores it, Business and Enterprise accounts can now replicate”

   proof ↗⚑ flag

   Raygun~partialclaimed5/10

   Raygun provides some data controls relevant to retention/deletion — filtering sensitive data before it's sent, disabling IP address storage, and exporting error data — but there's no documented self-service deletion/purge mechanism, configurable retention periods, or explicit data deletion policy for AI-native/automated control. missing for 10: documented retention period settings, an explicit data deletion/purge API or workflow, and confirmation these controls are accessible/automatable for AI-native use cases.

   • [claimed-docs] “You can filter out sensitive information from error data, meaning before errors are sent to Raygun. This enables you to remove sensitive dat…”
   • [claimed-docs] “To stop the storage of IP addresses you can go to your "Application settings" page in Raygun and then enabling the "Disable IP address stora…”
   • [claimed-docs] “The Raygun Crash Reporting export feature allows customers to export all error groups or selected errors groups from within the Crash Report…”

   proof ↗⚑ flag

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

   weight 2 · round to Raygun
   Honeybadger—none0/10

   Honeybadger itself is an error-tracking/telemetry product whose core function is collecting data from customer apps; the evidence pack contains no mention of an opt-out mechanism for telemetry/usage tracking related to the AI assistant/MCP integration or the product's own data collection practices. Since this axis (opting out of tracking) is a fair privacy-posture question for an AI-native user of any product, but no evidence shows such an opt-out exists, the verdict is none. Missing for 10: any documentation of an opt-out/telemetry-disable setting, privacy controls for AI assistant usage data, or opt-out options for the MCP integration.

   ⚑ flag

   Raygun~partialclaimed3/10

   Raygun documents limited privacy controls—filtering sensitive data before it's sent to Raygun and disabling IP address storage—but these apply to the error/crash data customers send from their apps, not to opting out of Raygun's own product usage/telemetry tracking for an AI-native user of the platform. Missing for 10: explicit opt-out mechanism for Raygun's own usage analytics/telemetry, any AI-agent-specific telemetry controls, and independent confirmation these settings fully disable tracking.

   • [claimed-docs] “You can filter out sensitive information from error data, meaning before errors are sent to Raygun. This enables you to remove sensitive dat…”
   • [claimed-docs] “To stop the storage of IP addresses you can go to your "Application settings" page in Raygun and then enabling the "Disable IP address stora…”
   • [claimed-docs] “You can filter out sensitive information from error data, meaning before errors are sent to Raygun.”

   proof ↗⚑ flag

Quotas

1. engineering leaderCap event quotas per project and set spend limits so an error storm burns a predictable budget, never a surprise invoice

   weight 2 · round drawn
   Honeybadger—none0/10

   No evidence anywhere in the pack of event quota caps, spend/budget limits, or usage-based throttling controls for a project; the evidence covers error grouping, search, deployments, alarms, and MCP/CLI integrations but nothing about cost or quota governance.

   ⚑ flag

   Raygun—none0/10

   No evidence anywhere in the pack of per-project event quotas, spend limits, or budget caps for error volumes; docs focus on error grouping, ignoring rules, AI resolution, and integrations, not billing/quota controls.

   ⚑ flag

Regressions

1. sreI get alerted when an error that was fixed comes back in a newer release, distinct from ordinary new-issue noise

   weight 2 · round to Honeybadger
   Honeybadger~partialclaimed5/10

   Honeybadger auto-resolves errors on deploy and tracks reoccurrences (doc-6, doc-29), and Slack messages include a 'resolve or reopen' button implying errors can reopen (doc-10), which is the mechanical basis for detecting a fixed error's return. However, there is no explicit evidence of a distinct 'regression' alert type or notification that flags a reopened error differently from a brand-new issue, so SREs would have to infer regressions from reopen state rather than get a dedicated alert. Missing for 10: explicit regression-specific alert/notification distinct from new-issue alerts, and confirmation that reopening a resolved error triggers a notification at all.

   • [claimed-docs] “By default, all unresolved errors are automatically marked as resolved when a deployment is recorded, which helps keep your error list clean…”
   • [claimed-docs] “Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When yo…”
   • [claimed-docs] “Messages about errors include a button to resolve or reopen the error”
   • [claimed-docs] “`occurred.after:'last deploy'` Errors that occurred since the most recent deployment”

   proof ↗⚑ flag

   Raygun—none0/10

   Raygun's docs show error grouping, marking errors 'Resolved', and version-based filtering, but there is no evidence of a distinct 'regression' state or alert that fires specifically when a previously resolved error reappears in a newer release version, separate from ordinary new-error notifications.

   • [claimed-docs] “Raygun groups errors based on the `exception type`, `class name`, `method name`, and the location within the `stack trace`.”
   • [claimed-docs] “Once you've fixed a particular error, you can mark an it as 'Resolved'.”
   • [claimed-docs] “Error statuses provides a workflow for triaging and managing your error inbox in Crash Reporting.”
   • [claimed-docs] “Order and prioritize errors based on users affected and the number of occurrences, and use smart filters to segment errors by date, location…”

   proof ↗⚑ flag

Release health

1. sreWatch release health — crash-free sessions and users, adoption per release — and compare a canary release against the last stable one

   weight 2 · round drawn
   Honeybadger—none0/10

   Honeybadger documents deployment tracking (correlating errors with deploys, diffing against last deploy, auto-resolving errors on deploy) but there is no evidence of crash-free sessions/users metrics or per-release adoption percentages, which are the specific release-health metrics this story asks about.

   • [claimed-docs] “By default, all unresolved errors are automatically marked as resolved when a deployment is recorded, which helps keep your error list clean…”
   • [claimed-docs] “When GitHub or GitLab is connected, Honeybadger links the revision to a comparison page that shows a diff of what changed since the last dep…”
   • [claimed-docs] “Use this endpoint to notify Honeybadger when a deploy occurs.”
   • [claimed-docs] “`occurred.after:'last deploy'` Errors that occurred since the most recent deployment”
   • [claimed-docs] “Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When yo…”

   proof ↗⚑ flag

   Raygun—none0/10

   Evidence shows Raygun can filter/segment errors by version and other tags (raygun-docs-3) but there is no mention of a release-health dashboard, crash-free sessions/users metrics, adoption-per-release tracking, or a canary-vs-stable comparison view anywhere in the docs or changelog.

   • [claimed-docs] “Order and prioritize errors based on users affected and the number of occurrences, and use smart filters to segment errors by date, location…”

   proof ↗⚑ flag

Release tracking

1. developerAssociate errors with releases and commits so each issue shows the release it first appeared in and the suspect commit that likely caused it

   weight 3 · round to Honeybadger
   Honeybadger~partialclaimed5/10

   Honeybadger's deployment tracking records deploys, auto-resolves errors on deploy, and (with GitHub/GitLab connected) links a revision to a diff of what changed since the last deploy, plus supports queries like 'occurred.after:last deploy' to correlate errors with releases. However, there's no documented evidence of a per-issue 'first seen in release X' badge or automatic 'suspect commit' attribution pinpointing which commit likely caused a specific error, which is the core of this story. Missing for 10: explicit per-error 'first appeared in release' metadata, automated suspect-commit/blame attribution shown on the issue itself, independent corroboration of this workflow.

   • [claimed-docs] “By default, all unresolved errors are automatically marked as resolved when a deployment is recorded, which helps keep your error list clean…”
   • [claimed-docs] “When GitHub or GitLab is connected, Honeybadger links the revision to a comparison page that shows a diff of what changed since the last dep…”
   • [claimed-docs] “`occurred.after:'last deploy'` Errors that occurred since the most recent deployment”
   • [claimed-docs] “Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When yo…”

   proof ↗⚑ flag

   Raygun~partialclaimed4/10

   Raygun docs show native repo integrations (GitHub/Bitbucket/GitLab) with source map decoding and a Deployments API requiring an external access token, implying some deployment/version tracking, but there is no explicit documentation of a 'first seen in release' field or automated 'suspect commit' identification tied to an issue. missing for 10: explicit release-tagging of first occurrence, suspect-commit/blame attribution, and any hands-on confirmation this works as described.

   • [claimed-docs] “Connect to your repo through native integrations with GitHub, Bitbucket, and GitLab, with support for source map decoding.”
   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “Order and prioritize errors based on users affected and the number of occurrences, and use smart filters to segment errors by date, location…”

   proof ↗⚑ flag

Event context

1. developerAttach breadcrumbs, custom tags, and user context to every event so a stack trace arrives with the state that produced it

   weight 2 · round to Honeybadger
   Honeybadger~partialclaimed4/10

   Evidence shows tag-based search syntax (implying tags can be attached) and a changelog note about 'event context' and 'event correlation' configuration in JS packages, but there is no explicit documentation of breadcrumb trails or explicit user-context attachment on error notices. missing for 10: explicit breadcrumb API/docs, explicit user context attachment API, worked example showing tags+context+breadcrumbs together on a single event.

   • [claimed-docs] “Example query: `john class:UserError -tag:wip -tag:pending component:"UsersController" action:'update'`.”
   • [claimed-docs] “Capture HTTP requests with automatic instrumentation and take advantage of new configuration options for event correlation, event context, h…”
   • [claimed-docs] “You can customize the grouping for each exception by changing the error class name, component, or stack trace—or by sending a custom fingerp…”

   proof ↗⚑ flag

   Raygun~partialclaimed3/10

   Docs mention filtering/segmenting errors by 'custom tags' (raygun-docs-3) and removing sensitive data before sending (raygun-docs-12), implying some ability to attach custom metadata to events, but there is no evidence of a breadcrumb API, explicit user-context attachment, or SDK instrumentation guidance for attaching state to individual events. Missing for 10: breadcrumb trail API, explicit user identification/context object, SDK code examples showing tags/custom data attachment per event.

   • [claimed-docs] “Order and prioritize errors based on users affected and the number of occurrences, and use smart filters to segment errors by date, location…”
   • [claimed-docs] “You can filter out sensitive information from error data, meaning before errors are sent to Raygun. This enables you to remove sensitive dat…”

   proof ↗⚑ flag

Mobile crashes

1. developerCapture native mobile crashes — iOS, Android, NDK — with the device, OS, and app-version context needed to reproduce them

   weight 2 · round to Raygun
   Honeybadger—none0/10

   Evidence pack covers Ruby, JS, and general error-reporting APIs, deployments, integrations, and MCP/CLI tooling, but contains no mention of iOS, Android, or NDK SDKs, or native mobile crash context (device, OS, app version). Missing for 10: iOS SDK docs, Android SDK docs, NDK/native crash capture, mobile device/app-version context capture.

   • [claimed-docs] “Once our client library is installed and configured, errors thrown by your application are automatically sent to our API.”
   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”
   • [claimed-docs] “Capture HTTP requests with automatic instrumentation and take advantage of new configuration options for event correlation, event context, h…”

   proof ↗⚑ flag

   Raygun~partialclaimed5/10

   Docs show support for iOS (dSYM upload) and Android (ProGuard mapping file upload) native crash symbolication, implying native mobile crash reporting exists, and general crash docs mention environment/version context capture. However there's no explicit mention of NDK crash support, and no mobile-specific documentation of device/OS/app-version metadata capture for reproducing crashes. missing for 10: NDK-specific crash handling evidence, mobile SDK docs detailing device/OS/app-version context fields, independent/hands-on confirmation of mobile crash capture.

   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “see the full stack trace, environment, browser, version, class name, host, and more”

   proof ↗⚑ flag

Sdk coverage

1. developerInstrument my web frontend, backend services, and mobile apps with official SDKs that capture uncaught errors automatically

   weight 3 · round drawn
   Honeybadger~partialclaimed6/10

   Docs confirm automatic uncaught-error capture via client libraries ("errors thrown by your application are automatically sent to our API"), JS/frontend automatic instrumentation and source-map support, and a generic exceptions API for backend reporting. However, the evidence pack lacks explicit confirmation of dedicated mobile SDKs (iOS/Android) or a list of officially supported backend languages beyond the Ruby CLI/gem reference, so mobile coverage is unconfirmed. Missing for 10: explicit mobile SDK documentation, multi-language backend SDK list, independent hands-on verification of auto-capture across platforms.

   • [claimed-docs] “Once our client library is installed and configured, errors thrown by your application are automatically sent to our API.”
   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files. Use the Source Map …”
   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files.”
   • [claimed-docs] “Capture HTTP requests with automatic instrumentation and take advantage of new configuration options for event correlation, event context, h…”
   • [claimed-docs] “Report errors using our [exceptions API](/api/reporting-exceptions/)”
   • [claimed-docs] “Your JSON payload should be submitted as the body of a POST request to https://api.honeybadger.io/v1/notices”

   proof ↗⚑ flag

   Raygun~partialcommunity6/10

   Raygun's crash-reporting docs confirm automatic capture of stack traces, environment, browser/host info (raygun-docs-1) and mention platform-specific tooling like JS source maps (raygun-docs-14/15), iOS dSYM uploads and Android ProGuard mapping (raygun-docs-8/23), plus a community testimonial confirming .NET and WinRT SDK support (raygun-comm-1). However, there is no explicit documentation snippet showing SDK installation/auto-instrumentation code for each platform (frontend, backend, mobile) or confirmation that uncaught exceptions are captured without manual instrumentation across all three. Missing for 10: explicit SDK setup docs per platform, confirmation of automatic uncaught-exception hooking (not just crash reporting features), and independent verification beyond one old HN comment.

   • [claimed-docs] “see the full stack trace, environment, browser, version, class name, host, and more”
   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “If your source maps are publicly available on your website Raygun will fetch them automatically without you having to do anything.”
   • [claimed-docs] “If the automatic option does not work for your application you can also manually upload source maps either through our website using the `JS…”
   • [claimed-docs] “You'll need your external access token for the following services:”
   • [community] “I've been using the product since Alpha, needless to say I love it... Their .NET support is awesome... WinRT support is GREAT! Picked up a f…”

   proof ↗⚑ flag

Dashboards

1. engineering leaderSee error trends across projects and teams on dashboards — top regressions, new issues per release, volume over time

   weight 2 · round to Honeybadger
   Honeybadger~partialclaimed6/10

   Honeybadger's BadgerQL/Insights, deployment tracking (correlating errors with releases, 'occurred.after:last deploy' queries), and anomaly detection support volume-over-time and per-release regression tracking, giving engineering leaders solid analytics tools. However, evidence never shows a native cross-project/cross-team rollup dashboard — only per-account switching (docs-34) — so the 'across projects and teams' aggregation aspect of the story is unproven. Missing for 10: explicit cross-project/team aggregated dashboard UI, named 'top regressions' report, and independent/hands-on confirmation of dashboard usability at leadership level.

   • [claimed-docs] “Alarms combine a BadgerQL query (“count all slow requests in the past five minutes”) with a threshold (“when count is > 2”) and trigger aler…”
   • [claimed-docs] “Anomaly detection alerts you when a project’s total error volume deviates from its learned baseline... notifies you when the current rate is…”
   • [claimed-docs] “`occurred.after:'last deploy'` Errors that occurred since the most recent deployment”
   • [claimed-docs] “Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When yo…”
   • [claimed-docs] “Honeybadger provides powerful search features that let you easily find previously-occurred errors by type, location, meta-data and many othe…”
   • [claimed-docs] “With it you can specify which fields you want to see, filter the kinds of events that should be returned, perform aggregations and calculati…”
   • [claimed-docs] “You can create additional accounts and switch between accounts using the dropdown in the navigation bar.”

   proof ↗⚑ flag

   Raygun~partialclaimed5/10

   Raygun provides error grouping, filtering/sorting by occurrence and users affected, an error chart on search results, and export capabilities, which support trend visibility within a single project, but there is no documented cross-project/cross-team rollup dashboard, no explicit 'new issues per release' or 'top regressions' aggregate view, and no evidence of an engineering-leader-focused multi-team overview. missing for 10: cross-project/team-level aggregate dashboards, explicit release-over-release regression tracking, top-regressions ranking view, and independent confirmation of these executive-level views.

   • [claimed-docs] “Order and prioritize errors based on users affected and the number of occurrences, and use smart filters to segment errors by date, location…”
   • [claimed-docs] “Added **error chart** visualization to **search results page**. Provides visual insight into error frequency and trends.”
   • [claimed-docs] “Added **error chart** visualization to **search results page**.”
   • [claimed-docs] “The Raygun Crash Reporting export feature allows customers to export all error groups or selected errors groups from within the Crash Report…”
   • [claimed-docs] “Raygun provides a fully integrated error, crash and performance monitoring solution, unlike anything else on the market today. See everythin…”

   proof ↗⚑ flag

Event search

1. developerSearch and filter events across projects by tag, release, environment, and custom properties with a real query syntax

   weight 2 · round to Honeybadger
   Honeybadger✓fullclaimed8/10

   Honeybadger documents a real BadgerQL-style query syntax (tag:, class:, component:, action:, occurred.after: 'last deploy', negation with -tag:) for filtering errors/events by tag, release/deploy, environment-like properties and custom fields, plus a natural-language-to-query assist feature and Insights query capabilities for aggregation/filtering across fields. missing for 10: explicit documentation of cross-project search/filtering (queries appear scoped per-project) and independent hands-on validation of the query syntax's breadth beyond docs.

   • [claimed-docs] “Example query: `john class:UserError -tag:wip -tag:pending component:"UsersController" action:'update'`.”
   • [claimed-docs] “You can search for errors without writing the query yourself. Click the lightbulb icon next to the search box to open the “Describe your sea…”
   • [claimed-docs] “`occurred.after:'last deploy'` Errors that occurred since the most recent deployment”
   • [claimed-docs] “Honeybadger provides powerful search features that let you easily find previously-occurred errors by type, location, meta-data and many othe…”
   • [claimed-docs] “Honeybadger's error search and BadgerQL can answer almost any question about your e”
   • [claimed-docs] “With it you can specify which fields you want to see, filter the kinds of events that should be returned, perform aggregations and calculati…”

   proof ↗⚑ flag

   Raygun~partialclaimed5/10

   Docs confirm smart filters to segment errors by date, location, version, host, OS, browser, and custom tags, plus a dedicated search results page with visual charts, indicating some query/filter capability. However, there's no evidence of a documented query syntax, explicit 'environment' as a filter dimension, or cross-project search scope. missing for 10: documented query syntax/operators, explicit environment tag filtering, cross-project search evidence.

   • [claimed-docs] “Order and prioritize errors based on users affected and the number of occurrences, and use smart filters to segment errors by date, location…”
   • [claimed-docs] “Added **error chart** visualization to **search results page**. Provides visual insight into error frequency and trends.”
   • [claimed-docs] “Aligned **CSV exports** with applied top-level filters. Exported data now matches filtered views for: Most Requested Pages, Tags, Country co…”

   proof ↗⚑ flag

Sourcemaps

1. developerUpload JavaScript source maps from CI — via CLI or bundler plugin — so production stack traces show my original source, not minified frames

   weight 3 · round to Honeybadger
   Honeybadger~partialprobed6/10

   Honeybadger documents a Source Map Upload API for un-minifying JS stack traces (honeybadger-docs-16, honeybadger-docs-28), and it has a general CLI (honeybadger-docs-18, honeybadger-probe-4) with deploy notification support, but the evidence never explicitly shows a CI-oriented source map upload command in that CLI or a bundler plugin (webpack/rollup/vite) for automated CI upload. missing for 10: explicit CLI subcommand or bundler plugin for source map upload, CI usage examples/integration guide, independent confirmation of correct symbolication in production.

   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files. Use the Source Map …”
   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files.”
   • [claimed-docs] “The Honeybadger CLI provides a Command Line Interface for various Honeybadger-related programs and utilities.”
   • [probe] “official CLI documented at https://docs.honeybadger.io/lib/ruby/gem-reference/cli/”

   proof ↗⚑ flag

   Raygun~partialclaimed5/10

   Docs confirm source map support: automatic fetching if public, or manual upload via the JS source map center or API, and an external access token is required for 'Uploading JavaScript files directly to Raygun' — implying scriptable/CI-friendly upload. However, no evidence of an official CLI tool or bundler plugin (webpack/vite/rollup) for source map upload as CI step. Missing for 10: dedicated CLI/bundler plugin documentation, explicit CI pipeline integration examples.

   • [claimed-docs] “If your source maps are publicly available on your website Raygun will fetch them automatically without you having to do anything.”
   • [claimed-docs] “If the automatic option does not work for your application you can also manually upload source maps either through our website using the `JS…”
   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”

   proof ↗⚑ flag

Symbolication

1. developerUpload dSYM, ProGuard, and native debug symbols so mobile and native crashes symbolicate to real function names and lines

   weight 2 · round to Raygun
   Honeybadger—none0/10

   Evidence shows Honeybadger supports JavaScript source map upload/unminification (docs-16, docs-28) but contains no mention of dSYM, ProGuard, or native mobile debug symbol upload/symbolication anywhere in the pack.

   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files. Use the Source Map …”
   • [claimed-docs] “Honeybadger can automatically un-minify your JavaScript code if you provide a source map along with your minified files.”

   proof ↗⚑ flag

   Raygun~partialclaimed4/10

   Docs confirm Raygun supports sending dSYMs and uploading ProGuard mapping files (gated behind an external access token), which implies symbolication support for iOS/Android crashes, but there is no detailed documentation of the upload workflow, verification of resulting symbolication quality, or independent/hands-on confirmation it works as claimed. missing for 10: detailed dSYM/ProGuard upload workflow docs, native debug symbol handling details, independent verification of correct symbolication.

   • [claimed-docs] “You'll need your external access token for the following services: Deployments API, Sending dSYMS to Raygun, Uploading ProGuard mapping file…”
   • [claimed-docs] “You'll need your external access token for the following services:”

   proof ↗⚑ flag

Issue trackers

1. developerLink an error to Jira, GitHub Issues, or Linear with two-way status sync, so fixing the ticket resolves the error and a regression reopens it

   weight 2 · round to Honeybadger
   Honeybadger~partialclaimed4/10

   Honeybadger documents issue export/linking to GitHub, GitLab, and Jira (including full Jira wiki markup), and auto-resolves errors on deploy, but there is no evidence of Linear integration nor explicit two-way status sync where resolving/reopening the external ticket automatically resolves/reopens the Honeybadger error (only Slack shows resolve/reopen buttons within Honeybadger itself). missing for 10: Linear integration, documented two-way sync (ticket resolution reopening/closing the Honeybadger error automatically), independent confirmation of sync behavior.

   • [claimed-docs] “We now support detailed issue exports to third-party managers. When enabled, your issue exports to GitHub or GitLab will contain the full ma…”
   • [claimed-docs] “By default, all unresolved errors are automatically marked as resolved when a deployment is recorded, which helps keep your error list clean…”
   • [claimed-docs] “Messages about errors include a button to resolve or reopen the error”

   proof ↗⚑ flag

   Raygun—none0/10

   Evidence shows GitHub/Bitbucket/GitLab integration is for repo linking and source map decoding, not issue-tracker ticket sync; no mention of Jira, GitHub Issues, or Linear ticket integration with two-way status sync (auto-resolve/reopen) anywhere in the pack.

   • [claimed-docs] “Connect to your repo through native integrations with GitHub, Bitbucket, and GitLab, with support for source map decoding.”
   • [claimed-docs] “Once you've fixed a particular error, you can mark an it as 'Resolved'.”

   proof ↗⚑ flag

Scm context

1. developerThe platform connects to my repos so an issue shows suspect commits and code owners, and I can jump from a stack frame to the exact line on my default branch

   weight 2 · round to Raygun
   Honeybadger—none0/10

   Evidence shows Honeybadger connects to GitHub/GitLab for deploy diffs and issue exports (docs-7, docs-23), but there is no evidence of suspect-commit identification, code-owner attribution, or jumping from a stack frame to the exact line on the default branch in the repo. Missing for 10: suspect commit detection, code owner mapping, stack-frame-to-source-line deep linking.

   • [claimed-docs] “When GitHub or GitLab is connected, Honeybadger links the revision to a comparison page that shows a diff of what changed since the last dep…”
   • [claimed-docs] “We now support detailed issue exports to third-party managers. When enabled, your issue exports to GitHub or GitLab will contain the full ma…”

   proof ↗⚑ flag

   Raygun~partialclaimed4/10

   Raygun documents native repo integrations (GitHub, Bitbucket, GitLab) with source map decoding, which implies some code-context mapping from stack traces, but there is no evidence of surfacing suspect commits, code owners, or direct deep-linking from a stack frame to the exact line on the default branch. missing for 10: suspect-commit identification, code owner attribution, verified line-level deep-linking to source repo.

   • [claimed-docs] “Connect to your repo through native integrations with GitHub, Bitbucket, and GitLab, with support for source map decoding.”
   • [claimed-docs] “If your source maps are publicly available on your website Raygun will fetch them automatically without you having to do anything.”
   • [claimed-docs] “If the automatic option does not work for your application you can also manually upload source maps either through our website using the `JS…”

   proof ↗⚑ flag