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 / notifications

The 10-minute order acceptance timeout (ADR-016) is a DB-backed scheduler in the API process, not BullMQ/Redis. Each tick runs UPDATE … WHERE order_status = 'pending' AND acceptance_deadline_at <= now() and is idempotent. See Accept, reject & timeout. Kitchen status after accept (preparing / ready / completed) is operator POST writes, not a job. See Kitchen status.

Transactional SMS (Twilio) and e-mail (AWS SES) clients live in packages/notifications. Credentials are optional (same pattern as Sentry): empty SID/token/from → no send, no API-start crash. sendSms runs after successful Accept, Reject, Timeout, and kitchen Ready. Checkout, preparing, and completed do not send. sendEmail is unused (no customer_email on orders). A skipped or failed SMS does not roll back the order write.

There is no notification queue. An optional POST /webhooks/twilio/status stub verifies the Twilio signature when TWILIO_AUTH_TOKEN is set (otherwise 503; bad signature 401) and does not mutate orders. See Transactional notifications.

Data retention

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

Infrastructure operations