ByteBite Docs
Operations

Operations Overview

Observability, health checks, and operational foundations.

Operations Overview

This page covers application-level observability foundations. Infrastructure operations (upgrades, backups, validation) are documented in Infrastructure.

Observability

  • Sentry is the error-monitoring foundation (packages/observability). Sentry is optional in local development: without a SENTRY_DSN, initSentry is a no-op. Production must provide a DSN. Additional uptime monitoring is planned.
  • Structured logging uses pino (packages/observability). Logs are JSON in production and pretty-printed in development.

Full infrastructure observability inventory (including gaps): Observability.

Health checks

The API exposes:

  • GET /health — simple liveness, returns { "status": "ok", "service": "bytebite-api" }.
  • GET /health/db — database connectivity probe. Does not expose connection information. Returns status: "ok" or "degraded".

Docker health checks are configured for PostgreSQL and MinIO. The API container starts only once PostgreSQL is healthy. Direct liveness: GET /health on http://api.bytebite.test or same-origin http://<app-host>/api/health.

The API does not auto-migrate on startup. Use pnpm db:migrate while the stack is running.

Smoke test commands: Validation.

Background jobs

The 10-minute order acceptance timeout (ADR-016) will be handled by a DB-backed scheduler, not BullMQ/Redis. That job is implemented during feature work; there is no placeholder module in the bootstrap tree.

Data retention

A technical retention/anonymization strategy is planned (ADR-009). Concrete retention periods must be legally reviewed before go-live.

Infrastructure operations

TopicPage
Recurring maintenanceOperations
Smoke testsValidation
Failure recoveryDisaster recovery
Known gapsKnown gaps

On this page