Skip to content
Beskid Beskid

Beskid

Jump to a Beskid service

Beskid

Jump to a Beskid service

Check Health and Monitoring

Use separate release and deployment evidence for image identity. A health handler does not expose release manifest identity. Use the health response and monitoring timestamp only for availability evidence. Do not include cookies, tokens, or private response bodies.

Record the expected image identity from the release workflow. Record the deployment time from the production operator. Obtain monitoring access for the selected lane.

  1. Check Auth at /api/v1/health.
  2. Check Learn at /api/health.
  3. Check Tracker at /api/health.
  4. Check Nexus at /api/health.
  5. Check pckg at /health/ready.
  6. Check the Website at /.
  7. Compare the public check times with container health.
  8. Inspect the same deployment window at monitor.beskid-lang.org.
BoundaryHealthy evidenceNext diagnostic
WebsiteSuccessful HTTP status for /.Site container and proxy logs.
AuthSuccessful HTTP status for /api/v1/health.Auth volume, session configuration, and OAuth callback.
LearnSuccessful HTTP status for /api/health.One safe lesson check and runtime-kit evidence.
TrackerSuccessful HTTP status for /api/health.SQLite volume and Auth hub configuration.
NexusSuccessful HTTP status for /api/health.Proxy trust boundary and nexus-data.
pckgSuccessful HTTP status for /health/ready.PostgreSQL connectivity and artifact volume.

Every required route returns a successful HTTP status. Container and public evidence agree on the deployment window. Separate release and deployment evidence identifies the expected images.

If one boundary fails, preserve its correlation evidence and inspect only that service. If several services fail, inspect the proxy and shared lane first. Ask the production operator to restore the previous state when the deployment caused the failure. Repeat all checks after the operator completes recovery.

Review the service-specific contract.