# Service status

> **Launch status:** use the exact environment health endpoints, external status publisher, and signed activation receipt delivered with onboarding. This static page never guesses live state from documentation publication.

This is the public, non-patient operational surface for the Chia Partner API. It deliberately reports only coarse component state. It never reports traffic, catalog items, care programs, partner events, request IDs, patients, purchases, orders, prescriptions, shipments, or clinical outcomes.

## Current components

| Environment | Required launch evidence |
|---|---|
| Sandbox | API/asset/care health receipt plus all three signed synthetic webhook acknowledgements |
| Production | API/asset/care health receipt, all three signed synthetic webhook acknowledgements, signed activation record, and authorized co-branded purchase acceptance test |

## Status vocabulary

After activation, Chia's approved status publisher must use only these component states:

- `Operational` — externally verified service objective is currently met.
- `Degraded performance` — the component is reachable but an objective is impaired.
- `Partial outage` — a bounded capability is unavailable.
- `Major outage` — the component is unavailable or Chia has failed it closed.
- `Maintenance` — a separately announced maintenance window is active.

Hosted care incidents take patient safety and continuity priority over partner availability. An outbound webhook delivery outage never blocks patient care. The partner continues scheduled catalog refreshes; production finance polling remains isolated from patient care and reads only immutable Finance releases.

## Incident updates

The production launch record binds this page to the approved external status publisher plus sandbox/production canary and paging evidence. A stale static build never overrides those runtime signals.

During an incident, use the named integration and security contacts, authenticated channels, hours, and acknowledgement targets from the signed onboarding receipt. This public page intentionally contains no personal email address, secret channel, tenant identifier, or credential.

## What the partner should do

- Treat a failed request according to its stable error code, `retryable` field, bounded retry guidance, and `Retry-After`; never infer a patient or business outcome from component status.
- Keep the last complete valid catalog only until its own earliest expiry. Status cannot authorize stale regulated content.
- Deduplicate signed synthetic webhook tests, acknowledge only after the durable no-op receipt commits, and never refetch catalog or finance because of an event.
- Escalate through the signed support route when the documented retry budget is exhausted.

See [Troubleshooting](https://partners.chia.health/docs/troubleshooting/), [Errors and retries](https://partners.chia.health/docs/errors/), and the [go-live checklist](https://partners.chia.health/docs/go-live/) for executable recovery rules.