Health, metrics, and logs answer different questions

What the public implementation shows

The gateway exposes health checks, Prometheus metrics, structured log services, dashboard endpoints, and operational query APIs as distinct surfaces.

Process and dependency readiness, aggregate behavior, and transaction-level evidence are not collapsed into one dashboard response. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleObservability works when each signal has a defined question and owner.

The decision behind the mechanism

Separate surfaces let automation consume health, monitoring systems consume metrics, and authorized operators investigate detailed records.

A single green health endpoint can hide growing recovery queues, while logs alone cannot provide reliable service-level trends. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Keep liveness narrower than readiness.
• Use bounded metric labels.
• Structure logs with correlation and financial identifiers.
• Restrict detailed operational queries by role.

How the control should be operated

Each signal should define freshness, cardinality, retention, access, alert thresholds, and the operational response it supports.

Operators can move from detection to diagnosis without using a high-cardinality transaction store as a monitoring system. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.