# Vendor facets — PagerDuty Status Pages. The status-page add-on to PagerDuty's incident platform (this profile
# covers Status Pages only); on the Kin Score it touches one pointer check, status_page_present (6 pts).
# Headline: PagerDuty status pages return the same 200 for every path, so the default *.trust.pagerduty.com
# pointer grades dead (0) and a custom status.* domain is rescued only to unverified (0.5).
vendor: pagerduty
name: PagerDuty Status Pages
website: https://www.pagerduty.com
areas:
- status-page
registry_keys: []
rubric_schema_version: 0.22.0
generated: '2026-09-25'
features_refreshed: '2026-09-25'
basis: capability
summary: >-
  PagerDuty Status Pages touch one Kin Score check, status_page_present, and today earn at most half of
  it. The hosted pages answer any path with an identical 200 page, which the pointer-liveness probe reads
  as a soft-404: the default subdomain.trust.pagerduty.com pointer grades dead (0 of 6 — both such pointers
  in the catalog), and a custom status.* domain is graded unverified (3 of 6) only because the scorer
  excuses status.* hosts as SPA shells. No vendor-registry key detects it. Subscriber webhooks, maintenance
  posts and uptime metrics score nothing.
features:
- id: external-status-page
  name: External (public) status page on subdomain.trust.pagerduty.com
  description: >-
    Public page built on business services with incident and maintenance posts, 90/30/7-day uptime metrics
    and resolved-incident history; plan-limited pages and subscribers, private and audience-specific pages
    via add-on.
  source: https://support.pagerduty.com/main/docs/external-status-page
  tier: paid
- id: custom-url
  name: Custom URL on the provider's own domain
  description: >-
    After publication, DNS records verify a custom domain for HTTP and mail; it cannot be changed once
    saved.
  source: https://support.pagerduty.com/main/docs/external-status-page
  tier: paid
- id: catch-all-shell
  name: Same 200 page for every path (measured)
  description: >-
    Probed 2026-09-25: cluely.trust.pagerduty.com/posts/dashboard and status.pagerduty.com return a byte-identical
    200 for the page and for a nonsense path.
  source: https://status.pagerduty.com
  tier: all
- id: subscribers
  name: Subscribers by email, Slack and webhook
  description: Up to 150,000 subscriptions per page; webhooks deliver JSON incident payloads.
  source: https://support.pagerduty.com/main/docs/external-status-page
  tier: paid
maps:
- feature: custom-url
  check: status_page_present
  layer: composite
  credit: 0.5
  conditional: true
  condition: >-
    Only on a custom domain whose host begins with `status.`. The default *.trust.pagerduty.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 pointer is liveness-graded: live 1.0, unverified 0.5, dead/soft-404 0. PagerDuty pages are soft-404
    on every host probed; SPA_SHELL_PREFIXES excuses status.* hosts to unverified, the 0.5 here.
  catalog_pass_rate: 0.125
  facet: operational_transparency
  points: 6
  baseline_pass_rate: 0.376
earns_nothing:
- feature: external-status-page
  check: status_page_present
  why: >-
    A *.trust.pagerduty.com pointer is a soft-404 on a host the SPA rule does not excuse, so it grades
    dead: 2 of 2 in the catalog earn 0.
- feature: subscribers
  check: webhooks_advertised
  why: >-
    Status-notification webhooks are PagerDuty's event stream about the page, not webhooks of the provider's
    API.
out_of_reach:
  checks:
  - change_log_present
  - deprecation_policy
  - roadmap_present
  - rate_limits_documented
  note: A status page publishes nothing about the API's changes, limits or deprecations.
unscored_practice:
- feature: external-status-page
  why: Published uptime percentages and scheduled-maintenance posts; no check reads them.
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://status.pagerduty.com
- https://support.pagerduty.com/main/docs/external-status-page
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