Blockchain Node Monitoring
Your node went down at 3 AM—your dApp started returning errors, users couldn't complete transactions. You found out at 9 AM from the first complaining customer. Sound familiar? We've encountered this dozens of times: without automatic monitoring, downtime stretches for hours. Our engineers have configured hundreds of nodes for Ethereum, Polygon, Solana, and Bitcoin over 5+ years of experience and 50+ successful projects. The result: an alert comes within 2 minutes of the problem starting, not after 6 hours. This setup can save you $500/month in downtime costs. For a typical production node, downtime costs about $500 per hour, so a 2-minute detection time can save thousands annually. This article covers the proven stack and specific configs we use in production for blockchain node monitoring.
Which Metrics Are Critical and What Thresholds to Set?
For any node (go-ethereum, Bor, Bitcoin Core, Solana validator), key metrics:
- Block lag (current_block - network_head_block). Normal: 0-5 blocks behind. Alert: >10 for EVM, >2 for Solana.
- Peer count—number of peers. < 3 means the node is isolated, 0 indicates a network issue.
- RPC availability—eth_blockNumber as a health check: the simplest method.
- System metrics—CPU, RAM, disk space. For archive nodes, disk grows by 1-2 GB per day—without monitoring, it will run out in a few months and the node will halt.
Prometheus best practices recommend polling critical service metrics every 15–30 seconds. We adhere to this.
| Metric | Normal | Warning | Critical Alert |
|---|---|---|---|
| Lag (EVM) | 0-5 blocks | 6-10 blocks | >10 blocks |
| Lag (Solana) | 0-2 blocks | 2 blocks | >2 blocks |
| Peer count | >=5 | 3-4 | <3 |
| Free disk space | >30% | 15-30% | <15% |
How to Set Up Alerts in 2 Minutes: Step-by-Step
The standard production approach for blockchain node monitoring uses Prometheus for metric collection and Alertmanager for notifications. Prometheus paired with Alertmanager processes alerts 10 times faster than a custom cron script, and its Alertmanager routing tree allows fine-grained notification policies.
- Step 1: Enable metric collection. geth exports metrics out of the box:
geth --metrics --metrics.addr 127.0.0.1 --metrics.port 6060 For nodes without native Prometheus support, write an exporter in Python (beware of metric cardinality):
from prometheus_client import Gauge, start_http_server from web3 import Web3 node_block = Gauge('node_current_block', 'Current block number') node_peers = Gauge('node_peer_count', 'Number of peers') def collect(): w3 = Web3(Web3.HTTPProvider('http://localhost:8545')) node_block.set(w3.eth.block_number) node_peers.set(w3.net.peer_count) start_http_server(8000) # Run collect on schedule—omitted for brevity - Step 2: Configure alert rules. Example alerts.yml with PromQL expressions:
groups: - name: blockchain-node rules: - alert: NodeSyncLag expr: (network_head_block - node_current_block) > 10 for: 2m labels: severity: critical annotations: summary: "Node is lagging {{ $value }} blocks behind" - alert: NodeRPCDown expr: up{job="ethereum-node"} == 0 for: 1m labels: severity: critical - alert: DiskSpaceLow expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.15 for: 5m labels: severity: warning - Step 3: Set up the notification channel. For small teams, Telegram is enough: a bot sends a message with a brief problem description. Alerts trigger after 1-2 minutes of delay.
Why External Monitoring Is Necessary?
Prometheus monitors internally—if the server or network goes down, the alert won't come. For thorough node monitoring setup, external checks solve this. The optimal choice depends on your tasks—contact us, we'll help you choose a solution.
For external monitoring, there are several options. Compare them:
| Tool | Type | Advantages | Disadvantages |
|---|---|---|---|
| Uptime Kuma | Self-hosted | Free, flexible | Requires separate server |
| Better Stack | SaaS | Easy setup, ready integrations | Paid subscription |
| Healthchecks.io | SaaS | Ideal for cron jobs | Limited functionality |
For a node, an HTTP check is sufficient: send a POST request to http://your-node:8545 with body {"method":"eth_blockNumber","id":1}—if the response is 200, the node is alive.
Grafana: Visualizing Trends
Without a dashboard, it's hard to analyze trends: disk growth, peer count decline, RPC response time increase. We import ready-made dashboards by ID from Grafana Labs and adapt them to your network. Setup takes 1-2 hours. Pay attention to metric retention: configure long-term storage for historical analysis.
Example query for a Lag panel
(network_head_block - node_current_block) Displays the block difference over the last 6 hours.
Logs: Quick Problem Search
Minimum: journald with rotation and grep for errors. For multiple nodes: Loki + Grafana. Critical patterns in geth logs: database corruption, fatal error, peer discovery disabled.
What You Get in 2-3 Days
- Prometheus + Grafana on your server or cloud.
- Metrics exporter for your node (go-ethereum, Bor, Bitcoin Core, Solana).
- Alerts in Telegram/Slack for lag, RPC unavailability, low disk.
- External uptime monitoring.
- Dashboard with metric history and real-time status.
- Documentation on maintenance and access.
We guarantee that after setup, you'll know about problems in 2 minutes, not the next morning. With 5+ years of experience and 50+ successful projects, we deliver reliable blockchain node monitoring. Order monitoring setup—get a consultation and assessment of your infrastructure. Contact us to discuss details.