Monitoring & Metrics

Enable the monitoring stack and track the health and sync status of your Celo node

The celo-l2-node-docker-compose setup ships with a monitoring stack so you can watch your node’s health and sync status.

Enable monitoring

Set the following in your .env file and restart:

MONITORING_ENABLED=true

This starts four services alongside your node: Healthcheck, Prometheus, Grafana, and InfluxDB.

Grafana dashboards

With monitoring enabled, Grafana is available at http://localhost:3000 (configurable via PORT__GRAFANA).

• Username: admin
• Password: celo

These are the compose defaults, and compose publishes Grafana on every host interface (${PORT__GRAFANA:-3000}:3000). Set GF_SECURITY_ADMIN_PASSWORD in .env before you first start with monitoring enabled: Grafana reads it only when it creates the admin user, and keeps that user in the grafana_data volume. If Grafana has already started, change the password in Grafana instead (user icon → Change Password). Either way, firewall port 3000 so it is not reachable from the public internet.

The Simple Node Dashboard (Dashboards → Manage → Simple Node Dashboard) shows basic node information and sync status. If you run the challenger, the Succinct Challenger dashboard shows challenger activity.

Where metrics come from

• op-node exposes Prometheus metrics on port 7300 (--metrics.enabled). Prometheus (port 9090, configurable via PORT__PROMETHEUS) scrapes op-node, op-reth, the healthcheck, and the challenger.
• op-reth exposes Prometheus metrics that Prometheus scrapes.
• Grafana reads from Prometheus.

Key metrics to watch

From op-node (query in Prometheus at http://localhost:9090 or in Grafana; the op-node port 7300 is not published to the host, where localhost:7300 is the healthcheck):

• op_node_default_refs_number — the op-node’s current L1/L2 reference block numbers. If it stops increasing, your node is not syncing; if it goes backwards, your node is reorging.
• op_node_default_peer_count — how many peers op-node is connected to. Without peers, op-node cannot sync unsafe blocks and your node will lag behind the sequencer.
• op_node_default_rpc_client_request_duration_seconds — latency of the RPC calls op-node makes to L1 and to the execution client; useful for finding sync bottlenecks.

From the healthcheck service:

• healthcheck_reference_height - healthcheck_target_height — how far your node lags the reference RPC (HEALTHCHECK__REFERENCE_RPC_PROVIDER, default https://forno.celo.org).
• healthcheck_is_currently_diverged — non-zero if your node has diverged from the reference chain.

For the full op-node metrics catalog, see the Optimism Node Metrics and Monitoring reference.

What healthy sync looks like

Even without the Grafana stack, you can confirm your node is syncing:

# Follow op-reth logs — watch it execute blocks toward the chain tip
docker compose logs -n 50 -f op-reth

# Check sync progress (requires foundry)
./progress.sh

# As the node syncs, the head block number climbs and then tracks the network
cast block-number --rpc-url http://localhost:9993

In the logs, a syncing node shows op-reth importing and executing blocks, with its head advancing toward the network’s latest block.

If your node is not syncing or has no peers, see Troubleshooting.