Observability

Prolifto uses structured logging, health endpoints, audit tables, and product analytics events. There is no dedicated APM or distributed tracing integration in the current codebase.

Logging

@prolifto/telemetry wraps pino:

• Development uses pino-pretty for readable output.
• Production emits JSON logs.
• LOG_LEVEL controls the level (fatal, error, warn, info, debug, trace, silent); the default is info.
• Errors are serialized with pino's error serializer.

Usage:

import { logger } from "@prolifto/telemetry";

logger.info({ orderId, organizationId }, "Order created");
logger.error({ error }, "Failed to confirm payment");

Include identifiers (organization, order, payment) rather than dumping entire objects. Never log secrets, API keys, session tokens, or full customer records.

oRPC logging

The oRPC base middleware logs the duration of every procedure at debug level. Errors in the OpenAPI and RPC handlers are logged at error level. Raise LOG_LEVEL="debug" locally when you need timing details.

Health checks

• Admin: GET /api/{organizationSlug}/health checks the database and storage. It returns ok, degraded (storage down), or down (database down).
• Storefront: GET /api/health calls the admin health endpoint through the SDK and returns 503 when the API is unavailable.

Use these endpoints for uptime checks and deployment verification.

Audit trails

Business history is stored in the database:

The order activity timeline combines status changes, payments, invoices, and returns into one view.

Debugging a production issue

1. Check the health endpoint.
2. Find the request in the logs by organization and entity ID.
3. Check the Inngest run for asynchronous steps.
4. Inspect the entity's activity timeline or audit table.
5. Check the provider dashboard (SMTP, Stripe, WhatsApp, storage) if the failure is external.
6. Reproduce locally with the same seed and configuration.

Related

• Background jobs
• Troubleshooting
• Deployment