Monitorización y conciliación
Un registro de eventos conecta API, workers, relayer y tablero. Los eventos ayudan a observar; la cadena determina el resultado financiero.
Qué observar
| Fuente | Señales |
|---|---|
| Crosschain | Estados, hashes, atestaciones, intentos inciertos. |
| Vault | Desembolsos, pausas, presupuesto y límites. |
| Relayer | Estado transaccional y gas nativo por red, incluido MON. |
| API / worker | Errores 5xx, memoria, event loop, colas y persistencia. |
| QR mock | Emisión y confirmación simulada; nunca prueba bancaria. |
Canal y acceso
El backend envía eventos firmados al sitio con secuencia creciente y ventana de validez. Lectura y escritura usan secretos distintos. El navegador no recibe claves del backend. /v1/monitor/stream ofrece SSE con after o Last-Event-ID para reanudar.
Retención y eventos perdidos
| Eventos | Qué pasa |
|---|---|
| Ya entregados a todos los destinos configurados | Se borran a los MONITOR_RETENTION_DAYS (14 por defecto). |
| Pendientes de algún destino configurado | Se conservan; desde la retención se levanta MONITOR_BACKLOG_RETAINED. |
Pendientes por más de MONITOR_PENDING_MAX_DAYS (90) | Se borran y la pérdida queda explícita: evento monitor.gap, alerta MONITOR_SINK_GAP y gap en el siguiente envío. El tablero muestra cuántos eventos y qué posiciones. |
Nunca hay un éxito silencioso: un tablero que vuelve antes de 90 días recibe todo lo que le faltaba. Un destino que ya no está configurado no retiene nada. Afecta al monitor, no a recibos ni saldos.
Estado operativo documentado
El historial del 13 de octubre registra eventos de monad-testnet-relayer y recursos de Monad en el tablero. La vista separa testnet de mainnet. La caché del monitor web permanece en memoria: reinicios y múltiples instancias requieren persistencia adecuada. La recepción de webhooks de cada relayer mainnet debe verificarse en su despliegue.
La disponibilidad depende de tu instancia. Consulta /health y /v1/routes antes de integrar.