# Vendor facets — Instatus. A static/CDN status page product with monitoring and on-call; on the Kin Score it
# touches one pointer check, status_page_present (6 pts). Headline: Instatus pages answer every path with the
# same 200 page, so the pointer-liveness probe grades the free-plan *.instatus.com pointer DEAD — 30 of 32
# such pointers in the catalog earn 0 — and a Pro custom status.* domain is rescued only to 0.5.
vendor: instatus
name: Instatus
website: https://instatus.com
areas:
- status-page
registry_keys:
- instatus
rubric_schema_version: 0.22.0
generated: '2026-09-25'
features_refreshed: '2026-09-25'
basis: capability
summary: >-
  Instatus touches one Kin Score check, status_page_present, and is the clearest case in the area of a
  vendor's hosting costing its customers the point. Every Instatus page returns an identical 200 for any
  path, which the pointer-liveness probe reads as a soft-404: 30 of 32 *.instatus.com status pointers
  in the catalog grade dead (0 of 6 points). The free Starter plan has no custom domain, so a free customer
  cannot earn the check at all; on Pro a status.* custom domain is graded unverified, 3 of 6. Its broad
  subscriber channels (webhook, RSS/Atom, Slack, SMS) and public JSON are real practice no check reads.
features:
- id: hosted-status-page
  name: Hosted status page on a *.instatus.com subdomain
  description: >-
    Public status page with components, incidents and maintenance; the free plan is public-page only with
    no custom domain.
  source: https://instatus.com/pricing
  tier: all
- id: custom-domain
  name: Custom domain
  description: Serves the page on the provider's own host; 1+ custom domains on Pro, 3+ on Business.
  source: https://instatus.com/pricing
  tier: paid
- id: catch-all-shell
  name: Same 200 page for every path (measured)
  description: >-
    Probed 2026-09-25: appcharge.instatus.com, doppel.instatus.com and status.instatus.com each return
    a byte-identical 200 for the page and for a nonsense path.
  source: https://appcharge.instatus.com
  tier: all
- id: subscriber-channels
  name: Subscribers across email, SMS, webhook, Slack, Teams, Discord, Google Chat, X, RSS and Atom
  description: >-
    Signed JSON webhooks, RSS/Atom feeds and chat channels notified on incidents, maintenance and updates.
  source: https://instatus.com/help/status-page/subscribers
  tier: all
- id: instatus-api
  name: Management REST API and public summary.json
  description: >-
    api.instatus.com manages pages, components, incidents, maintenances and metrics; a public summary.json
    exposes current status.
  source: https://instatus.com/help/api
  tier: all
- id: monitoring-oncall
  name: Monitoring, on-call and Slack/Teams incident workflow
  description: Monitors, on-call and incident handling from Slack and Teams alongside the status page.
  source: https://instatus.com/
  tier: all
maps:
- feature: custom-domain
  check: status_page_present
  layer: composite
  credit: 0.5
  conditional: true
  condition: >-
    Only on a paid plan with a custom domain whose host begins with `status.`. The free *.instatus.com
    pointer earns 0 (see earns_nothing).
  provider_must: >-
    Serve the page on status.<own-domain> (Pro or Business) 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. Instatus pages are soft-404
    on every host; SPA_SHELL_PREFIXES excuses status.* hosts to unverified, which is the 0.5. Adding instatus.com
    to SPA_SHELL_HOSTS would lift the 30 dead pointers to 0.5, not to 1.0; only a discriminating probe
    (e.g. its summary.json) could prove the page live.
  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 *.instatus.com pointer is a soft-404 on a host the SPA rule does not excuse, so it grades dead:
    30 of 32 in the catalog earn 0 of 6 points. This is the only option on the free plan.
- feature: subscriber-channels
  check: webhooks_advertised
  why: >-
    Status-notification webhooks are the vendor's event stream about the page, not webhooks of the provider's
    API; declaring them as Webhooks would be a mis-declaration.
out_of_reach:
  checks:
  - change_log_present
  - deprecation_policy
  - roadmap_present
  - rate_limits_documented
  note: >-
    No change-log product for customers appeared on the pages fetched, and a status page publishes nothing
    about the API's limits or deprecations.
unscored_practice:
- feature: instatus-api
  why: Public machine-readable status (summary.json); no check reads it.
- feature: subscriber-channels
  why: RSS/Atom and webhook status feeds an agent could consume; unscored.
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://appcharge.instatus.com
- https://instatus.com/
- https://instatus.com/help/api
- https://instatus.com/help/status-page/subscribers
- https://instatus.com/pricing
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