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 aSENTRY_DSN,initSentryis 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. Returnsstatus: "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
| Topic | Page |
|---|---|
| Recurring maintenance | Operations |
| Smoke tests | Validation |
| Failure recovery | Disaster recovery |
| Known gaps | Known gaps |