# 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.

1. Identify the app in the [inventory](/stormtrust/apps/) and find the latest successful deployment run. Check subsequent failed or partial runs too. Record its commit, Worker names, and deployment receipt identifiers.
2. Use the app-specific evidence in the table. For gateway-owned ingress and auth readiness, these read-only requests are useful starting points:  
```sh  
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  
```
3. 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:  
```sh  
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.
4. 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](/stormtrust/engineering/operations/recover/) 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.