MEV Bot Monitoring & Alerts 2026: Uptime, Dashboards, On-Call

The problem with MEV bots going silent — an MEV bot that stops submitting bundles doesn't throw errors at you. It just stops making money. Without monitoring, a stuck RPC connection, an exhausted tip balance, or a crashed process can silently cost you hours of missed opportunities before you notice. This guide covers the complete monitoring stack: what to watch, how to alert, and how to recover fast.

Why Standard Uptime Monitoring Isn't Enough

A web service goes down and returns 5xx — your uptime monitor sees the failure immediately. An MEV bot is different:

• The process may be running but submitting zero bundles (blocked RPC, stale nonce, exhausted allowance)
• The bot may be bidding but consistently losing (competitor outbid, config drift, execution issue)
• Profit may have declined without a hard failure (gas cost increase, MEV opportunity compression)

Standard ping-based uptime monitoring tells you the process is alive. It doesn't tell you the bot is earning. You need business-logic monitoring — watching the outputs, not just the process health.

The Three Layers of MEV Bot Monitoring

Layer 1: Process Health (Is it running?)

Basic infrastructure monitoring. The bot process should be alive and consuming expected resources.

What to monitor:

• Process PID alive (can use systemd, PM2, or Windows Task Scheduler to auto-restart)
• CPU usage (a stuck bot sometimes spins at 100%; a crashed bot drops to 0%)
• Memory usage (memory leaks in long-running bots cause gradual RAM growth until OOM)
• Disk space (logs fill up fast; rotate aggressively)

Tools:

• Prometheus + Node Exporter — scrapes system metrics every 15s, feeds Grafana
• PM2 (Node.js) or systemd (Linux) — process supervisor with auto-restart
• Windows Task Scheduler or NSSM (FRB Agent on Windows) — auto-restart on failure
• UptimeRobot / Better Uptime — external process check via HTTP health endpoint

Practical setup: expose a /health HTTP endpoint from your bot that returns 200 + a JSON payload including last bundle submitted time, last successful block, and current balance. Ping this every 60 seconds from an external monitor.

Layer 2: RPC and Relay Health (Are my connections working?)

RPC failures are the most common cause of silent MEV bot failures. Your bot needs a live connection to:

• A block data source (Ethereum node / Alchemy / QuickNode WebSocket)
• Flashbots relay (or MEV Blocker, private order flow, etc.)
• Mempool feed (if running public mempool strategies)

What to monitor:

• RPC latency: measure the round-trip time for eth_blockNumber every 10 seconds. Spikes above 500ms indicate degraded RPC performance.
• WebSocket connection state: WebSocket disconnects often happen silently; add reconnect logic and alert if you've reconnected more than N times in an hour
• Relay submission success rate: Flashbots relay returns bundle status — track the ratio of submitted to accepted bundles. A sudden drop indicates relay issues or config problems.
• Block lag: if your bot's view of the latest block is more than 2-3 blocks behind real head, your RPC is lagging and you're bidding on stale state

Tools:

• Alchemy Notify / QuickNode Alerts — provider-side monitoring; alerts when your RPC quota is approaching or connection is degraded
• Grafana + custom exporter — write a small sidecar that polls your RPC and exports latency as a Prometheus metric
• Flashbots relay API — poll https://relay.flashbots.net/relay/v1/data/bundlestats for bundle simulation results

Alert threshold example:

alert: RPCLatencyHigh
condition: rpc_latency_ms > 500 for 2 minutes
severity: warning

alert: RPCDisconnected  
condition: rpc_connection_state != "connected" for 30 seconds
severity: critical — page on-call immediately
Copy

Layer 3: Business Logic (Is it earning?)

This is the layer most operators miss. The bot is running, connections are live — but is it actually finding and winning opportunities?

Key business metrics to track:

How to get this data:

• Parse your bot's own log output and expose as Prometheus metrics
• Subscribe to eth_newBlockFilter and verify each block for your successful transactions on-chain
• Use Flashbots bundle status API to get accepted/rejected counts

Alert Routing: Who Gets Paged for What

Not every alert needs to wake someone up at 3am. Define severity levels upfront:

Telegram Alerts (Recommended for Solo Operators)

Telegram is the standard for crypto bot operators — instant, mobile-first, free, and programmable via bot API.

Setup:

1. Create a Telegram bot via BotFather (/newbot)
2. Get your chat ID (send a message to the bot, then call https://api.telegram.org/bot<TOKEN>/getUpdates)
3. Send alerts via sendMessage API call from your monitoring code

Alert message format (keep it actionable):

🔴 CRITICAL — FRB bot not submitting
Last bundle: 47 minutes ago
Latest block: 22,341,887
RPC latency: 1,240ms
Action: check RPC connection, restart if needed
Copy

PagerDuty / Opsgenie (For Teams)

For teams running multiple bots, PagerDuty provides on-call rotation, escalation policies, and incident management. Connect Prometheus Alertmanager → PagerDuty with a routing key. Critical alerts go to the on-call person's phone; high alerts go to Slack.

Grafana Cloud (Free Tier)

Grafana Cloud's free tier supports 10,000 active metrics series — more than enough for a single MEV bot operation. Push metrics from your bot via the Prometheus remote write endpoint and build dashboards in Grafana Cloud without running your own infrastructure.

Building Your Core Dashboard

A useful MEV bot dashboard has 4 panels:

Panel 1: Bot Health Overview

• Process uptime (time since last restart)
• RPC latency (line chart, last 6 hours)
• WebSocket reconnects (count, last 24 hours)

Panel 2: Bundle Activity

• Bundles submitted per hour (bar chart)
• Bundle win rate (%) — line chart
• Failed simulations per hour

Panel 3: Revenue

• Gross revenue per hour (ETH)
• Gas cost per hour (ETH)
• Net profit per hour (ETH)
• Cumulative daily PnL

Panel 4: Infrastructure

• ETH tip balance (with threshold line at 0.1 ETH)
• CPU / memory usage
• Disk space remaining (for logs)

On-Chain Verification: Trust But Verify

Don't only rely on your bot's own logs. Cross-check on-chain:

• Etherscan address monitoring: Etherscan supports email alerts when your wallet address makes a transaction. Use this as a secondary signal.
• Blockdaemon / Nansen alerts: Whale-grade alert services but useful for verifying large flows
• Custom script: Run a cron job every 5 minutes that calls eth_getTransactionCount on your bot address and verifies nonce is increasing. If nonce is stuck, the bot isn't landing transactions.

## Simple nonce check (run every 5 minutes via cron)
NONCE=$(curl -s -X POST https://eth-mainnet.alchemyapi.io/v2/$ALCHEMY_KEY \
  -H "Content-Type: application/json" \
  -d '{"method":"eth_getTransactionCount","params":["'$BOT_ADDRESS'","latest"],"id":1}' \
  | jq -r '.result')
echo "$(date): nonce=$NONCE" >> /var/log/bot-nonce.log
Copy

Incident Runbook: Bot Not Submitting Bundles

When you get a critical alert, follow this sequence:

1. Check process — is the bot process running? ps aux | grep bot or check Task Manager
2. Check RPC — can you curl the RPC endpoint and get a valid block number?
3. Check relay — is Flashbots relay reachable? curl https://relay.flashbots.net/
4. Check balance — does the signing wallet have enough ETH for gas + tips?
5. Check nonce — is there a stuck pending transaction? Check Etherscan for your address
6. Check logs — what's the last log entry? Errors? Panics?
7. Restart — if no clear cause, restart the bot process and monitor for 5 minutes
8. Escalate — if restart doesn't resolve, escalate to the on-call engineer or check Discord/status pages for relay issues

Keep this runbook somewhere your whole team can access — not just in your head.

FRB Agent Monitoring Integration

FRB Agent exposes bundle submission status and connection health via its built-in UI. For external monitoring, pipe its log output to your preferred aggregator:

• Windows Event Log: redirect stdout to Windows Event Log via NLog
• File-based logs: FRB Agent writes structured JSON logs — parse with Filebeat → Elasticsearch or Loki → Grafana

The FRB Agent download includes configuration templates for common monitoring setups.

Further Reading

• MEV Bot PnL Tracking Dashboards 2026
• MEV Bot Security 2026
• How to Detect MEV in Your Trades
• VPS Setup for Crypto Bots 2026
• Flashbots MEV Overview