/health Contract

Every harnessed site exposes GET /health. This is the single source of truth for the contract; harness.shwrk.com publishes this file byte-for-byte.

Response

GET /health returns HTTP 200 with a JSON body:

{
  "status": "ok",
  "service": "<name matching wrangler.toml>",
  "commit": "<git SHA stamped at deploy time>",
  "version": "<package/app version>",
  "timestamp": "<ISO 8601>",
  "checks": { "<dependency>": "ok" }
}

Field	Type	Meaning
`status`	`"ok"` \	`"degraded"` \	`"down"`	overall health
`service`	string	must match the `name` in `wrangler.toml`
`commit`	string	git SHA stamped at deploy time (see below)
`version`	string	package/app version
`timestamp`	string	ISO 8601 time the response was generated
`checks`	object	per-dependency `"ok"` \	`"fail"` (KV, D1, upstream APIs); `{}` if none

Rules

Non-ok status → HTTP 503. A plain status-code poll is therefore sufficient for the status dashboard (200 = up, anything else = down).
Commit SHA is stamped at deploy time. Workers Builds exposes the commit; inject it into the Worker (e.g. --var GIT_SHA:$WORKERS_CI_COMMIT_SHA, or a build-time define). Falls back to "dev" locally.
Respond in < 1s. Dependency checks must be cheap (e.g. a KV read of a known key) — never expensive queries.
checks is {} when the service has no external dependencies.

Status → HTTP code

status	HTTP
`ok`	200
`degraded`	503
`down`	503

See templates/health/typescript.ts for the reference implementation.