Skip to main content
On-chain checks protect your contracts at execution time. Off-chain monitoring protects your protocol between executions — alerting your team before a stale feed, a depeg event, or a relayer delay reaches the point where it causes a transaction to revert or a user to be harmed. This page provides production-ready monitoring scripts, alerting patterns, and operational guidance for running IFÁ Labs feed monitoring in a live environment.

What to Monitor

Before writing any monitoring code, define what conditions matter for your protocol:

Basic Monitoring Script

A minimal polling monitor that checks all feeds every five minutes and logs anomalies:

Adding Alerting Integrations

The monitor above calls an alert() function for every anomaly. Replace the placeholder comment with your alerting stack.

Discord Webhook

Telegram Bot

PagerDuty


Real-Time Event-Based Monitor

Polling every five minutes misses events between checks. For tighter monitoring, combine polling with real-time event listening:
WebSocket connections to RPC providers drop periodically. Production monitors must implement reconnection logic. Without it, your monitor will silently stop receiving events after the first disconnection. Libraries like reconnecting-websocket handle this automatically, or implement exponential backoff reconnection manually.

Grafana Dashboard

For teams that want a visual monitoring dashboard, expose metrics from the monitor and scrape with Prometheus:
Import the ifa_labs_* metrics into Grafana and build dashboards showing price history, feed age, and staleness status across all assets and networks.

Deployment Options


Monitoring Checklist

Before going live with a protocol that consumes IFÁ Labs feeds, confirm:
1

Monitoring is running in production

The monitoring script is deployed and running against Base Mainnet — not just tested locally against testnet.
2

Alerting is wired up

At least one alerting integration — Discord, Telegram, PagerDuty, or equivalent — is configured and has been tested end-to-end with a simulated alert.
3

Thresholds are calibrated to heartbeat intervals

maxAge values in the monitoring config are set to at least 1.5× the heartbeat interval for each asset — not arbitrary round numbers.
4

WebSocket reconnection is implemented

If using real-time event monitoring, reconnection logic is in place and has been tested by deliberately killing the WebSocket connection.
5

Runbook exists for alerts

Every alert type has a documented response procedure — who gets paged, what they check first, what actions are available (pause, fallback, investigate).
6

On-call rotation is defined

Someone is responsible for responding to CRITICAL alerts at any time. Monitoring without on-call coverage is monitoring theater.

Next Steps

Building Fallback Strategies

What to do when monitoring detects a problem — fallback oracle patterns for protocol resilience.

Handle Stale Data

On-chain staleness patterns that complement off-chain monitoring.