Routing Log

A per-payment, after-the-fact record of which providers were considered, in what order, and why.

6 min read

Routing Log is a historical audit trail of routing decisions — not a live feed. Each payment produces one decision record: the ordered list of provider candidates the orchestrator considered, each one's priority tier and tie-break score, any providers skipped by the circuit breaker, and whether the country was blocked outright.

Routing Log vs Event Stream

Routing Log is a paginated list of RoutingDecision snapshots, refreshed on page load — you search it to understand a payment that already happened. To watch the same route.evaluated / provider.attempt.failed / route.fallback / provider.attempt.succeeded sequence arrive live, millisecond by millisecond, while a payment is in progress, use Event Stream instead.

Konsole·Log Explorer

status:5xx OR provider:"MTN MoMo"

24h

MethodEndpointStatusDurationProvider

POST/payments201412msMTN MoMo

GET/payments/trx.PVrU8x2k20088msMTN MoMo

POST/transfers202690msOrange Money

POST/payments4021203msWave

GET/balance20042ms—

POST/payments5005012msCinetPay

Filters

searchstringoptional

Transaction reference (partial match).

channelstringoptional

e.g. mobile_money, card, bank.

providerstringoptional

Filter by the winning provider.

date_start / date_enddateoptional

Inclusive date range.

outcomestringoptional

fallback (more than one candidate), circuit_skip (at least one provider was skipped), or no_candidate (no eligible provider was found).

What a decision record shows

candidatesarrayoptional

The ordered list actually tried. Each entry has provider_id/slug, rank, priority tier, tiebreak_score, and — if a rule contributed — rule_id/rule_boost, is_least_cost/cost_boost, and telemetry_boost.

circuit_skippedarrayoptional

Providers excluded because their circuit breaker was open for this team/channel, with the reason.

country_blockedbooleanoptional

True if the whole transaction was blocked by a team-level country restriction before any candidate was even loaded.

channel / currency / amountcontextoptional

The context the decision was computed for.

processingsarrayoptional

The actual attempt chain for the transaction (one row per provider actually tried), joined in from the payment's processing history.

Ranking is deterministic and priority-first: a candidate's priority tier fully dominates the order — a lower-priority provider is never tried ahead of a higher-priority one. The tiebreak_score (rule match + least-cost boost + live success-rate telemetry) only decides ordering within the same priority tier; among tied scores, selection is weighted-random by each provider's configured weight.

What it's for

Understand a decision: which providers were even eligible for this payment, and in what order were they ranked?
Confirm a rule is contributing: check whether a candidate's rule_boost is non-zero for the rule you expect to match — remember it only affects ordering within a priority tier, it never overrides priority itself.
Spot a stuck circuit breaker: a provider consistently appearing in circuit_skipped reveals a provider your team can't currently route to.

From routing to the API call

Routing Log tells you which providers were considered and in what order; to see the actual HTTP exchange with a provider or the final response you sent your customer, cross-reference the same transaction in API Logs.

Konsole OverviewThe developer cockpit at a glance.Event StreamWatch the same kind of decision arrive live, for a payment in progress.API LogsSearch your full request history.WebhooksManage endpoints, inspect deliveries, resend or test.OrchestrationHow priority tiers and tie-break scoring work.

Was this page helpful?

Edit this page on GitHub

Need help?

Troubleshooting Contact support GitHub Discussions Service Status