Bridge Monitor
Track cross-chain bridge routes and the addresses that matter so delayed or stuck transfers show up before users escalate them.
Why teams use this monitor
Bridge issues are rarely “hard down.” They usually look like long pending times, incomplete route handling, or one side of the transfer lagging behind.
- Teams routing user funds across chains
- Support or ops teams handling stuck bridge tickets
- Projects depending on Stargate or Wormhole routes
Quick start in 5 minutes
- Pick one route that matters operationally, not every possible source/destination pair.
- Track the bridge contract or user-facing addresses you actually need to correlate.
- Set the stuck threshold slightly above the normal completion time for that protocol.
Configuration notes
| Field | What to know |
|---|---|
| bridgeProtocol | Only Stargate and Wormhole are supported here. Choose the route you actually operate. |
| trackedAddresses | These can be bridge contracts or user wallets. Use the smallest set that answers your support question. |
| sourceChainId / destChainId | Source and destination must differ. Model each operational route separately. |
| stuckThresholdMinutes | This should reflect expected completion time plus a buffer, not a generic one-hour default. |
Recommended thresholds and defaults
- Fast liquidity bridges often start around 30-60 minutes as a stuck threshold.
- If your route includes native rollup withdrawals, the threshold must match that much longer finalization profile.
- Track one route per monitor if different routes have different support expectations.
Ready-made examples
Stargate route monitor
A practical starting point for a high-volume liquidity bridge route.
Best for
Teams moving funds between Ethereum and Polygon through Stargate
- Ethereum -> Polygon
- 60 min stuck threshold
- Track Stargate contract
{
"name": "Stargate route monitor",
"bridgeProtocol": "stargate",
"sourceChainId": 1,
"destChainId": 137,
"sourceRpcUrl": "https://eth.llamarpc.com",
"destRpcUrl": "https://polygon-rpc.com",
"trackedAddresses": [
"0x8731d54E9D02c286767d56ac03e8037C07e01e98"
],
"checkIntervalSeconds": 120,
"stuckThresholdMinutes": 60
}Wormhole delayed transfers
Use a slower expectation profile for guardian-network routes.
Best for
Teams supporting Wormhole-based asset movement
- Ethereum -> Base
- 90 min stuck threshold
- Track Wormhole token bridge
{
"name": "Wormhole delayed transfers",
"bridgeProtocol": "wormhole",
"sourceChainId": 1,
"destChainId": 8453,
"sourceRpcUrl": "https://eth.llamarpc.com",
"destRpcUrl": "https://mainnet.base.org",
"trackedAddresses": [
"0x3ee18B2214AFF97000D974cf647E7C347E8fa585"
],
"checkIntervalSeconds": 180,
"stuckThresholdMinutes": 90
}User address bridge watch
Track an address pair tied to a user-facing transfer flow.
Best for
Support teams triaging delayed transfers for a specific wallet cohort
- Arbitrum -> Optimism
- Track user-facing address
- 45 min stuck threshold
{
"name": "User address bridge watch",
"bridgeProtocol": "stargate",
"sourceChainId": 42161,
"destChainId": 10,
"sourceRpcUrl": "https://arb1.arbitrum.io/rpc",
"destRpcUrl": "https://mainnet.optimism.io",
"trackedAddresses": [
"0x5fC2E691E520bbd3499f409bb9602DBA94184672"
],
"checkIntervalSeconds": 120,
"stuckThresholdMinutes": 45
}Alert example
Bridge transaction delayed
Bridge alert: a monitored transfer is taking longer than expected. Route: Ethereum -> Arbitrum Elapsed time: 78 minutes Suggested action: verify bridge status, liquidity, and whether the destination leg completed.
Troubleshooting
Transactions appear delayed but not truly stuck.
Raise stuckThresholdMinutes to reflect the normal bridge completion time for that route.
The monitor never sees transactions for a route you care about.
Check whether you should be tracking the bridge contract, the user wallet, or both.
The alert is operationally unclear.
Separate user-support routes from protocol-health routes so each monitor has one owner and one action path.