Monitoring and reconciliation
An event log connects API, workers, relayer and dashboard. Events provide observability; the chain determines the financial result.
What to observe
| Source | Signals |
|---|---|
| Crosschain | States, hashes, attestations, uncertain attempts. |
| Vault | Disbursements, pauses, budget and limits. |
| Relayer | Transaction status and native gas by network, including MON. |
| API / worker | 5xx errors, memory, event loop, queues and persistence. |
| QR mock | Issuance and simulated confirmation; never bank evidence. |
Channel and access
The backend pushes signed events to the site with an increasing sequence and validity window. Reading and writing use separate secrets. The browser does not receive backend keys. /v1/monitor/stream provides SSE with after or Last-Event-ID for resumption.
Retention and lost events
| Events | What happens |
|---|---|
| Already delivered to every configured destination | Pruned after MONITOR_RETENTION_DAYS (14 by default). |
| Pending for a configured destination | Kept; from the retention on MONITOR_BACKLOG_RETAINED is raised. |
Pending longer than MONITOR_PENDING_MAX_DAYS (90) | Pruned, and the loss is explicit: a monitor.gap event, the MONITOR_SINK_GAP alert and a gap in the next delivery. The dashboard shows how many events and which positions. |
There is never a silent success: a dashboard that comes back within 90 days gets everything it missed. A destination that is no longer configured keeps nothing. It concerns the monitor, not receipts or balances.
Documented operations status
The 13 October log records monad-testnet-relayer events and Monad resources in the dashboard. The view separates testnet and mainnet. The web monitor cache remains in memory: restarts and multiple instances require appropriate persistence. Webhook reception for each mainnet relayer must be verified in its deployment.
Availability depends on your instance. Check /health and /v1/routes before integrating.