Monitoring

This guide covers monitoring for an OpenScan.AI explorer deployment: what to measure, how to alert, and how to read the signals during an incident.

The Golden Signal: Blocks Behind Head

The single most important metric is how far the indexer trails the chain:

blocks_behind = chain_head_height - last_indexed_height

Healthy: close to your configured confirmation depth. Alert when it grows steadily — that means the indexer is falling behind or the chain node is lagging.

What to Monitor

Chain Node

• Sync status — eth_syncing should return false
• Peer count — drops to zero mean the node is isolated
• Disk usage — archive data grows continuously

Indexer

• Blocks behind head (above)
• Fetch error rate — RPC failures against the node
• Reorg events — occasional is normal; frequent indicates node issues

Database

• Disk usage — alert at 70% and 85%
• Connection count — approaching the configured max indicates leaks or undersizing
• Query latency — slow queries surface as slow API responses

API and Frontend

• Request rate and error rate — 5xx responses
• Response latency — p95 per endpoint
• Health endpoint — /api/v2/blocks returning recent blocks

Prometheus and Grafana

The services expose /metrics endpoints in Prometheus format. A minimal scrape config:

scrape_configs:
  - job_name: openscan
    static_configs:
      - targets: ["indexer:6060", "api:4000"]

Pair with Grafana dashboards for block lag, API latency, and database health, and route alerts to your on-call channel (email, Slack, or PagerDuty).

Log-Based Troubleshooting

# Indexer progress and errors
docker compose logs -f indexer

# API errors
docker compose logs --since 1h api | grep -i error

Common Incident Patterns

Hosted Instances

For hosted EaaS deployments, OpenScan.AI monitors all of the above on your behalf and responds to incidents. You’ll still want to watch the public health of your explorer’s domain as part of your own chain’s status page.