BDC Monitoring & Observability

As of 2026-05-29

Monitoring tells you if known signals are in bounds; observability lets you ask new questions when something unexpected happens — a BDC platform needs both, or the first sign of trouble is a user complaint or a surprise bill. Four signal domains: pipeline health (ran/succeeded/on-time), data quality+freshness (stale/broken numbers), performance (latency), consumption/cost (vs TCO, M032/M043) — each with its own threshold + owner; watching only "did the job run" misses three-quarters. Fail loud, not silent (M042) — silent failure lets bad data reach a decision; alerts must reach the right owner, not a dead inbox. Observability is the run-time assurance layer for design-time governance: lineage (M077) says where a number came from, observability says when it went stale; access (M081) defines who may act, observability detects the anomaly; agentic AI (M049) needs action auditability. Combine static thresholds (known) + anomaly detection (unknown, feeds cost M043 + security M090). Honest (§0i): reduces time-to-detect/resolve, doesn't prevent every incident.