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.Documentation Index
Fetch the complete documentation index at: https://docs.ifalabs.com/llms.txt
Use this file to discover all available pages before exploring further.
What to Monitor
Before writing any monitoring code, define what conditions matter for your protocol:| Condition | Why It Matters | Recommended Alert Threshold |
|---|---|---|
| Feed staleness | Stale data may no longer reflect market reality | Age > heartbeat interval × 1.2 |
| Peg deviation | Off-peg stablecoin may indicate depeg event | > 0.5% from $1.00 for global stablecoins |
| Sudden price movement | Rapid movement may indicate manipulation or genuine crisis | > 1% change between consecutive updates |
| Update frequency drop | Fewer updates than expected may indicate relayer issues | < expected updates per hour |
| Cross-chain divergence | Price inconsistency across chains may indicate deployment issues | > 0.1% deviation between networks |
| Feed going offline | Asset returning exists = false | Immediate — should never happen post-launch |
Basic Monitoring Script
A minimal polling monitor that checks all feeds every five minutes and logs anomalies:Adding Alerting Integrations
The monitor above calls analert() 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:Grafana Dashboard
For teams that want a visual monitoring dashboard, expose metrics from the monitor and scrape with Prometheus:ifa_labs_* metrics into Grafana and build dashboards showing price history, feed age, and staleness status across all assets and networks.
Deployment Options
| Option | Best For | Notes |
|---|---|---|
| Local process | Development and testing | Not suitable for production — no reliability guarantees |
| Docker container | Self-hosted production | Use a process manager like PM2 or systemd for restart on failure |
| Cloud function (Lambda, Cloud Run) | Scheduled polling | Trigger every 5 minutes via cron. No persistent state — use a database for previousPrices. |
| Dedicated VPS | Full monitoring stack | Run monitor + Prometheus + Grafana together |
| Tenderly Alerts | No-code monitoring | Set up web3 action alerts directly on the oracle contract without writing code |
Monitoring Checklist
Before going live with a protocol that consumes IFÁ Labs feeds, confirm:Monitoring is running in production
The monitoring script is deployed and running against Base Mainnet — not just tested locally against testnet.
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.
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.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.
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).
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.

