Check application health

Check the app's intended behavior as well as its deployment receipt. Start with read-only evidence. Use the app's access boundary when interpreting responses.

Identify the app in the inventory and find the latest successful deployment run. Check subsequent failed or partial runs too. Record its commit, Worker names, and deployment receipt identifiers.

Use the app-specific evidence in the table. For gateway-owned ingress and auth readiness, these read-only requests are useful starting points:

curl --fail --max-time 20 https://stormtrust.net/.well-known/stormtrust-gateway
curl --fail --max-time 20 https://auth.stormtrust.net/health
curl --fail --max-time 20 https://ui.stormtrust.net/health.txt

If a response fails, inspect the selected Worker's logs and its backing resources. With approved Cloudflare read access and installed app tooling, tail a Worker explicitly:
```
bash scripts/apps/pnpm.sh data exec wrangler tail stormtrust-data --format json
```
Correlate timestamps and request identifiers with the deployment. Keep credentials, session tokens, and sensitive application payloads out of shared incident records.
Compare the outcome with the latest release and any dependency changes. Check failed stages and drift issues before concluding that source code caused the incident. Follow Recover a release when a retry or correction is needed.

Evidence by application

The existing post-deployment checks live in scripts/apps/smoke/. These checks have different scope; there is no universal readiness endpoint.

App	Existing deployment check	What still needs separate evidence
`app`	Receipts for its eight private Workers	Authorized sign-in, tenant access, and the affected command-center journey
`assets`	Versioned stylesheet contents, cache, CORS, and resource-policy headers	Consumers loading the intended immutable version
`auth`	`/health` reports `ok: true` and `database: "ok"`; monitor ingress returns `302` or `403`	Sign-in and recovery journeys; email delivery when relevant
`data`	Worker deployment receipt	Source freshness, ingestion and revision queues, dead-letter work, and consumer reads
`developers`	Homepage contains `StormTrust developer documentation`	Changed pages, assets, Markdown twins, and agent-readable content
`gateway`	Diagnostic responses for configured smoke-test hosts, canonical redirect, and monitor route ownership	Authorized and unauthorized behavior of the changed route
`hail-alerts`	Unauthenticated root returns `302` or `403`	Authenticated simulation/replay behavior; Access denial does not prove app readiness
`pioneer`	Stateful live acceptance proof	Production proof results and correlated structured logs; a root Access response alone is insufficient
`ui`	`/health.txt` contains `StormTrust UI laboratory`	The affected component and consumer contract
`www`	Both website hostnames serve expected HTML without attachment headers	The changed user journey and data dependency

The public gateway diagnostic proves routing, not downstream readiness. The app and data receipt checks do not exercise their live APIs. New plain Workers also default to receipt-only verification until a useful probe exists.

Checks with side effects

Do not run every smoke script as a read-only health sweep. Auth's smoke script also reconciles an Email Sending subscription. Pioneer's live proof writes D1 and R2 test data, sends queue work, exercises an intentional failure, and acknowledges its matching dead-letter message.

Pioneer's dedicated pioneer-canary.yml workflow runs daily and supports manual dispatch from trusted main. It requires PIONEER_CANARY_TOKEN. Use that workflow for its controlled production proof rather than copying its mutation commands into a general health probe.

Coverage gaps

The repository has no shared make app-health command, complete read-only readiness suite, or single dashboard proving every app is healthy. Treat new health endpoints, alert thresholds, and incident ownership assignments as implementation work, not established guarantees.