Observability — full-stack visibility, built in

Every component emits standard telemetry to a single collector, which fans it out to purpose-built backends — all viewed together.

• Traces — one request followed across the entire path, from the edge through the API to the query that served it, including AI and background-worker paths. Trace context propagates end to end using the W3C traceparent standard.
• Metrics — every component scraped on a fixed interval: core data health and connection use, request and error rates and latency across both API channels, edge metrics, and background workers (queue depth, processing time, retries). Rate, Errors and Duration are derived from the traces themselves.
• Logs — structured logs from every component, aggregated centrally and stamped with trace IDs.
• Continuous profiling — CPU, memory and allocation behaviour over time, so a performance regression can be traced to the exact function responsible.

Collecting four signals is common. Correlating them is where the time actually goes — and that is the part that is already done here:

• trace → logs — every log line for a span
• trace → metrics — that component's dashboard
• trace → profile — the flame graph for a span
• metric → trace — click a latency spike, land on a representative trace
• log → trace — follow one log line back to the full request

"Why was this transaction slow?" goes from a dashboard, to the offending trace, to its logs, to the profile of the responsible function — in clicks, not in an afternoon of lining up timestamps across four tools.

Everything. Not a sampled subset, and not just the easy parts:

• Edge — creates the root span for each request, propagates trace context, exposes connection and throughput metrics.
• API layer — connection, cache and authentication metrics; preserves trace continuity; returns a Server-Timing response header breaking down the server-side phases of your call.
• Operations console — a span tree per page render, correlated with data-layer timing.
• Core data layer — connection, replication and statement-level metrics, plus plans for slow queries.
• Background workers and AI services — fully traced, metered and profiled, with trace-to-profile correlation.

The same layer surfaces business metrics — transaction throughput, queue depth, reconciliation match rates, API latency percentiles — on dashboards that are provisioned for you.

Because processing, queuing and scheduling all happen within the platform core, operational and business signals come from one consistent source. There is no reconciling of numbers between a broker's dashboard, a scheduler's log and the ledger's own view of what happened.

• Zero-config to start — comes up with the platform.
• Self-hosted — telemetry stays inside your deployment. Nothing is shipped to a third party, which matters when your logs contain financial activity.
• Tunable — retention and storage location for each signal are configuration values: modest on a laptop, generous in production.
• Standards-based — OpenTelemetry throughout. Your telemetry is portable to your own central observability platform, so adopting LedgerFlow does not mean adopting our monitoring choices.

Because the platform is fully instrumented, you can measure your own calls instead of guessing at them. Send a request, read the returned trace identifier and the Server-Timing response header for a server-side phase breakdown, and — with operator access — open the matching end-to-end trace to see precisely how the call was handled.

This changes the shape of a production incident. Instead of a support ticket arguing about whether the problem is your side or ours, both parties look at the same trace. Latency has a source you can point to.