Orchestration Analytics

There is no single orchestration dashboard. The numbers live on four surfaces, each answering a different question over a different window, and the most common mistake is comparing two of them and concluding one is wrong.

All four are live only. Sandbox payments are not routed, so they are excluded from every figure on this page, and the Orchestration section itself is available in live mode only.

The Overview, and what each figure counts

Pick a period of 7, 30 or 90 days. The figures can be up to ten minutes old; use the refresh control when you need the current value immediately.

Per connection, you get these figures, all computed from your own transactions in that period. The names are the labels the Dashboard shows.

Above the list, the same period is aggregated across every connection, plus two figures that only exist there. Average time is the average number of seconds between the payment being created and it being credited, so it measures the payer's whole journey including the time they spent looking for their phone, not the provider's response time. The trend shown with Transactions compares the transaction count against the immediately preceding period of the same length.

When a connection is called degraded

One rule decides the words and colours you see: green from 95 %, amber from 80 %, red below, and nothing below 5 payments. Each surface applies it on its own window.

Below the minimum, nothing is asserted. A grey cell or a missing badge means too little traffic to judge, not a problem.

The matrix, and the diagnosis it enables

The matrix puts your operator channels down the side and your connections across the top, and fills each cell from a rolling 15-minute window. It exists for one distinction that a per-provider list cannot make.

A whole row red means the operator itself is down. Every connection that reaches MTN Cameroon is failing, so there is nothing to reroute to, and the answer is to wait or to stop offering that channel until it comes back.

One cell red while its neighbours hold means your path to that operator is the problem, not the operator. The traffic can be saved, because another connection on the same row is working. This is exactly the case the cascade handles on its own, and the case where a policy on that channel pays off immediately: Max acceptance, or a minimum health, puts the failing connection behind the working one on this channel only.

Each cell also shows whether that route's circuit is open, which explains a connection that appears to be receiving no traffic at all. When the connection's credentials are missing or rejected, the cell turns red and shows Connection refused in place of the circuit badge.

What the cascade recovered

The single figure that justifies orchestration is on the Overview, over the last 7 days: the number of payments a fallback provider charged after the one ranked before it failed on the path, with their volume. Only failovers inside one routing decision count: a payer who tried again on their own after a decline started a new decision, and is not counted.

Each of those is a payment that would have been lost on a single-provider integration. The panel also shows the volume that ran through channels currently flagged as degraded, which is the exposure you are carrying right now rather than a result you have already banked.

The advisor, and which of its findings move the needle

The Overview reads your matrix and raises findings, sorted by severity and by the volume at stake. They are deterministic, computed from your own data, and every number in them is one you can check.

The one that always leads to a real change is the single path warning: one channel, one connection, no fallback, and the volume that would stop if it failed. Connecting a second provider for that channel is the fix, and it is the single highest-value action in the whole module.

The operator down finding is informational and correctly so. Nothing you configure will fix an operator outage.

The remaining finding names a connection failing on a channel while another one is healthy, and points at that channel's policy on the Matrix page: set it to Max acceptance, or give it a minimum health, and the failing connection is tried after the healthy one on that channel only. On every payment on the channel, Wajub applies the policy to the connections no routing rule placed. Raising the connection's priority instead would move it on every channel.

Reading one decision, or filtering many

Konsole's routing log holds one entry per charge attempt: one per call to POST /payments/{id}, so a payer who tried twice on the same payment leaves two. Filtering it is how you answer questions the aggregates cannot.

Selecting a row opens every candidate and why it was placed, alongside the attempts that followed it: each candidate that was tried shows its outcome and its latency. That pairing, the decision next to what happened, is the only place the two are shown together.

Alerts

Orchestration, Alerts watches a figure for you and tells you when it crosses a line. Wajub evaluates every rule every 5 minutes, on live payments only.

A channel scope counts the payments charged on that channel, a payment sent on mobile or cm.mobile counting under the operator it resolved to. A rule scope counts the payments that rule routed. The scope only narrows the payment metrics. The webhook metrics count every delivery to your own endpoints, and the funnel metric every payment page opened. A Slack or webhook target receives a JSON body with rule_id, rule_name, observed_value, context and fired_at. The last 20 alerts that fired are listed on the same page.

What is not measured

Knowing where the gaps are saves you looking for exports that do not exist.

Cost is an input, not an output. The negotiated rate you enter on a connection is used to find the cheapest connection for each payment, and it is not aggregated back into a cost per transaction or a spend comparison anywhere in the product. If you need that, compute it from your own transaction exports and the rates you entered.

None of this is on the API. There is no endpoint for provider statistics, routing decisions, matrix cells or advisor findings, and no CSV export of them. Orchestration analytics are read in the Dashboard and in Konsole.

Sandbox contributes nothing. No decision is recorded, no attempt is counted, no cell is updated. A quiet matrix on a busy test account is expected.