Connecting Client Errors to Backend Diagnostics
Correlation identifiers, structured logs and telemetry in Culina's web-to-API workflow.
An error message is the start of an investigation
A user sees a failed action in a browser. The cause might sit in request handling, persistence, media storage or another integration. A useful diagnostic path needs to connect the visible failure to the backend work that accompanied it.
Culina carries correlation identifiers on browser requests to help make that connection. The identifiers provide a way to relate client failures to backend diagnostics, rather than relying only on an approximate timestamp and a description of the screen.
Give each signal a role
Culina’s observability tooling includes OpenTelemetry, Serilog and Seq, with Grafana, Prometheus, Loki and Tempo covering monitoring concerns. The value lies in connecting signals to a concrete question, not in the number of services in the stack.
For an investigation, structured logs can describe events associated with a request. Traces can help examine instrumented work across boundaries. Metrics can reveal whether a problem appears isolated or part of a wider pattern. A correlation identifier helps navigate related evidence; it does not automatically establish complete tracing coverage.
Health checks provide another signal. They help determine whether the application is ready or responding, but a passing health check cannot establish that every recipe, cookbook or media workflow succeeds.
Keep local diagnosis close to development
Culina’s Docker Compose setup supports local backend development with PostgreSQL and Seq. That gives developers a place to inspect structured application output while exercising use cases. The deployed environment adds the broader monitoring stack around the same need to understand application behavior.
Elysion and Muninn also include OpenTelemetry, structured logging, Seq and health checks in their documented engineering setup. Their specific product boundaries still matter: a document conversion workflow and an encrypted synchronization request need different diagnostic context.
Context should not become content logging
Muninn’s journal data makes the distinction especially clear. Diagnosing an operation does not require treating private entry text as routine log data. As a design principle, operational context should help locate a failing operation without casually duplicating sensitive payloads into another storage system.
The practical goal is an explainable path from a reported action to relevant evidence. The documented tooling establishes the components of that path; it is not a claim of measured uptime, complete instrumentation or a particular incident outcome.