The problem in plain language
Dashboards say the API is up and the integration platform is running. Yet a customer order never reaches fulfilment, a lead never arrives in CRM or an invoice never reaches finance.
The failure is usually discovered by the wrong person at the wrong time: a customer asking where an order is, a salesperson wondering why a lead was never assigned, or a month-end reconciliation that does not balance. By then the technical evidence may be days old, and the team must reconstruct what happened across several systems that each insist they were working correctly.
What the buyer is actually trying to solve
Searches such as “integration monitoring end to end”, “API healthy but transaction failed” and “business transaction monitoring” reflect a need to prove completion, not merely component uptime.
Evidence and system mechanism
Azure Application Insights documents end-to-end transaction diagnostics that correlate requests, dependencies and exceptions across monitored components. Its dependency tracking can associate failed downstream calls with originating requests. The same documentation includes an important caveat: where sampling is enabled, the portal views show the telemetry retained after sampling rather than every item the application emitted. Correlation is powerful, but it shows what was instrumented and kept.
OpenTelemetry defines telemetry conventions for messaging systems, covering spans, metrics and exceptions for platforms such as Kafka, RabbitMQ, Amazon SQS and SNS and Azure Service Bus. Those conventions are still marked as in development, which is itself a reminder that tracing across asynchronous messaging is less mature than tracing a synchronous API call.
Messaging platforms also make failure quiet by design. Microsoft's documentation on Service Bus dead-letter queues explains that a message which exceeds its maximum delivery count is moved to the dead-letter queue, that expiring messages are moved there when dead-lettering is enabled, and that there is no automatic cleanup: messages remain until someone explicitly retrieves them. The platform has behaved correctly. The business transaction has stopped. Nothing on a component-health dashboard needs to change colour.
The architectural point is that a business transaction often crosses several components. Each component can appear healthy while the overall transaction is delayed, rejected or stranded between systems. The related condition of failed integration messages that sit unnoticed is one of the most common ways this happens.
An illustrative example
Illustrative scenario, not a client case. An online order is accepted by the web shop, which calls the order API successfully. The API publishes a message for the warehouse system. The warehouse consumer rejects the message because a new product code is not yet in its catalogue, retries until the delivery limit is reached, and the message is dead-lettered. Every component reports healthy: the shop is up, the API returned success, the queue is available and the warehouse service is running. The customer has received an order confirmation. The order will not ship until someone notices.
Problem owner and why now
Integration leads and enterprise architects usually own the interface layer; the CIO or CTO often funds reliability. Urgency rises after an integration incident or when transaction volume makes manual reconciliation impractical. It also rises when a new system is added to a chain, a supplier changes an API version or a customer-facing commitment, such as same-day dispatch, depends on several systems completing in sequence.
Warning signs
- Integration incidents are reported by users or customers more often than by monitoring.
- Dead-letter or error queues are not monitored, or nobody knows who should empty them.
- Investigating one failed transaction requires searching several systems by hand.
- Each system uses its own reference number and there is no shared identifier.
- Integration alerts go to an individual mailbox, a condition examined in why integration failures should not route to personal inboxes.
Economic consequence
Incomplete transactions create investigation labour, customer delay, duplicate entry, missed revenue events and operational interruption. The cost can stay hidden when the technical platform reports availability but users discover the missing business outcome later. Unsafe recovery adds a second cost: a stranded transaction that is resubmitted without care can create a duplicate order, payment or invoice. Measure the effect from your own data—failed or delayed transactions per period, time to detection, time to resolution and manual corrections—rather than applying generic figures.
Root cause
Typical causes are component-level monitoring, missing correlation identifiers, unobserved message queues, weak retry handling, no definition of the final business success state and unclear exception ownership. The last two are the most important. If nobody has written down what “complete” means for an order, a lead or an invoice, no tool can alert when it has not happened.
Practical intervention
- Define the business transaction from trigger to final state.
- Assign a correlation identifier that survives system boundaries.
- Trace synchronous calls and asynchronous messages.
- Monitor failed and delayed messages.
- Define success as the business outcome, not only technical availability.
- Create exception ownership and safe recovery procedures.
- Measure completion latency and unresolved failures.
A practical complement to tracing is a completion check: a scheduled comparison that asks whether every transaction started in the source system has reached its final state in the target within an agreed time. It does not depend on perfect instrumentation and directly measures the outcome the business cares about. Recovery should be designed so that replaying a message cannot create duplicate work, as explored in how to design retries without creating duplicate work.
Trade-offs to manage
Full distributed tracing across every system is valuable but can be costly to instrument and store, and sampling reduces both cost and completeness. Completion checks are simpler but detect problems later and explain less about the cause. Most organisations benefit from combining the two: trace the most critical flows in depth, and run completion checks across the wider set so that nothing stalls silently.
Diagnostic questions
- Can one order or case be traced across every system it touches?
- What proves the final transaction completed?
- Who owns a failed integration message?
- Can failed transactions be recovered safely?
- Are business and technical dashboards looking at the same outcome?
- How long can a transaction remain incomplete before anyone is alerted?
What good looks like
Operations can start from a business transaction, see each dependency and message hop, identify where it failed and route the exception to a named owner without waiting for a user to report missing data. Dead-letter queues are watched and emptied by someone accountable, recovery is safe to repeat, and each critical integration has an operational owner, as argued in why critical integrations need a named operational owner.
Where Mellorca fits
Mellorca can inventory integrations, define transaction contracts and ownership, implement observability and recovery patterns, and establish managed monitoring around critical interfaces.
Commercial next step
Discovery article → integration observability diagnostic → transaction map → monitoring and recovery design → implementation → managed operations.
Sources and further reading
- Investigate failures, performance, and transactions with Application Insights - Azure Monitor (last verified 10 October 2026)
- Dependency Tracking in Application Insights - Azure Monitor (last verified 10 October 2026)
- Service Bus Dead-Letter Queues - Azure Service Bus (last verified 10 October 2026)
- Semantic conventions for messaging systems (last verified 10 October 2026)
Related Mellorca reading
- Why Integration Incidents Require Several Vendors to Diagnose
- API credentials are shared across unrelated integrations
- Why teams cannot trace one business transaction across several systems