Orchestration Analytics

Where the routing numbers live, what each one counts, and over which window.

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.

Surface	Question it answers	Window
Orchestration, Overview	How has each connection performed for me	7, 30 or 90 days
Orchestration, Matrix	What is happening right now, per operator	Rolling 15 minutes
Overview, uplift panel	What has the cascade actually recovered	7 days
Konsole, Routing Log	Why was this exact payment routed this way	Per charge call

All four are live only. Sandbox payments never reach the orchestrator, so they are excluded from every figure on this page, and the Orchestration section itself is closed to a test key by route middleware.

The Overview, and what each figure counts

Pick a period of 7, 30 or 90 days. The page is cached for ten minutes, with a refresh control when you need the current value immediately.

Per connection, you get five numbers, all computed from your own transactions in that period.

total_transactionsintegeroptional

Live payments attributed to this connection in the period.

completed_transactionsintegeroptional

Of those, the ones that were actually credited to your balance.

success_ratepercentageoptional

Completed divided by total. This is an acceptance rate seen from your books, so a payer who abandoned the prompt counts against it.

total_volumeamountoptional

Credited volume for the period, in your base currency.

last_used_attimestampoptional

The most recent payment on this connection, which is how you spot a connection that has quietly stopped receiving traffic.

Above the list, the same period is aggregated across every connection, plus two figures that only exist there. avg_processing_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. trend compares the transaction count against the immediately preceding period of the same length.

Two success rates, two meanings

The Overview computes success from credited transactions, so an abandoned prompt lowers it. The live success rate the router uses as a scoring boost counts only path-side failures, so an abandoned prompt does not touch it. A connection can sit at 72 % on the Overview and still be scored as healthy by the engine, and both numbers are right.

When a connection is called degraded

Two thresholds decide the words and colours you see, and they sit on different windows.

Where	Data it needs	Verdict
Overview, attention banner	10 payments in the selected period	Degraded below 80 %
Provider page, health badge	5 payments in the last 24 hours	Green from 95 %, amber from 80 %, red below
Matrix, cell colour	5 attempts in the last 15 minutes	Green from 95 %, red below 80 %

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 the rolling 15-minute window the engine maintains while it routes. 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 raising another connection's priority pays off immediately.

Each cell also shows whether that route's circuit is open, which explains a connection that appears to be receiving no traffic at all.

What the cascade recovered

The single figure that justifies orchestration is on the Overview, over the last 7 days: the number of payments that needed more than one attempt and ended up credited anyway, with their volume.

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.

Read it next to your single-path warnings

A high recovery count on a channel that also carries a single-path warning is the strongest argument for connecting a second provider: the cascade is already saving payments where it can, and on that channel it has nothing to save them with.

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 findings suggest editing a cascade policy on the Matrix page. That policy does not currently change the order the router tries your connections in. The lever that does is the priority on the connection itself, on Orchestration, Providers, and a routing rule when you need the preference to depend on the channel, the currency or the amount.

Reading one decision, or filtering many

Konsole's routing log holds one record per decision, written the moment the candidate list is built. That is one record 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.

Filter	What it isolates
Outcome, fallback	Decisions where more than one candidate was ranked
Outcome, circuit skipped	Decisions where a route was out of rotation
Outcome, no candidate	Decisions where the list came back empty, the `422` cases
Channel	One operator rail at a time
Provider	Decisions where this connection was ranked first
Transaction reference	One payment, end to end

Selecting a row opens the full candidate list with each score, alongside the attempts that followed it. That pairing, the decision next to what happened, is the only place the two are shown together.

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 feeds the least-cost boost in the routing score, 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.