Commands to check your node

• Is it running?
• Sync progress
• Peers
• Disk and memory
• Mempool
• Logs
• Stop and restart

Is it running?

Tells you whether systemd sees the node as alive. Check this before debugging anything else.

$ systemctl status bitcoind --no-pager
● bitcoind.service - Bitcoin daemon
     Active: active (running) since ...

Good: active (running). failed or inactive: read the logs.

Sync progress

Tells you how far the node has validated the chain. headers is the height of the best chain the node knows about, blocks is how many it has fully checked.

$ bitcoin-cli getblockchaininfo | grep -E 'blocks|headers|verificationprogress|initialblockdownload|size_on_disk|pruned'
  "blocks": 969640,
  "headers": 969640,
  "verificationprogress": 0.99999,
  "initialblockdownload": false,
  "size_on_disk": 800000000000,
  "pruned": false,

Good: blocks equals headers (or trails by a block or two), initialblockdownload is false. During the first sync, blocks is lower than headers and verificationprogress rises toward 1, slowly at first. Bad: blocks unchanged for hours, see sync stuck.

Peers

A node needs peers to receive blocks. These show how many it has and who they are.

$ bitcoin-cli getconnectioncount
10
$ bitcoin-cli getnetworkinfo | grep -E 'subversion|networkactive|connections'
  "subversion": "/Satoshi:X.Y.Z/",
  "networkactive": true,
  "connections": 10,
  "connections_in": 0,
  "connections_out": 10,
$ bitcoin-cli getpeerinfo | grep -E '"(addr|inbound|subver)"'
    "addr": "203.0.113.5:8333",
    "inbound": false,
    "subver": "/Satoshi:X.Y.Z/",

Good: about 10 outbound connections (connections_out). connections_in stays at 0 unless TCP port 8333 is reachable from the internet, which is optional. Bad: 0 connections after a few minutes, or networkactive: false: check the machine's internet access and DNS. Tor-only nodes see different numbers, see Tor and privacy.

Disk and memory

The two resources that most often stop a node. A full disk is the common one.

$ df -h /var/lib/bitcoind
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  1.8T  820G  900G  48% /
$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.6Gi       1.9Gi       0.3Gi        10Mi       5.4Gi       5.6Gi
Swap:          1.0Gi          0B       1.0Gi

Good: Use% below about 90 and still stable, available memory not near zero, little or no swap in use. Bad: disk at 100% or memory almost gone with heavy swap: see disk space & pruned and lower dbcache in the config.

Mempool

The mempool holds transactions your node has seen and not yet seen in a block. It is only informative once the node is in sync.

$ bitcoin-cli getmempoolinfo
{
  "loaded": true,
  "size": 12000,
  "bytes": 4500000,
  "usage": 30000000,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00000100,
  ...
}

Good: loaded is true and size is not stuck at 0 once you are synced and have peers. size is the transaction count and usage is memory, capped by maxmempool. A big or small mempool reflects network activity and says nothing about your node's health.

Logs

The log says what the node is doing right now and why it failed. Under systemd it goes to the journal and to debug.log, with the same content.

$ journalctl -u bitcoind -n 20 --no-pager
... bitcoind[1234]: 2026-10-02T12:00:00Z UpdateTip: new best=0000... height=969640 ... progress=0.999990 cache=...
$ sudo tail -n 20 /var/lib/bitcoind/debug.log

Good: regular UpdateTip lines while syncing, then one about every ten minutes once synced. Lines mentioning disk, corrupt or Error need attention. The log can contain IP addresses, so redact it before posting it anywhere.

Stop and restart

$ sudo systemctl stop bitcoind
$ sudo systemctl start bitcoind

Good: after a start the node is back to active (running) and blocks catches up with headers within minutes. If it keeps failing, fix the cause shown in the logs instead of restarting in a loop.

Related

• Setup guide
• bitcoin.conf reference
• Node maintenance
• Security basics

FAQ