# Vendor facets — Better Stack (status pages). A monitoring-plus-status-page product; on the Kin Score it
# touches one pointer check, status_page_present (6 pts). Headline: Better Stack's hosted status pages are a
# client-rendered shell that returns the SAME 200 for every path, so the pointer-liveness probe cannot prove
# the page exists — a *.betteruptime.com pointer grades dead (0), and only a custom status.* domain is
# rescued to unverified (0.5) by the scorer's SPA-shell host rule.
vendor: betterstack
name: Better Stack
website: https://betterstack.com
areas:
- status-page
registry_keys:
- betterstack
rubric_schema_version: 0.22.0
generated: '2026-09-25'
features_refreshed: '2026-09-25'
basis: capability
summary: >-
  Better Stack touches one Kin Score check, status_page_present, and today earns at most half of it. Its
  status pages answer any path with an identical 200 page, which the pointer-liveness probe reads as a
  soft-404: all 6 *.betteruptime.com status pointers in the catalog grade dead (0 points), and a custom
  status.yourdomain.com page is graded unverified (3 of 6) only because the scorer excuses status.* hosts
  as SPA shells. A provider on Better Stack should put the page on a status.* custom domain and declare
  it. The Better Stack MCP server, subscriber notifications and maintenance windows score nothing for
  the provider.
features:
- id: hosted-status-page
  name: Hosted status page on a *.betteruptime.com subdomain
  description: >-
    Status pages with sections of monitors and heartbeats, served on a *.betteruptime.com subdomain by
    default; private pages with password, SSO or IP protection are available.
  source: https://betterstack.com/docs/uptime/getting-started-with-status-pages/
  tier: all
- id: custom-subdomain
  name: Custom domain (status.yourdomain.com)
  description: A CNAME to statuspage.betteruptime.com serves the page on the provider's own status.* host.
  source: https://betterstack.com/docs/uptime/custom-subdomain/
  tier: unknown
- id: catch-all-shell
  name: Same 200 page for every path (measured)
  description: >-
    Probed 2026-09-25: bitpowr.betteruptime.com and status.betterstack.com return a byte-identical 200
    for the page and for a nonsense path, so the host cannot be told apart from a catch-all.
  source: https://bitpowr.betteruptime.com
  tier: all
- id: status-reports
  name: Status reports, updates and maintenance
  description: >-
    Automatic or manual status reports with updates through resolution, subscriber notification from the
    Small Team plan on, and a custom sender domain for update emails.
  source: https://betterstack.com/docs/uptime/creating-status-report-and-status-update/
  tier: paid
- id: page-customization
  name: Branding, response-time charts, multi-language, email subscriptions
  description: >-
    Custom CSS, dark mode, response-time charts and custom metrics, translations, and email subscriptions
    per page or component.
  source: https://betterstack.com/status-page
  tier: all
- id: betterstack-mcp
  name: Better Stack MCP server (mcp.betterstack.com)
  description: >-
    Remote MCP server, OAuth or API token, that manages the provider's Better Stack account — monitors,
    incidents, status page reports, logs.
  source: https://betterstack.com/docs/getting-started/integrations/mcp/
  tier: all
maps:
- feature: custom-subdomain
  check: status_page_present
  layer: composite
  credit: 0.5
  conditional: true
  condition: >-
    Only on a custom domain whose host begins with `status.`. The default *.betteruptime.com pointer earns
    0 (see earns_nothing).
  provider_must: Serve the page on status.<own-domain> and declare it in apis.yml as common[].type StatusPage.
  note: >-
    The check is binary but its pointer is liveness-graded (derive-pointer-liveness.py): live 1.0, unverified
    0.5, dead/soft-404 0. Better Stack pages are soft-404 everywhere; SPA_SHELL_PREFIXES turns a status.*
    soft-404 into unverified, which is the 0.5 here. Arguably the rule should know the vendor (a JSON
    status endpoint would discriminate) — until it does, 0.5 is what the score reads.
  catalog_pass_rate: 0.125
  facet: operational_transparency
  points: 6
  baseline_pass_rate: 0.376
earns_nothing:
- feature: hosted-status-page
  check: status_page_present
  why: >-
    A *.betteruptime.com pointer is a soft-404 on a host the SPA rule does not excuse, so it grades dead:
    6 of 6 such pointers in the catalog earn 0 of 6 points today.
- feature: betterstack-mcp
  check: mcp_server
  why: >-
    It manages the provider's Better Stack account for the provider's own team. The dimension reads an
    MCP server for the provider's API, described in the provider's mcp/ manifest; this is neither.
out_of_reach:
  checks:
  - change_log_present
  - deprecation_policy
  - roadmap_present
  - rate_limits_documented
  - webhooks_advertised
  note: >-
    Status reports are not a change log, and nothing on a status page documents the API's limits, deprecations
    or its own webhooks.
unscored_practice:
- feature: status-reports
  why: Incident and maintenance communication with subscriber notification; no check reads it.
- feature: page-customization
  why: Per-component response-time and uptime charts; no check reads published uptime.
surface:
  operational_transparency:
    reachable: 3.0
    total: 38
  agent_readiness:
    reachable: 0
    total: 139
hard_rule: >-
  A model, not a score. Adopting this vendor changes a provider's Kin Score only when the provider publishes
  the resulting artifacts on its own surface; nothing here writes a score, and no sponsorship or partnership
  can.
method: searched
source:
- https://betterstack.com/docs/getting-started/integrations/mcp/
- https://betterstack.com/docs/uptime/creating-status-report-and-status-update/
- https://betterstack.com/docs/uptime/custom-subdomain/
- https://betterstack.com/docs/uptime/getting-started-with-status-pages/
- https://betterstack.com/status-page
- https://bitpowr.betteruptime.com
measured:
  cohort:
    method: vendors-catalog.json detections (CNAME / header / URL shape / markup), never a name match
    detected: 0
    in_baseline: 0
  control:
    basis: providers earning contract_present + documentation_present + api_reference_present, minus the
      cohort
    n: 5216
  metric: >-
    cohort_pct / control_pct = mean share of the check's points earned (derived and platform credit weighted),
    x100
  measured_on: '2026-09-25'
  status: 'not measurable: 0 detected customers clear the baseline (need 20)'
simulation:
  simulated_on: '2026-09-25'
  rubric: 0.23.0
  population: providers publishing a contract (contract_present earned), replayable exactly
  providers: 8977
  providers_unreplayable: 987
  providers_moved: 0
  conditional_rows: excluded (they depend on what the API already does)
  composite_lift:
    median: 0.0
    p75: 0.0
    p90: 0.0
    max: 0.0
    mean_among_movers: 0.0
  agent_readiness_lift:
    median: 0.0
    p75: 0.0
    p90: 0.0
    max: 0.0
    mean_among_movers: 0.0
  facet_lift_median_among_movers: {}
  composite_band_moves: {}
  agent_readiness_band_moves: {}
  method: >-
    each provider's own kin/checks file, the vendor's maps at their stated credit, the scorer's composite
    formula; from -> to, nothing written