The record of a meaningful moment in a business process, in plain English, and why it sees what infrastructure monitoring cannot.
Most monitoring answers one question: is the plumbing healthy. CPU, memory, error rates, whether the API returned a 200. All useful, and all silent on the thing your leadership team actually cares about, which is whether the customer got what they came for. A business event is how you close that gap. It is not a new tool to buy, it is a shift in what you choose to record. Here is what a business event is, in plain English, with a worked example from my own demo account, and where it stops short.
What is a business event?
A business event is a record of a meaningful moment in a business process, not a technical metric. Not "CPU at 80%" and not "the API returned 200", but "application submitted", "documents checked", "credit check passed", "account opened". Each event carries business context with it: the fee, the product, and a correlation ID that ties every step back to one specific customer doing one specific thing.
Dynatrace calls them "bizevents", but the idea is not vendor-locked. The point is the same wherever you meet it: you are instrumenting the outcome the customer feels, not just the infrastructure underneath it.
From events to a flow
One event on its own is just a data point. The value arrives when you stitch thousands of them together. Group the events by correlation ID and you can reconstruct the actual path customers took through a process. The boxes are the steps, the arrows are the route people travelled. You stop asking "is the server up" and start asking "of everyone who tried, how many got through, where did they fall out, how long did it take, and what did it cost us".
One customer journey, four business events. Each records a meaningful business moment; one correlation ID threads them into a single, followable journey.
Where the data comes from does not much matter to the outcome: business events can be captured from application traffic, sent in through a pipeline or via OpenTelemetry, or emitted by the apps themselves, then stored and queried like any other data.
Under the hood: each service passes the trace context on, and the business event is emitted with the same trace ID, so it lands on the same thread as the spans and logs.
A worked example, from my own demo account
Here is one I can show you. This is a financial services account-opening flow over three days, taken from my own demo environment, so the numbers are illustrative of the pattern rather than anyone's production book.
Roughly 1,030 account-opening journeys were completed, generating about £77.55K in account fees, with an average journey time of just under six hours end-to-end.
At the "documents checked" step, documents were typically re-checked one to three times before they passed. That loop is visible in the flow, not buried in a log somewhere.
The headline: of 319 "errors", 302 were business exceptions, not technical failures. A business exception is a rule-based rejection, a failed credit check or a missing or invalid document. That is an expected business outcome, not a system bug.
350 people dropped at the credit-check stage: they started and did not finish.
Read that middle line again, because it is the whole point. The system is not broken. Customers are being stopped by the business rules. Infrastructure monitoring would show you green dashboards all the way through and tell you nothing was wrong.
What business events do well
They measure the promise, not the plumbing. Did the customer actually open the account, and if not, where did they fall out. That is the question a board asks, answered in the same platform your engineers already use.
They separate a business exception from a technical error. "Working as designed, customer rejected by a rule" and "the system failed" look identical to infrastructure monitoring. Telling them apart changes what a leadership team does next.
They put a number on the leak. Dropped journeys and abandoned applications become lost fees you can quantify, not a vague sense that "conversion could be better".
The honest ledger
You have to define what matters first. Business events do not appear on their own. Someone has to decide which moments in the process are worth recording and add the instrumentation. The tool captures the plumbing for free; the meaning is still your work.
Correlation is only as good as your IDs. The flow reconstruction depends on a correlation ID threading every step. If your systems do not carry one cleanly across hand-offs, the picture has gaps.
It is a complement, not a replacement. You still need the infrastructure signals underneath. A business event tells you customers are dropping at credit check; you still need the traces and logs to find out why when the cause is technical rather than a rule.
So, are business events for you?
If you run a customer-facing process with clear steps and a clear outcome, an application, a checkout, an onboarding, a claim, business events are one of the highest-leverage things you can add, because they speak the language the business already cares about. If your estate is mostly internal plumbing with no obvious customer journey, the payoff is smaller and you are better off getting your infrastructure signals solid first. Either way, hold on to the distinction that does the work: your dashboards being green does not mean your promise is being kept. That is the gap business events are built to close.
Seen this yourself? Green dashboards, but customers still dropping out? | |
I would like to hear it, especially from anyone running a real customer journey through this. Book a slot and tell me what you found.
Prefer to read first? Start with a free chapter of Metrics & Mayhem. |
Sources / further reading
Dynatrace Docs, business events: https://docs.dynatrace.com/docs/analyze-explore-automate/business-analytics
OpenTelemetry, events and logs: https://opentelemetry.io/docs/specs/otel/logs/
Worked example: Allan's own Dynatrace demo environment (illustrative, not a production book)