Business Metric Instrumentation
Emitting metrics for business outcomes — orders, payments, signups — alongside technical telemetry, so incidents can be detected and prioritised by impact.
Technical metrics answer whether the system is working. Business metrics answer whether the business is working, and there are failures where the first stays green and the second does not.
The canonical case: a change breaks the checkout button in one browser. Error rates are normal, latency is normal, every instance is healthy — and orders drop 30%. Only the business metric detects it, and usually it is detected by the business rather than by engineering.
What to instrument: the small number of events that constitute the product working — orders placed, payments succeeded, signups completed, messages delivered, searches returning results — as counters, with enough dimensions (region, platform, tier) to localise a problem and few enough to keep cardinality sane.
Alert on anomalous drops, compared against the same period last week rather than against a fixed threshold, because these metrics are strongly seasonal.
Two further benefits. Business metrics make incident severity obvious — "orders down 30%" is understood by everyone and needs no translation. And they connect engineering work to outcomes: demonstrating that a latency improvement moved conversion is the argument that funds the next one.