Activity

Every gateway failure, logged with reason and destination.

When a PIX payment fails, Bob tries the next gateway on the route, and Activity logs every attempt: transaction, amount, what failed, where it went and why. With history by period and a live mode.

Create account

Failovers with reason and destination

Per-route alerts with start and end

Live mode

Benefits

Failover feed

Every attempt on record: amount, the gateway that failed, where the payment was routed and why — timeout, HTTP 5xx.

Monitor alerts

Per-route monitors flag approval drops against the segment's baseline — with start, recovery and duration.

Webhooks and API

Failed webhook deliveries, paused channels and rate limits become events with a timestamp and context.

Capabilities

The audit trail of your payment operation, written in real time.

— Failovers, monitors, webhooks and API — four tabs, zero black box.

Resilience feed

What failed, where it went, and why.

The Failovers tab shows every payment that needed a failover: Routed or Not routed status, amount, the connection that failed, the destination and the last reason — HTTP 502, timeout at creation. Search by transaction, filter by period and follow it live.

The real reason behind every failure
Timeout, HTTP 5xx — the error the provider returned, not a generic "something went wrong".
Routed or not routed
You see what failover saved — and what had nowhere to go.

Bob's Activity screen with the failover attempts feed

Per-route monitors

Approval drops get a start, an end and a duration.

Every published route can have monitors with a threshold and window you define. When a segment's approval rate drops past the threshold, the alert lands in Activity — and stays active until recovery, with the incident duration on record.

Your threshold, your window
Deviation is measured against the segment's own baseline, over the window you configured.
From alert to recovery
Active or resolved, with timestamps and duration — the full history of the incident.